linux-ima-devel — Discussion list for problems or development.

Re: [Linux-ima-devel] Query about ditital signature format (v1 and v2)

[Dmitry K. <dmi...@gm...>]

Hello Vivek,


On Thu, May 30, 2013 at 6:44 PM, Vivek Goyal <vg...@re...> wrote:
> Hi Dmitry,
>
> I was going through the evmutils code and have few questions. Would be
> great if you could help me out here.
>
> I noticed that both for v1 and v2 of digital signauture we store the
> length of signature.
>
> For v1 we seem to be storing bit length (and not byte length) while
> for V2 we seem to be storing byte length. Comment says that it is to
> make it compatible with gnupg.
>
> For v1:
>
>         /* we add bit length of the signature to make it gnupg compatible
>  * */
>         blen = (uint16_t *) (sig + sizeof(*hdr));
>         *blen = __cpu_to_be16(len << 3);
>
>
> For v2:
>
>         /* we add bit length of the signature to make it gnupg compatible
>  * */
>         hdr->sig_size = __cpu_to_be16(len);
>
>
> Few queries.
>
> - Is it intentional that for V2 we store the length in bytes and not bits.
>
> - Is there any documentation which explains gnupg signature format and it
>   requirements for storing length of signature.
>

Using bits was a very old legacy decision based on some very old code from
digsig project or so. There is a function in the mpilib which reads bits...
In fact it has nothing to do with gpg...


> - Storing sizse in bits  with-in 2 bytes means that signature can not exceed
>   the size of 32 bytes. I am not sure if that's good enough or not.
>

When measuring in bytes, 2 bytes it can hold up 64k.
When measuring in nits, 2 bytes can 64k >> 3 - up to 8k.

Right?

Signature is under 1k now...

> - What does gnupg compatible mean here? Can I take this sigunature and
>   pass as detached signature to gnupg utils and they can verify this
>   signature against a given file?

It means nothing.. just ignore that comment.
it is not possible.. signature header format is different...
BUT RSA signature itself is a usual signature (RSA sign).

What do you want to achieve?

>
> Thanks
> Vivek

Re: [Linux-ima-devel] Query regarding digital signature hash algorithm

[Mimi Z. <zo...@li...>]

On Thu, 2013-05-30 at 14:50 -0400, Vivek Goyal wrote:
> Hi Dmitry,
> 
> I have more queries about evmctl. This time hash algorithm used for digital
> signing by evmctl. Will be great if you can help out.
> 
> IIUC, following seems to be the case.
> 
> - We always use SHA1 for v1 of digital signature. Even if one specifies
>   -a option, we ignore that for v1?
> 
> - hash algo into is put in digital signature header. Looks like we put
>   this info differently for v1 and v2. For v1, we always seem to use
>   DIGEST_ALGO_SHA1 that is value 0. For V2, we seem to map algo to
>   enum pkey_hash_algo. That means even if we sign v2 header using sha1,
>   value will be 2.
> 
>   IOW, sha1 is mapped to different values in v1 and v2. v2 seems to
>   map to kernel defined hash algo enum while v1 does not. So if I decide
>   to parse signatures in kernel and extract hash algorithm in kernel, I 
>   need to do it differently based on version of signature?

Hi Vivek, we're working on an IMA patch set that supports larger hash
digests.  The ima-evm-utils package has already been updated to support
these larger digests.  Unfortunately, the change isn't isolated to just
signature verification, but requires major changes to the measurement
list architecture.  One version of the changes are in the
#next-multiple-templates-experimental branch.

thanks,

Mimi

[Linux-ima-devel] Query regarding digital signature hash algorithm

[Vivek G. <vg...@re...>]

Hi Dmitry,

I have more queries about evmctl. This time hash algorithm used for digital
signing by evmctl. Will be great if you can help out.

IIUC, following seems to be the case.

- We always use SHA1 for v1 of digital signature. Even if one specifies
  -a option, we ignore that for v1?

- hash algo into is put in digital signature header. Looks like we put
  this info differently for v1 and v2. For v1, we always seem to use
  DIGEST_ALGO_SHA1 that is value 0. For V2, we seem to map algo to
  enum pkey_hash_algo. That means even if we sign v2 header using sha1,
  value will be 2.

  IOW, sha1 is mapped to different values in v1 and v2. v2 seems to
  map to kernel defined hash algo enum while v1 does not. So if I decide
  to parse signatures in kernel and extract hash algorithm in kernel, I 
  need to do it differently based on version of signature?

Thanks
Vivke

[Linux-ima-devel] Query about ditital signature format (v1 and v2)

[Vivek G. <vg...@re...>]

Hi Dmitry,

I was going through the evmutils code and have few questions. Would be
great if you could help me out here.

I noticed that both for v1 and v2 of digital signauture we store the
length of signature.

For v1 we seem to be storing bit length (and not byte length) while
for V2 we seem to be storing byte length. Comment says that it is to
make it compatible with gnupg.

For v1:

        /* we add bit length of the signature to make it gnupg compatible
 * */
        blen = (uint16_t *) (sig + sizeof(*hdr));
        *blen = __cpu_to_be16(len << 3);


For v2:

        /* we add bit length of the signature to make it gnupg compatible
 * */
        hdr->sig_size = __cpu_to_be16(len);


Few queries.

- Is it intentional that for V2 we store the length in bytes and not bits.

- Is there any documentation which explains gnupg signature format and it
  requirements for storing length of signature.

- Storing sizse in bits  with-in 2 bytes means that signature can not exceed
  the size of 32 bytes. I am not sure if that's good enough or not.

- What does gnupg compatible mean here? Can I take this sigunature and
  pass as detached signature to gnupg utils and they can verify this
  signature against a given file?

Thanks
Vivek

Re: [Linux-ima-devel] [Linux-ima-user] Query about evmctl and hash algo

[Roberto S. <rob...@po...>]

Il 3/13/2013 10:16 PM, Mimi Zohar ha scritto:
> On Wed, 2013-03-13 at 21:42 +0100, Roberto Sassu wrote:
>> Il 3/13/2013 7:11 PM, Mimi Zohar ha scritto:
>>> On Wed, 2013-03-13 at 13:26 -0400, Vivek Goyal wrote:
>>>> On Wed, Mar 13, 2013 at 11:34:28AM -0400, Vivek Goyal wrote:
>>>>> Hi Dmitry,
>>>>>
>>>>> I used evmctl to sign an executable. I used an x.509 cert. I generated
>>>>> cert and specified to use -sha256 algorithm.
>>>>>
>>>>> But I noticed that evmctl ignores x.509 values and by default calculates
>>>>> sha1 hash.
>>>>>
>>>>> I thought we should honor x.509 certificate and use the hashing algorithm
>>>>> as specified in the cert. What do you think?
>>>>>
>>>>
>>>> Or may be I have misunderstood it and x.509 does not impose the type
>>>> of hash algorithm that should be used for signing. And user is free to
>>>> use any hash algorithm.
>>>
>>> Vivek, we definitely want to be able to collect, store, and appraise
>>> files based on the signature hash algorithm.  For now, the kernel only
>>> supports sha1.  Dmitry has some kernel patches in his
>>> linux-digsig/#working branch, which are not yet quite ready to be posted
>>> or upstreamed.
>>>
>>> Before being able to support hashes larger than md5/sha1, we also need
>>> to modify the existing 'ima' template.  Otherwise we would need to hash
>>> the file twice - once for the measurement list and again based on the
>>> signature.  I've pushed out some patches yesterday, which also are not
>>> quite ready for review, to the "next-multiple-template" branch.  These
>>> patches are based on the 'template' patches written 3+ years ago, but
>>> were never upstreamed.  Below is the patch description from the first
>>> patch.
>>>
>>>       The original 'ima' template data includes just the file hash and
>>>       filename.  The hash algorithm size is limited to 20 bytes (md5/sha1).
>>>       The filename is a null terminated string, limited to 255 characters.
>>>       To overcome these limitations, and provide additional file metadata,
>>>       this patch set introduces multiple templates of variable length sizes.
>>>       Future patches will address TPM v2.0 changes.
>>>
>>>       This first patch adds the template data length to the
>>>       binary_runtime_measurements list.  As new templates are defined,
>>>       userspace will continue being able to verify the measurement list
>>>       against the PCR value, yet skip unknown templates.
>>>
>>>       For the patches to be bisect safe and not break userspace, defer
>>>       adding the ability to change the template, until the 'ima-ng' template
>>>       definition is complete.
>>>
>>> The patches to support larger hashes, will be included prior, to the
>>> last patch in this patch set, which changes the default 'ima' template
>>> to 'ima-ng' template and adds a boot command line option for backwards
>>> compatibility.  For a better understanding of what needs to be done,
>>> please refer to the individual patch descriptions.
>>>
>>
>> Hi Mimi, Vivek
>>
>> I'm following this mailing list and I noticed that there is some
>> activity about the IMA templates topic.
>>
>> I'm currently working in this area and I produced some patches that
>> introduce this functionality. They are completely different from
>> those that were developed some years ago. For example, now, in my
>> implementation, it is possible to define a template as a set of fields
>> separated by '|'. Also, there are template names that are associated
>> to a specific set of fields.
>>
>> Each field is defined by two functions: init() to populate data from
>> arguments passed to this function and show() to display that data in
>> ascii or in binary format so that IMA should not be aware of the format
>> but it only has to store the data.
>>
>> I will deliver these patches shortly.
>
> It sounds like a really interesting solution, that scales a lot better
> than what we originally had.  My concern is userspace (eg. trousers,
> openpts, etc) being able to parse this dynamic, variable measurement
> list definition.  I'm looking forward to seeing the patches!
>

Yes, that could be a problem. However, I think this solution eases the
task of adding support for multiple templates in userspace programs
as these applications should only implement a parser for each field
identifier and then, they are capable of inspecting a generic
measurement by retrieving the format contained in the measurement
itself.

Roberto Sassu


> thanks,
>
> Mimi
>

Re: [Linux-ima-devel] [Linux-ima-user] Query about evmctl and hash algo

[Mimi Z. <zo...@li...>]

On Wed, 2013-03-13 at 21:42 +0100, Roberto Sassu wrote:
> Il 3/13/2013 7:11 PM, Mimi Zohar ha scritto:
> > On Wed, 2013-03-13 at 13:26 -0400, Vivek Goyal wrote:
> >> On Wed, Mar 13, 2013 at 11:34:28AM -0400, Vivek Goyal wrote:
> >>> Hi Dmitry,
> >>>
> >>> I used evmctl to sign an executable. I used an x.509 cert. I generated
> >>> cert and specified to use -sha256 algorithm.
> >>>
> >>> But I noticed that evmctl ignores x.509 values and by default calculates
> >>> sha1 hash.
> >>>
> >>> I thought we should honor x.509 certificate and use the hashing algorithm
> >>> as specified in the cert. What do you think?
> >>>
> >>
> >> Or may be I have misunderstood it and x.509 does not impose the type
> >> of hash algorithm that should be used for signing. And user is free to
> >> use any hash algorithm.
> >
> > Vivek, we definitely want to be able to collect, store, and appraise
> > files based on the signature hash algorithm.  For now, the kernel only
> > supports sha1.  Dmitry has some kernel patches in his
> > linux-digsig/#working branch, which are not yet quite ready to be posted
> > or upstreamed.
> >
> > Before being able to support hashes larger than md5/sha1, we also need
> > to modify the existing 'ima' template.  Otherwise we would need to hash
> > the file twice - once for the measurement list and again based on the
> > signature.  I've pushed out some patches yesterday, which also are not
> > quite ready for review, to the "next-multiple-template" branch.  These
> > patches are based on the 'template' patches written 3+ years ago, but
> > were never upstreamed.  Below is the patch description from the first
> > patch.
> >
> >      The original 'ima' template data includes just the file hash and
> >      filename.  The hash algorithm size is limited to 20 bytes (md5/sha1).
> >      The filename is a null terminated string, limited to 255 characters.
> >      To overcome these limitations, and provide additional file metadata,
> >      this patch set introduces multiple templates of variable length sizes.
> >      Future patches will address TPM v2.0 changes.
> >
> >      This first patch adds the template data length to the
> >      binary_runtime_measurements list.  As new templates are defined,
> >      userspace will continue being able to verify the measurement list
> >      against the PCR value, yet skip unknown templates.
> >
> >      For the patches to be bisect safe and not break userspace, defer
> >      adding the ability to change the template, until the 'ima-ng' template
> >      definition is complete.
> >
> > The patches to support larger hashes, will be included prior, to the
> > last patch in this patch set, which changes the default 'ima' template
> > to 'ima-ng' template and adds a boot command line option for backwards
> > compatibility.  For a better understanding of what needs to be done,
> > please refer to the individual patch descriptions.
> >
> 
> Hi Mimi, Vivek
> 
> I'm following this mailing list and I noticed that there is some
> activity about the IMA templates topic.
> 
> I'm currently working in this area and I produced some patches that
> introduce this functionality. They are completely different from
> those that were developed some years ago. For example, now, in my
> implementation, it is possible to define a template as a set of fields
> separated by '|'. Also, there are template names that are associated
> to a specific set of fields.
> 
> Each field is defined by two functions: init() to populate data from
> arguments passed to this function and show() to display that data in
> ascii or in binary format so that IMA should not be aware of the format
> but it only has to store the data.
> 
> I will deliver these patches shortly.

It sounds like a really interesting solution, that scales a lot better
than what we originally had.  My concern is userspace (eg. trousers,
openpts, etc) being able to parse this dynamic, variable measurement
list definition.  I'm looking forward to seeing the patches!

thanks,

Mimi

Re: [Linux-ima-devel] [Linux-ima-user] Query about evmctl and hash algo

[Roberto S. <rob...@po...>]

Il 3/13/2013 7:11 PM, Mimi Zohar ha scritto:
> On Wed, 2013-03-13 at 13:26 -0400, Vivek Goyal wrote:
>> On Wed, Mar 13, 2013 at 11:34:28AM -0400, Vivek Goyal wrote:
>>> Hi Dmitry,
>>>
>>> I used evmctl to sign an executable. I used an x.509 cert. I generated
>>> cert and specified to use -sha256 algorithm.
>>>
>>> But I noticed that evmctl ignores x.509 values and by default calculates
>>> sha1 hash.
>>>
>>> I thought we should honor x.509 certificate and use the hashing algorithm
>>> as specified in the cert. What do you think?
>>>
>>
>> Or may be I have misunderstood it and x.509 does not impose the type
>> of hash algorithm that should be used for signing. And user is free to
>> use any hash algorithm.
>
> Vivek, we definitely want to be able to collect, store, and appraise
> files based on the signature hash algorithm.  For now, the kernel only
> supports sha1.  Dmitry has some kernel patches in his
> linux-digsig/#working branch, which are not yet quite ready to be posted
> or upstreamed.
>
> Before being able to support hashes larger than md5/sha1, we also need
> to modify the existing 'ima' template.  Otherwise we would need to hash
> the file twice - once for the measurement list and again based on the
> signature.  I've pushed out some patches yesterday, which also are not
> quite ready for review, to the "next-multiple-template" branch.  These
> patches are based on the 'template' patches written 3+ years ago, but
> were never upstreamed.  Below is the patch description from the first
> patch.
>
>      The original 'ima' template data includes just the file hash and
>      filename.  The hash algorithm size is limited to 20 bytes (md5/sha1).
>      The filename is a null terminated string, limited to 255 characters.
>      To overcome these limitations, and provide additional file metadata,
>      this patch set introduces multiple templates of variable length sizes.
>      Future patches will address TPM v2.0 changes.
>
>      This first patch adds the template data length to the
>      binary_runtime_measurements list.  As new templates are defined,
>      userspace will continue being able to verify the measurement list
>      against the PCR value, yet skip unknown templates.
>
>      For the patches to be bisect safe and not break userspace, defer
>      adding the ability to change the template, until the 'ima-ng' template
>      definition is complete.
>
> The patches to support larger hashes, will be included prior, to the
> last patch in this patch set, which changes the default 'ima' template
> to 'ima-ng' template and adds a boot command line option for backwards
> compatibility.  For a better understanding of what needs to be done,
> please refer to the individual patch descriptions.
>

Hi Mimi, Vivek

I'm following this mailing list and I noticed that there is some
activity about the IMA templates topic.

I'm currently working in this area and I produced some patches that
introduce this functionality. They are completely different from
those that were developed some years ago. For example, now, in my
implementation, it is possible to define a template as a set of fields
separated by '|'. Also, there are template names that are associated
to a specific set of fields.

Each field is defined by two functions: init() to populate data from
arguments passed to this function and show() to display that data in
ascii or in binary format so that IMA should not be aware of the format
but it only has to store the data.

I will deliver these patches shortly.

Regards

Roberto Sassu


> thanks,
>
> Mimih
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Linux-ima-user mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-ima-user
>

Re: [Linux-ima-devel] Query about evmctl and hash algo

[Kasatkin, D. <dmi...@in...>]

On Wed, Mar 13, 2013 at 5:34 PM, Vivek Goyal <vg...@re...> wrote:
> Hi Dmitry,
>
> I used evmctl to sign an executable. I used an x.509 cert. I generated
> cert and specified to use -sha256 algorithm.
>
> But I noticed that evmctl ignores x.509 values and by default calculates
> sha1 hash.
>
> I thought we should honor x.509 certificate and use the hashing algorithm
> as specified in the cert. What do you think?
>
> If kernel IMA does not support sha256, then signature verification will
> fail, but I think that's a different issue altogether.
>
> In fact I am not sure that kernel command line ima_hash is relevant
> in user space signing because it hard codes that all files should
> be signed using single hash algorithm. But the fact is that user should
> be able to sign different files using different algorithms. You already
> are passing hash algorithm information in header in V2.
>
> I think there is a disconnect here. Despite the fact that we are passing
> hash algo information in header, in kernel, we are not using that info
> to calculate file hash. Instead we are using sha1 or md5 as specified
> by ima_hash kernel parameter.
>
> I thought a user should have the flexbility to sign the file using
> supported hash algorithms and then kernel should provide mechanism to
> verify file using those algorithms. And we should not impose that all
> ima signed files will have single hash algorithm.
>
> Thanks
> Vivek

Hello Vivek,

As Mimi responded we will support different hashes and work is going on.

Regarding evmctl, it supports different hash algorithms using '-a' or
'--hashalgo' command line parameter.
Latest patch to support asymmetric keys also honors those parameters.

Signing is obviously done using private keys and that does not have
any hash algo in it.
If certificate has a property for a hash algorithm it could be used
instead of default or from command line.

Please suggest a patch for ima-evm-utils

thanks.

- Dmitry

Re: [Linux-ima-devel] Query about evmctl and hash algo

[Mimi Z. <zo...@li...>]

On Wed, 2013-03-13 at 13:26 -0400, Vivek Goyal wrote:
> On Wed, Mar 13, 2013 at 11:34:28AM -0400, Vivek Goyal wrote:
> > Hi Dmitry,
> > 
> > I used evmctl to sign an executable. I used an x.509 cert. I generated
> > cert and specified to use -sha256 algorithm.
> > 
> > But I noticed that evmctl ignores x.509 values and by default calculates
> > sha1 hash.
> > 
> > I thought we should honor x.509 certificate and use the hashing algorithm
> > as specified in the cert. What do you think?
> > 
> 
> Or may be I have misunderstood it and x.509 does not impose the type
> of hash algorithm that should be used for signing. And user is free to 
> use any hash algorithm.

Vivek, we definitely want to be able to collect, store, and appraise
files based on the signature hash algorithm.  For now, the kernel only
supports sha1.  Dmitry has some kernel patches in his
linux-digsig/#working branch, which are not yet quite ready to be posted
or upstreamed.

Before being able to support hashes larger than md5/sha1, we also need
to modify the existing 'ima' template.  Otherwise we would need to hash
the file twice - once for the measurement list and again based on the
signature.  I've pushed out some patches yesterday, which also are not
quite ready for review, to the "next-multiple-template" branch.  These
patches are based on the 'template' patches written 3+ years ago, but
were never upstreamed.  Below is the patch description from the first
patch.

    The original 'ima' template data includes just the file hash and
    filename.  The hash algorithm size is limited to 20 bytes (md5/sha1).
    The filename is a null terminated string, limited to 255 characters.
    To overcome these limitations, and provide additional file metadata,
    this patch set introduces multiple templates of variable length sizes.
    Future patches will address TPM v2.0 changes.
    
    This first patch adds the template data length to the
    binary_runtime_measurements list.  As new templates are defined,
    userspace will continue being able to verify the measurement list
    against the PCR value, yet skip unknown templates.
    
    For the patches to be bisect safe and not break userspace, defer
    adding the ability to change the template, until the 'ima-ng' template
    definition is complete.

The patches to support larger hashes, will be included prior, to the
last patch in this patch set, which changes the default 'ima' template
to 'ima-ng' template and adds a boot command line option for backwards
compatibility.  For a better understanding of what needs to be done,
please refer to the individual patch descriptions.

thanks,

Mimih

Re: [Linux-ima-devel] Query about evmctl and hash algo

[Vivek G. <vg...@re...>]

On Wed, Mar 13, 2013 at 11:34:28AM -0400, Vivek Goyal wrote:
> Hi Dmitry,
> 
> I used evmctl to sign an executable. I used an x.509 cert. I generated
> cert and specified to use -sha256 algorithm.
> 
> But I noticed that evmctl ignores x.509 values and by default calculates
> sha1 hash.
> 
> I thought we should honor x.509 certificate and use the hashing algorithm
> as specified in the cert. What do you think?
> 

Or may be I have misunderstood it and x.509 does not impose the type
of hash algorithm that should be used for signing. And user is free to 
use any hash algorithm.

Thanks
Vivek

> If kernel IMA does not support sha256, then signature verification will
> fail, but I think that's a different issue altogether.
> 
> In fact I am not sure that kernel command line ima_hash is relevant
> in user space signing because it hard codes that all files should
> be signed using single hash algorithm. But the fact is that user should
> be able to sign different files using different algorithms. You already
> are passing hash algorithm information in header in V2.
> 
> I think there is a disconnect here. Despite the fact that we are passing
> hash algo information in header, in kernel, we are not using that info
> to calculate file hash. Instead we are using sha1 or md5 as specified
> by ima_hash kernel parameter.
> 
> I thought a user should have the flexbility to sign the file using
> supported hash algorithms and then kernel should provide mechanism to
> verify file using those algorithms. And we should not impose that all
> ima signed files will have single hash algorithm.
> 
> Thanks
> Vivek

[Linux-ima-devel] Query about evmctl and hash algo

[Vivek G. <vg...@re...>]

Hi Dmitry,

I used evmctl to sign an executable. I used an x.509 cert. I generated
cert and specified to use -sha256 algorithm.

But I noticed that evmctl ignores x.509 values and by default calculates
sha1 hash.

I thought we should honor x.509 certificate and use the hashing algorithm
as specified in the cert. What do you think?

If kernel IMA does not support sha256, then signature verification will
fail, but I think that's a different issue altogether.

In fact I am not sure that kernel command line ima_hash is relevant
in user space signing because it hard codes that all files should
be signed using single hash algorithm. But the fact is that user should
be able to sign different files using different algorithms. You already
are passing hash algorithm information in header in V2.

I think there is a disconnect here. Despite the fact that we are passing
hash algo information in header, in kernel, we are not using that info
to calculate file hash. Instead we are using sha1 or md5 as specified
by ima_hash kernel parameter.

I thought a user should have the flexbility to sign the file using
supported hash algorithms and then kernel should provide mechanism to
verify file using those algorithms. And we should not impose that all
ima signed files will have single hash algorithm.

Thanks
Vivek

[Linux-ima-devel] ReCaculate PCR value from IMA measurement list

[Yu Xi <ge...@gm...>]

Dear all,

I'm writing a testing program to recaculate the pcr value from IMA
measurement list following the procedure below:
*
*
*
*
* {
   uchar PCR_tmp[20] = {0...0}  // the initial value of pcr assigned to zero

   for (i=0; i<MList.len; i++)
        PCR_tmp = SHA1(PCR_tmp || MList[i])  // where || means concatenation

   if (PCR == PCR_tmp)
        return OK
   else
        return INVALID
 }*
*
*
However the newly calculated value doesn't match the real PCR.
I found that some measurement enty in the list is "0000000000000000000000",
is this the reason for the problem? Could anybody help me to solve the
problem? Thank you very much.
-- 
Regards
Xi Yu (禹熹)

Re: [Linux-ima-devel] [TrouSerS-tech] TPM auditing

[Kent Y. <shp...@gm...>]

Hi Matt,

  Sure, I'd be happy to accept an audit patch.  We need to get the IMA
folks on board as well, so we can align how we'd audit things internal
to trousers with what we'd audit in IMA.  If you'd like to send a
patch, just include a signed-off-by: line agreeing to our Developer's
Certificate of Origin:  http://trousers.sourceforge.net/dco.text.

>
>  > Hal Finney wrote:
>  > > The one technical comment I can make is that the TPM device driver
>  > > just sees a stream of bytes going to and coming from the device. It
>  > > would not be in a position to log any of these events without trying
>  > > to parse these bytes and in effect simulate the TPM to some degree. So
>  > > that would be a much more difficult place to insert auditing commands.

  Yep, we'll need to do the auditing somewhere above the DD for
exactly this reason.

>  > I think for things like remote attestation requests that is certainly
>  > true.  From what I've seen so far an audit event like that needs to
>  > happen in tcsd in order to have the most value.  Especially when it
>  > comes down to knowing things like the auid of the user which requested
>  > the action.

  From the tcsd's point of view, all its requests are anonymous.  It
can tell if the request is remote or local, but knows nothing about
the process making the request (such as the uid).  So we may need some
auditing in the TSP.

>  > >> I have been experimenting with the TPM on some of my test systems and
>  > >> have so far come up with this list of possible events that could be
>  > >> interesting from a OS auditing perspective:
>  > >>
>  > >>     * Taking Ownership
>  > >>     * Clearing Ownership
>  > >>     * Dis/Enabling the TPM
>  > >>     * Dis/Activating the TPM
>  > >>     * Recording PCR values at tcsd startup
>  > >>     * Adjustments to PCR values

  It may not be possible to audit PCR changes exactly in the order
they were made (if this matters).

Kent

>  > >>     * Remote attestation connections/commands and their results
>  > >>     * Requests of the Public Endorsement Key (EK)
>  > >>     * Adjustments to the access controls on the EK
>  > >>     * Creating/Destroying the EK
>  > >>     * Changes to the TPM locked status (set/reset)
>  > >>
>  > >> That list is in no way intended to be exhaustive, so suggestions are
>  > >> welcome.  So far it seems like most of these would be audited from
> tcsd,
>  > >> but perhaps some of them make more sense to be audited from within the
>  > >> tpm device driver.  What do you think?
>  > >>
>  > >> -matt
>  > >>
>  > >>
>  > >>
>  > >> Kent Yoder wrote:
>  > >>> Hi Matt,
>  > >>>
>  > >>>   Yes, this feature was for support of Audit as implemented by the
> TSS
>  > >>> and TPM.  We have no plans to add support for Linux auditing.
>  > >>>
>  > >>> Kent
>  > >>>
>  > >>> On Dec 3, 2007 12:32 PM, Matt Anderson <mr...@hp...> wrote:
>  > >>>> Looking at the TSS 1.2 work list I saw Audit was listed as an item
> and
>  > >>>> that Tom Lendacky had the features in CVS.  From what I've seen in
> the
>  > >>>> code this seems to be internal TSS auditing as opposed to work to
>  > >>>> integrate with Linux's light weight audit framework
>  > >>>> http://people.redhat.com/sgrubb/audit/ is that correct?  Is anyone
>
>
>  > >>>> currently working on adding that integration?
>  > >>>>
>  > >>>> -matt
>  > >>>>
>  > >>>>
> -------------------------------------------------------------------------
>  > >>>> SF.Net email is sponsored by: The Future of Linux Business White
> Paper
>  > >>>> from Novell.  From the desktop to the data center, Linux is going
>  > >>>> mainstream.  Let it simplify your IT future.
>  > >>>> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
>
>
>  > >>>> _______________________________________________
>  > >>>> TrouSerS-tech mailing list
>  > >>>> Tro...@li...
>  > >>>> https://lists.sourceforge.net/lists/listinfo/trousers-tech
>  > >>>>
>  > >>>
>  > >>>
>  > >>
>  > >>
> -------------------------------------------------------------------------
>  > >> SF.Net email is sponsored by: The Future of Linux Business White Paper
>  > >> from Novell.  From the desktop to the data center, Linux is going
>  > >> mainstream.  Let it simplify your IT future.
>  > >> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
>  > >> _______________________________________________
>  > >> TrouSerS-tech mailing list
>  > >> Tro...@li...
>  > >> https://lists.sourceforge.net/lists/listinfo/trousers-tech
>  > >>
>  >
>  >
>  > -------------------------------------------------------------------------
>  > SF.Net email is sponsored by: The Future of Linux Business White Paper
>  > from Novell.  From the desktop to the data center, Linux is going
>  > mainstream.  Let it simplify your IT future.
>  > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
>  > _______________________________________________
>  > TrouSerS-tech mailing list
>  > Tro...@li...
>  > https://lists.sourceforge.net/lists/listinfo/trousers-tech
>



-- 
Kent Yoder
IBM LTC Security Dev.

[Linux-ima-devel] Test Message

[Kylene Jo H. <kj...@us...>]

Test message.