linux-ima-user — Q&A for users of IMA

Re: [Linux-ima-user] Endianness-dependent IMA field array hash

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

On 05/02/2014 02:52 PM, Mimi Zohar wrote:
> On Thu, 2014-05-01 at 11:07 +0200, Andreas Steffen wrote:
>> Hello,
>>
>> just to make it clear. There is no problem with the length
>> fields in the raw binary measurement list
>>
>>    /sys/kernel/security/ima/binary_runtime_measurements
>>
>> being in host order since this list is handled by the local
>> Attestation Integrity Measurement Collector (IMC) which
>> has the same endianness as the underlying kernel. The
>> information which the Attestation IMC includes in the
>> integrity report (TCG TNC PTS Binding for the IF-M Protocol)
>> is the template hash of each measurement as it was extended into
>> PCR 10 (which with a current version 1.2 TPM is a 20 byte SHA-1 value).
>> Additional information included in the  integrity report is the
>> eventname (a modified absolute filename or boot_aggregate) and the hash
>> algorithm with which the file itself was hashed ("sha1:", "sha256",
>> etc.).
>>
>> My only request is to convert the field lengths into network
>> order when they are actually hashed into the final measurement value:
>>
>>    u32 field_data_len = htonl(field_data[i].len);
>>
>>    rc = crypto_shash_update(&desc.shash,
>>                (const u8 *) &field_data_len,
>>                 sizeof(field_data_len));
>>
>> With this simple change the endianness of the client platform doesn't
>> have to be included in the integrity report (which would be an awful
>> kludge anyway).
>>
>> A platform-independent template hash has also the big advantage that
>> the measurement values of [non-executable] configuration files would be
>> the same on all platforms.
>
> Ok. So for now, only the field length needs to be in a
> platform-independent byte order to calculate the template hash.
> However, the flexible template format permits us to define new fields,
> such as gid/uid, which are included in the hash calculation.  These new
> fields might also need to be converted to a platform-independent byte
> order for the hash calculation.
>
> Roberto, perhaps in the field definition, itself, we could include a bit
> indicating whether the field needs to be converted to a
> platform-independent byte order.
>

Hi Mimi

the conversion can be done directly by the helper that
field init() functions use for writing data in a buffer,
ima_write_template_field_data(). Since this function takes
the data format as input, for data types like uint32_t
it could perform the conversion before writing a buffer.

Roberto


> Andreas, did you want to post the patch?
>
> thanks,
>
> Mimi
>

Re: [Linux-ima-user] Endianness-dependent IMA field array hash

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

On Thu, 2014-05-01 at 11:07 +0200, Andreas Steffen wrote: 
> Hello,
> 
> just to make it clear. There is no problem with the length
> fields in the raw binary measurement list
> 
>   /sys/kernel/security/ima/binary_runtime_measurements
> 
> being in host order since this list is handled by the local
> Attestation Integrity Measurement Collector (IMC) which
> has the same endianness as the underlying kernel. The
> information which the Attestation IMC includes in the
> integrity report (TCG TNC PTS Binding for the IF-M Protocol)
> is the template hash of each measurement as it was extended into
> PCR 10 (which with a current version 1.2 TPM is a 20 byte SHA-1 value).
> Additional information included in the  integrity report is the
> eventname (a modified absolute filename or boot_aggregate) and the hash
> algorithm with which the file itself was hashed ("sha1:", "sha256",
> etc.).
> 
> My only request is to convert the field lengths into network
> order when they are actually hashed into the final measurement value:
> 
>   u32 field_data_len = htonl(field_data[i].len);
> 
>   rc = crypto_shash_update(&desc.shash,
>               (const u8 *) &field_data_len,
>                sizeof(field_data_len));
> 
> With this simple change the endianness of the client platform doesn't
> have to be included in the integrity report (which would be an awful
> kludge anyway).
> 
> A platform-independent template hash has also the big advantage that
> the measurement values of [non-executable] configuration files would be
> the same on all platforms.

Ok. So for now, only the field length needs to be in a
platform-independent byte order to calculate the template hash.
However, the flexible template format permits us to define new fields,
such as gid/uid, which are included in the hash calculation.  These new
fields might also need to be converted to a platform-independent byte
order for the hash calculation.

Roberto, perhaps in the field definition, itself, we could include a bit
indicating whether the field needs to be converted to a
platform-independent byte order.

Andreas, did you want to post the patch?

thanks,

Mimi

Re: [Linux-ima-user] Endianness-dependent IMA field array hash

[Andreas S. <and...@st...>]

Hello,

just to make it clear. There is no problem with the length
fields in the raw binary measurement list

  /sys/kernel/security/ima/binary_runtime_measurements

being in host order since this list is handled by the local
Attestation Integrity Measurement Collector (IMC) which
has the same endianness as the underlying kernel. The
information which the Attestation IMC includes in the
integrity report (TCG TNC PTS Binding for the IF-M Protocol)
is the template hash of each measurement as it was extended into
PCR 10 (which with a current version 1.2 TPM is a 20 byte SHA-1 value).
Additional information included in the  integrity report is the
eventname (a modified absolute filename or boot_aggregate) and the hash
algorithm with which the file itself was hashed ("sha1:", "sha256",
etc.).

My only request is to convert the field lengths into network
order when they are actually hashed into the final measurement value:

  u32 field_data_len = htonl(field_data[i].len);

  rc = crypto_shash_update(&desc.shash,
              (const u8 *) &field_data_len,
               sizeof(field_data_len));

With this simple change the endianness of the client platform doesn't
have to be included in the integrity report (which would be an awful
kludge anyway).

A platform-independent template hash has also the big advantage that
the measurement values of [non-executable] configuration files would be
the same on all platforms.

Kind regards

Andreas

On 30.04.2014 23:43, Mimi Zohar wrote:
> On Wed, 2014-04-30 at 19:40 +0200, Roberto Sassu wrote: 
>> On 04/30/2014 07:10 PM, Mimi Zohar wrote:
>>> On Wed, 2014-04-30 at 10:34 +0300, Dmitry Kasatkin wrote:
>>>> Hello,
>>>>
>>>>
>>>> On 30 April 2014 09:43, Andreas Steffen <and...@st...> wrote:
>>>>> Hi Mimi,
>>>>>
>>>>> I'm currently updating strongSwan's remote attestation capability
>>>>> to include the new IMA-NG hash formats.
>>>
>>> Nice!
>>>
>>>> While inspecting the IMA
>>>>> source code I noticed that the hash of the template data computed
>>>>> by im_calc_field_array_hash_tfm() in ima_crypto.c depends on the
>>>>> endianness of the host platform:
>>>>>
>>>>>    rc = crypto_shash_update(&desc.shash,
>>>>>                (const u8 *) &field_data[i].len,
>>>>>                 sizeof(field_data[i].len));
>>>>>
>>>>> Since the attestation server reconstructs the template data hash
>>>>> from the SHA-1/SHA-256 file hash and absolute file name stored in
>>>>> the reference database I would be much happier if the 32 bit
>>>>> unsigned integer stored in field_data[i].len would be converted into
>>>>> platform-independent network order before these four bytes are
>>>>> included in the template hash. With the current code the attestation
>>>>> server must know the endianness of each of its clients in order to
>>>>> generate the correct hash value.
>>>>>
>>>
>>> Yes, I'm aware of this issue.
>>>
>>>> It is very good point. Measurement list should not depend on endianness.
>>>
>>> The measurement lists aren't network facing, but consumed by a userspace
>>> application/server.  The question is whether converting the securityfs
>>> binary/ascii measurement lists to network byte order is the
>>> responsibility of the kernel or should this be done by userspace
>>> application/server?
>>>
>>> CC'ing Roberto for his comments, as he's upstreamed OAT patches.
>>>
>>
>> Hi Mimi, all
>>
>> the TCG consortium defined a set of specifications so that
>> measurements can be arranged in a XML document. For IMA measurements
>> we found that the fields 'Type' and 'Image' of the object ValuesType
>> can be used to store respectively the template name and template data
>> in binary format (encoded in base 64).
>>
>> This part of the specifications can be found at the URL:
>>
>> http://www.trustedcomputinggroup.org/files/temp/643D2506-1D09-3519-ADA1A8A4C92A3A98/IWG%20SimpleObject_Schema_Specification_v1.pdf
>>
>> at page 11.
>>
>>
>>  From what I understand, an userspace tool that handles the remote
>> attestation protocol should take raw data as is and store it directly
>> in the integrity report. The advantage to do that is that userspace
>> tools do not need the ability to understand raw data, that are
>> interpreted by an analysis tool after doing the unmarshalling of the
>> report.
>>
>> So, I think that it is better to modify the IMA code to fix this issue.
> 
> Ok.  Besides the field length, is there any other data which should be
> defined in a platform independent format (eg. template_data_len)?
> 
> Mimi
> 
> 
> 

-- 
======================================================================
Andreas Steffen                         and...@st...
strongSwan - the Open Source VPN Solution!          www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==

Re: [Linux-ima-user] Endianness-dependent IMA field array hash

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

On 04/30/2014 11:43 PM, Mimi Zohar wrote:
> On Wed, 2014-04-30 at 19:40 +0200, Roberto Sassu wrote:
>> On 04/30/2014 07:10 PM, Mimi Zohar wrote:
>>> On Wed, 2014-04-30 at 10:34 +0300, Dmitry Kasatkin wrote:
>>>> Hello,
>>>>
>>>>
>>>> On 30 April 2014 09:43, Andreas Steffen <and...@st...> wrote:
>>>>> Hi Mimi,
>>>>>
>>>>> I'm currently updating strongSwan's remote attestation capability
>>>>> to include the new IMA-NG hash formats.
>>>
>>> Nice!
>>>
>>>> While inspecting the IMA
>>>>> source code I noticed that the hash of the template data computed
>>>>> by im_calc_field_array_hash_tfm() in ima_crypto.c depends on the
>>>>> endianness of the host platform:
>>>>>
>>>>>     rc = crypto_shash_update(&desc.shash,
>>>>>                 (const u8 *) &field_data[i].len,
>>>>>                  sizeof(field_data[i].len));
>>>>>
>>>>> Since the attestation server reconstructs the template data hash
>>>>> from the SHA-1/SHA-256 file hash and absolute file name stored in
>>>>> the reference database I would be much happier if the 32 bit
>>>>> unsigned integer stored in field_data[i].len would be converted into
>>>>> platform-independent network order before these four bytes are
>>>>> included in the template hash. With the current code the attestation
>>>>> server must know the endianness of each of its clients in order to
>>>>> generate the correct hash value.
>>>>>
>>>
>>> Yes, I'm aware of this issue.
>>>
>>>> It is very good point. Measurement list should not depend on endianness.
>>>
>>> The measurement lists aren't network facing, but consumed by a userspace
>>> application/server.  The question is whether converting the securityfs
>>> binary/ascii measurement lists to network byte order is the
>>> responsibility of the kernel or should this be done by userspace
>>> application/server?
>>>
>>> CC'ing Roberto for his comments, as he's upstreamed OAT patches.
>>>
>>
>> Hi Mimi, all
>>
>> the TCG consortium defined a set of specifications so that
>> measurements can be arranged in a XML document. For IMA measurements
>> we found that the fields 'Type' and 'Image' of the object ValuesType
>> can be used to store respectively the template name and template data
>> in binary format (encoded in base 64).
>>
>> This part of the specifications can be found at the URL:
>>
>> http://www.trustedcomputinggroup.org/files/temp/643D2506-1D09-3519-ADA1A8A4C92A3A98/IWG%20SimpleObject_Schema_Specification_v1.pdf
>>
>> at page 11.
>>
>>
>>   From what I understand, an userspace tool that handles the remote
>> attestation protocol should take raw data as is and store it directly
>> in the integrity report. The advantage to do that is that userspace
>> tools do not need the ability to understand raw data, that are
>> interpreted by an analysis tool after doing the unmarshalling of the
>> report.
>>
>> So, I think that it is better to modify the IMA code to fix this issue.
>
> Ok.  Besides the field length, is there any other data which should be
> defined in a platform independent format (eg. template_data_len)?
>

Yes. I think also template fields representing integers (like the
inode UID/GID).

A not invasive solution to overcome this problem would be reporting
the endianness of the platform that created measurements in the first
measurement (boot_aggregate), whose format could be extended to
include a new field (other measurements would be still created with
the 'ima-ng' format). A parsing library (e.g. the ima_measure tool
of LTP) could use this information to interpret data and eventually
perform the conversion before returning data to callers.

Roberto


> Mimi
>
>
>

Re: [Linux-ima-user] Endianness-dependent IMA field array hash

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

On Wed, 2014-04-30 at 19:40 +0200, Roberto Sassu wrote: 
> On 04/30/2014 07:10 PM, Mimi Zohar wrote:
> > On Wed, 2014-04-30 at 10:34 +0300, Dmitry Kasatkin wrote:
> >> Hello,
> >>
> >>
> >> On 30 April 2014 09:43, Andreas Steffen <and...@st...> wrote:
> >>> Hi Mimi,
> >>>
> >>> I'm currently updating strongSwan's remote attestation capability
> >>> to include the new IMA-NG hash formats.
> >
> > Nice!
> >
> >> While inspecting the IMA
> >>> source code I noticed that the hash of the template data computed
> >>> by im_calc_field_array_hash_tfm() in ima_crypto.c depends on the
> >>> endianness of the host platform:
> >>>
> >>>    rc = crypto_shash_update(&desc.shash,
> >>>                (const u8 *) &field_data[i].len,
> >>>                 sizeof(field_data[i].len));
> >>>
> >>> Since the attestation server reconstructs the template data hash
> >>> from the SHA-1/SHA-256 file hash and absolute file name stored in
> >>> the reference database I would be much happier if the 32 bit
> >>> unsigned integer stored in field_data[i].len would be converted into
> >>> platform-independent network order before these four bytes are
> >>> included in the template hash. With the current code the attestation
> >>> server must know the endianness of each of its clients in order to
> >>> generate the correct hash value.
> >>>
> >
> > Yes, I'm aware of this issue.
> >
> >> It is very good point. Measurement list should not depend on endianness.
> >
> > The measurement lists aren't network facing, but consumed by a userspace
> > application/server.  The question is whether converting the securityfs
> > binary/ascii measurement lists to network byte order is the
> > responsibility of the kernel or should this be done by userspace
> > application/server?
> >
> > CC'ing Roberto for his comments, as he's upstreamed OAT patches.
> >
> 
> Hi Mimi, all
> 
> the TCG consortium defined a set of specifications so that
> measurements can be arranged in a XML document. For IMA measurements
> we found that the fields 'Type' and 'Image' of the object ValuesType
> can be used to store respectively the template name and template data
> in binary format (encoded in base 64).
> 
> This part of the specifications can be found at the URL:
> 
> http://www.trustedcomputinggroup.org/files/temp/643D2506-1D09-3519-ADA1A8A4C92A3A98/IWG%20SimpleObject_Schema_Specification_v1.pdf
> 
> at page 11.
> 
> 
>  From what I understand, an userspace tool that handles the remote
> attestation protocol should take raw data as is and store it directly
> in the integrity report. The advantage to do that is that userspace
> tools do not need the ability to understand raw data, that are
> interpreted by an analysis tool after doing the unmarshalling of the
> report.
> 
> So, I think that it is better to modify the IMA code to fix this issue.

Ok.  Besides the field length, is there any other data which should be
defined in a platform independent format (eg. template_data_len)?

Mimi

Re: [Linux-ima-user] Endianness-dependent IMA field array hash

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

On 04/30/2014 07:10 PM, Mimi Zohar wrote:
> On Wed, 2014-04-30 at 10:34 +0300, Dmitry Kasatkin wrote:
>> Hello,
>>
>>
>> On 30 April 2014 09:43, Andreas Steffen <and...@st...> wrote:
>>> Hi Mimi,
>>>
>>> I'm currently updating strongSwan's remote attestation capability
>>> to include the new IMA-NG hash formats.
>
> Nice!
>
>> While inspecting the IMA
>>> source code I noticed that the hash of the template data computed
>>> by im_calc_field_array_hash_tfm() in ima_crypto.c depends on the
>>> endianness of the host platform:
>>>
>>>    rc = crypto_shash_update(&desc.shash,
>>>                (const u8 *) &field_data[i].len,
>>>                 sizeof(field_data[i].len));
>>>
>>> Since the attestation server reconstructs the template data hash
>>> from the SHA-1/SHA-256 file hash and absolute file name stored in
>>> the reference database I would be much happier if the 32 bit
>>> unsigned integer stored in field_data[i].len would be converted into
>>> platform-independent network order before these four bytes are
>>> included in the template hash. With the current code the attestation
>>> server must know the endianness of each of its clients in order to
>>> generate the correct hash value.
>>>
>
> Yes, I'm aware of this issue.
>
>> It is very good point. Measurement list should not depend on endianness.
>
> The measurement lists aren't network facing, but consumed by a userspace
> application/server.  The question is whether converting the securityfs
> binary/ascii measurement lists to network byte order is the
> responsibility of the kernel or should this be done by userspace
> application/server?
>
> CC'ing Roberto for his comments, as he's upstreamed OAT patches.
>

Hi Mimi, all

the TCG consortium defined a set of specifications so that
measurements can be arranged in a XML document. For IMA measurements
we found that the fields 'Type' and 'Image' of the object ValuesType
can be used to store respectively the template name and template data
in binary format (encoded in base 64).

This part of the specifications can be found at the URL:

http://www.trustedcomputinggroup.org/files/temp/643D2506-1D09-3519-ADA1A8A4C92A3A98/IWG%20SimpleObject_Schema_Specification_v1.pdf

at page 11.


 From what I understand, an userspace tool that handles the remote
attestation protocol should take raw data as is and store it directly
in the integrity report. The advantage to do that is that userspace
tools do not need the ability to understand raw data, that are
interpreted by an analysis tool after doing the unmarshalling of the
report.

So, I think that it is better to modify the IMA code to fix this issue.

Roberto


> thanks,
>
> Mimi
>
>>> Since the IMA-NG code has already been released with the 3.13 kernel
>>> I don't know if it is possible to include my proposed change.
>>> It would make life really much easier!
>>>
>>
>> It should be possible. I do not think it is so widely used "format"
>> now to allow it.
>> Other packages can be fixed...
>
>

Re: [Linux-ima-user] Endianness-dependent IMA field array hash

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

On Wed, 2014-04-30 at 10:34 +0300, Dmitry Kasatkin wrote: 
> Hello,
> 
> 
> On 30 April 2014 09:43, Andreas Steffen <and...@st...> wrote:
> > Hi Mimi,
> >
> > I'm currently updating strongSwan's remote attestation capability
> > to include the new IMA-NG hash formats.

Nice!

> While inspecting the IMA
> > source code I noticed that the hash of the template data computed
> > by im_calc_field_array_hash_tfm() in ima_crypto.c depends on the
> > endianness of the host platform:
> >
> >   rc = crypto_shash_update(&desc.shash,
> >               (const u8 *) &field_data[i].len,
> >                sizeof(field_data[i].len));
> >
> > Since the attestation server reconstructs the template data hash
> > from the SHA-1/SHA-256 file hash and absolute file name stored in
> > the reference database I would be much happier if the 32 bit
> > unsigned integer stored in field_data[i].len would be converted into
> > platform-independent network order before these four bytes are
> > included in the template hash. With the current code the attestation
> > server must know the endianness of each of its clients in order to
> > generate the correct hash value.
> >

Yes, I'm aware of this issue.

> It is very good point. Measurement list should not depend on endianness.

The measurement lists aren't network facing, but consumed by a userspace
application/server.  The question is whether converting the securityfs
binary/ascii measurement lists to network byte order is the
responsibility of the kernel or should this be done by userspace
application/server?

CC'ing Roberto for his comments, as he's upstreamed OAT patches.

thanks,

Mimi 

> > Since the IMA-NG code has already been released with the 3.13 kernel
> > I don't know if it is possible to include my proposed change.
> > It would make life really much easier!
> >
> 
> It should be possible. I do not think it is so widely used "format"
> now to allow it.
> Other packages can be fixed...

Re: [Linux-ima-user] Endianness-dependent IMA field array hash

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

Hello,


On 30 April 2014 09:43, Andreas Steffen <and...@st...> wrote:
> Hi Mimi,
>
> I'm currently updating strongSwan's remote attestation capability
> to include the new IMA-NG hash formats. While inspecting the IMA
> source code I noticed that the hash of the template data computed
> by im_calc_field_array_hash_tfm() in ima_crypto.c depends on the
> endianness of the host platform:
>
>   rc = crypto_shash_update(&desc.shash,
>               (const u8 *) &field_data[i].len,
>                sizeof(field_data[i].len));
>
> Since the attestation server reconstructs the template data hash
> from the SHA-1/SHA-256 file hash and absolute file name stored in
> the reference database I would be much happier if the 32 bit
> unsigned integer stored in field_data[i].len would be converted into
> platform-independent network order before these four bytes are
> included in the template hash. With the current code the attestation
> server must know the endianness of each of its clients in order to
> generate the correct hash value.
>

It is very good point. Measurement list should not depend on endianness.


> Since the IMA-NG code has already been released with the 3.13 kernel
> I don't know if it is possible to include my proposed change.
> It would make life really much easier!
>

It should be possible. I do not think it is so widely used "format"
now to allow it.
Other packages can be fixed...

- Dmitry

> Best regards
>
> Andreas
>
> ======================================================================
> Andreas Steffen                         and...@st...
> strongSwan - the Open Source VPN Solution!          www.strongswan.org
> Institute for Internet Technologies and Applications
> University of Applied Sciences Rapperswil
> CH-8640 Rapperswil (Switzerland)
> ===========================================================[ITA-HSR]==
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.  Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Linux-ima-user mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-ima-user
>



-- 
Thanks,
Dmitry

[Linux-ima-user] Endianness-dependent IMA field array hash

[Andreas S. <and...@st...>]

Hi Mimi,

I'm currently updating strongSwan's remote attestation capability
to include the new IMA-NG hash formats. While inspecting the IMA
source code I noticed that the hash of the template data computed
by im_calc_field_array_hash_tfm() in ima_crypto.c depends on the
endianness of the host platform:

  rc = crypto_shash_update(&desc.shash,
              (const u8 *) &field_data[i].len,
               sizeof(field_data[i].len));

Since the attestation server reconstructs the template data hash
from the SHA-1/SHA-256 file hash and absolute file name stored in
the reference database I would be much happier if the 32 bit
unsigned integer stored in field_data[i].len would be converted into
platform-independent network order before these four bytes are
included in the template hash. With the current code the attestation
server must know the endianness of each of its clients in order to
generate the correct hash value.

Since the IMA-NG code has already been released with the 3.13 kernel
I don't know if it is possible to include my proposed change.
It would make life really much easier!

Best regards

Andreas

======================================================================
Andreas Steffen                         and...@st...
strongSwan - the Open Source VPN Solution!          www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==

[Linux-ima-user] oraphaned keywords in audit log text [was: Re: [PATCH] integrity: get comm using lock to avoid race in string] printing

[Richard G. B. <rg...@re...>]

On 14/04/02, Mimi Zohar wrote:
> On Wed, 2014-04-02 at 14:18 -0400, Eric Paris wrote: 
> > On Wed, 2014-04-02 at 14:12 -0400, Mimi Zohar wrote:
> > > On Wed, 2014-04-02 at 14:00 -0400, Steve Grubb wrote: 
> > > > Hello Mimi,
> > > > 
> > > > On Wednesday, April 02, 2014 01:39:47 PM Mimi Zohar wrote:
> > > > > This change is already being upstreamed as commit 73a6b44 "Integrity:
> > > > > Pass commname via get_task_comm()".
> > > > 
> > > > While I was looking at Richard's patch, I noticed a few places where cause and 
> > > > op are logged and the string isn't tied together with a _ or -. These are in 
> > > > ima/ima_appraise.c line 383, and ima/ima_policy.c lines 333, 657, and 683. Are 
> > > > these fixed upstream? Or should a patch be made?
> > > 
> > > Nothing has changed in terms of 'cause' and 'op'.  I would suggest
> > > making the changes in integrity_audit.c: integrity_audit_msg().

That function could massage incoming text fields and convert spaces to
hyphens or underscores, but I'd assume the right place to do it would be
in the original text.  If you suggest the former, it could just be done
in audit_log_string(), but then grepping the source for error messages
would not be nearly as useful.  Is this what you were suggesting?

> > The question is actually, do you know of anyone who is expecting the
> > space, instead of a more 'audit standard' - or _ ?  If not, we'll change
> > it.  If so, we'll discuss more   :)
> 
> CC'ing linux-ima-user as well.

Thanks.

> Mimi

- RGB

--
Richard Guy Briggs <rb...@re...>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545

Re: [Linux-ima-user] [PATCH] integrity: get comm using lock to avoid race in string printing

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

On Wed, 2014-04-02 at 14:18 -0400, Eric Paris wrote: 
> On Wed, 2014-04-02 at 14:12 -0400, Mimi Zohar wrote:
> > On Wed, 2014-04-02 at 14:00 -0400, Steve Grubb wrote: 
> > > Hello Mimi,
> > > 
> > > On Wednesday, April 02, 2014 01:39:47 PM Mimi Zohar wrote:
> > > > This change is already being upstreamed as commit 73a6b44 "Integrity:
> > > > Pass commname via get_task_comm()".
> > > 
> > > While I was looking at Richard's patch, I noticed a few places where cause and 
> > > op are logged and the string isn't tied together with a _ or -. These are in 
> > > ima/ima_appraise.c line 383, and ima/ima_policy.c lines 333, 657, and 683. Are 
> > > these fixed upstream? Or should a patch be made?
> > 
> > Nothing has changed in terms of 'cause' and 'op'.  I would suggest
> > making the changes in integrity_audit.c: integrity_audit_msg().
> 
> The question is actually, do you know of anyone who is expecting the
> space, instead of a more 'audit standard' - or _ ?  If not, we'll change
> it.  If so, we'll discuss more   :)

CC'ing linux-ima-user as well.

Mimi

Re: [Linux-ima-user] [Help]How to start learning IMA source code?

[Youren S. <she...@gm...>]

Hi,

Thank you very much, I'm so impatient and did not take a careful look about
the wiki page, It's my fault.

Thank you for your reply and now I understand some  problem which confused
me for a long time.

I will take a look about the wiki page and other doc, Thank you very much.

-- 
Best Regards.
Youren Shen.

Re: [Linux-ima-user] [Help]How to start learning IMA source code?

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

On Mon, 2014-03-31 at 14:53 +0300, Dmitry Kasatkin wrote: 
> On 30/03/14 18:44, Youren Shen wrote:
> > Hi, Dmitry:
> >
> > Thank you for you reply.
> > Sorry for so later to reply.
> > Even in the early Linux 3.0, there  is no apprised module. If the
> > apprised module is absent, how did the IMA keep the system secure? 
> > How did the arrest module work? By integrity reporting?
> > "This list can be examined by a (possibly remote) program to ensure
> > that no unknown or known-vulnerable applications have been run.", said
> > in this page[1].  *What's this program? Is it implement by user space
> > application developer or kernel hacker?*
> > The IMA will keep the system secure before a program execute, or when
> > a program is execute, the IMA will keep the program secure?
> >
> > Thank you very much. 
> >
> > [1]. https://lwn.net/Articles/137306/
> >
> >
> > -- 
> > Best Regards.
> > Youren Shen.
> 
> Hi,
> 
> I recommend you to look to Integrity subsystem wiki:
> http://sourceforge.net/p/linux-ima/wiki/Home
> 
> I provides lots of information.
> 
> IMA itself does not prevent program from execution.
> IMA just measures files, specified by the policy.
> Along the runtime IMA is building up measurement list which can be read
> via sysfs entry.
> 
> The key component is TPM.
> TPM PCR register is extended by IMA measurements.
> TPM allows remotely verify measurement list.
> TPM allows to sign IMA PCR register with special attestation private key
> and that signature can be verified by remote attestation service.
> Remote attestation service will have attestation public key.
> 
> 
> Please have a look to the wiki.

In particular, take a look at the overview section, which contains a
time line of when the different features were upstreamed and a reference
to the whitepaper describing the goals, design, and benefits of these
features.

Mimi

Re: [Linux-ima-user] [Help]How to start learning IMA source code?

[Dmitry K. <d.k...@sa...>]

On 30/03/14 18:44, Youren Shen wrote:
> Hi, Dmitry:
>
> Thank you for you reply.
> Sorry for so later to reply.
> Even in the early Linux 3.0, there  is no apprised module. If the
> apprised module is absent, how did the IMA keep the system secure? 
> How did the arrest module work? By integrity reporting?
> "This list can be examined by a (possibly remote) program to ensure
> that no unknown or known-vulnerable applications have been run.", said
> in this page[1].  *What's this program? Is it implement by user space
> application developer or kernel hacker?*
> The IMA will keep the system secure before a program execute, or when
> a program is execute, the IMA will keep the program secure?
>
> Thank you very much. 
>
> [1]. https://lwn.net/Articles/137306/
>
>
> -- 
> Best Regards.
> Youren Shen.

Hi,

I recommend you to look to Integrity subsystem wiki:
http://sourceforge.net/p/linux-ima/wiki/Home

I provides lots of information.

IMA itself does not prevent program from execution.
IMA just measures files, specified by the policy.
Along the runtime IMA is building up measurement list which can be read
via sysfs entry.

The key component is TPM.
TPM PCR register is extended by IMA measurements.
TPM allows remotely verify measurement list.
TPM allows to sign IMA PCR register with special attestation private key
and that signature can be verified by remote attestation service.
Remote attestation service will have attestation public key.


Please have a look to the wiki.

- Dmitry

Re: [Linux-ima-user] [Help]How to start learning IMA source code?

[Youren S. <she...@gm...>]

Hi, Dmitry:

Thank you for you reply.
Sorry for so later to reply.
Even in the early Linux 3.0, there  is no apprised module. If the apprised
module is absent, how did the IMA keep the system secure?
How did the arrest module work? By integrity reporting?
"This list can be examined by a (possibly remote) program to ensure that no
unknown or known-vulnerable applications have been run.", said in this
page[1].  *What's this program? Is it implement by user space application
developer or kernel hacker?*
The IMA will keep the system secure before a program execute, or when a
program is execute, the IMA will keep the program secure?

Thank you very much.

[1]. https://lwn.net/Articles/137306/


-- 
Best Regards.
Youren Shen.

Re: [Linux-ima-user] [Help]How to start learning IMA source code?

[Dmitry K. <d.k...@sa...>]

Hi,

Yes. Many new functionality came in 3.x kernels..

- Dmitry

On 24/03/14 09:18, Youren Shen wrote:
> Hi,Mimi:
>
> Thank you for your reply, It's really helpful.
>
> However, There is no ima_appraise_measurement in linux-2.6.30. Does
> this means that IMA of this version is incomplete ?
>
>
> -- 
> Best Regards.
> Youren Shen.
>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
>
>
> _______________________________________________
> Linux-ima-user mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-ima-user

Re: [Linux-ima-user] [Help]How to start learning IMA source code?

[Youren S. <she...@gm...>]

Hi,Mimi:

Thank you for your reply, It's really helpful.

However, There is no ima_appraise_measurement in linux-2.6.30. Does this
means that IMA of this version is incomplete ?


-- 
Best Regards.
Youren Shen.

Re: [Linux-ima-user] [Help]How to start learning IMA source code?

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

On Sat, 2014-03-22 at 21:55 +0800, Youren Shen wrote: 
> Hi,everyone:
> 
> I'm a student in college and I'm trying to leaning IMA in linux. I have
> read the the part about integrity measurement in [1].

Have you looked at the linux-ima or Gentoo wiki.  There are also a
number of LWN articles and Linux Security Summit(LSS) slides as well.

> Now I suffer some problem when I start to reading the IMA's  source code in
> Linux 2.6.30,(I consider a previous version maybe simple and more suitable
> to start learning). I can easily understand the relations between
> ima_template_entry and ima_queue_entry, But I don't understand the use of
> iint. I am also confused the digests and their relations. Why we need so
> much digest (If I'm right ,There is four
> digest,ima->digest,ima->template.digest,iint->digest,and one in PCR). I
> thought I should figure this out so I can understand how IMA assert one
> file is not safe by compare digests.

The iint contains integrity information associated with an inode, but is
freed along with the inode.

ima_collect_measurement(): calculates the file data hash, storing it in
the iint.
ima_store_measurement(): the file hash stored in the iint is preserved
by copying it to the measurement list and extending the PCR value.
ima_appraise_measurement(): compares the file hash stored in the iint
with the existing 'good' value stored in the extended attribute.

Mimi

[Linux-ima-user] [Help]How to start learning IMA source code?

[Youren S. <she...@gm...>]

Hi,everyone:

I'm a student in college and I'm trying to leaning IMA in linux. I have
read the the part about integrity measurement in [1].

Now I suffer some problem when I start to reading the IMA's  source code in
Linux 2.6.30,(I consider a previous version maybe simple and more suitable
to start learning). I can easily understand the relations between
ima_template_entry and ima_queue_entry, But I don't understand the use of
iint. I am also confused the digests and their relations. Why we need so
much digest (If I'm right ,There is four
digest,ima->digest,ima->template.digest,iint->digest,and one in PCR). I
thought I should figure this out so I can understand how IMA assert one
file is not safe by compare digests.

These is just a part of my confusion but it's most essential for me now.
I'm not seek someone who can answer every question from me, but I search
the wiki of IMA and Google, It's turn out there is too few doc to introduce
the IMA in Linux. So, if there anyone who can give me some guide, It will
be really helpful.

Thanks all of you.

[1]. TCG, "Specification Architecture Overview, Version 1.4."

-- 
Best Regards.
Youren Shen.

Re: [Linux-ima-user] Reliability of IMA/EVM against power failure

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

On Thu, 2014-02-27 at 12:51 -0500, Mimi Zohar wrote: 
> On Thu, 2014-02-27 at 16:46 +0000, Lipinski, MarekX wrote:
> > Hi,
> > 
> > I was wondering what are the possible problems for the IMA
> > appraise/EVM-enabled system in case of sudden power failure or system
> > crash.
> > 
> > Is it possible that we end up having a new content written to the file
> > and IMA or EVM hash not correctly updated causing Permission denied
> > after reboot?
> > Assuming file system integrity is ok or it was fixed by the fsck.
> 
> Right, any new or modified file would need to be relabeled, if the file
> wasn't closed properly.  Currently, fixing the 'security.evm' xattr
> requires loading the EVM key and booting in fix mode.  This would land
> up fixing all problems.  I'm thinking we probably want something in
> between fixing everything to fixing specific files.

Then again, we wouldn't be able to differentiate between a failure or an
attack.  Accessing the file via the file system should be prevented, but
an admin, with privilege, would still be able to access the file via the
raw device.

Mimi

Re: [Linux-ima-user] Reliability of IMA/EVM against power failure

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

On Thu, 2014-02-27 at 16:46 +0000, Lipinski, MarekX wrote:
> Hi,
> 
> I was wondering what are the possible problems for the IMA
> appraise/EVM-enabled system in case of sudden power failure or system
> crash.
> 
> Is it possible that we end up having a new content written to the file
> and IMA or EVM hash not correctly updated causing Permission denied
> after reboot?
> Assuming file system integrity is ok or it was fixed by the fsck.

Right, any new or modified file would need to be relabeled, if the file
wasn't closed properly.  Currently, fixing the 'security.evm' xattr
requires loading the EVM key and booting in fix mode.  This would land
up fixing all problems.  I'm thinking we probably want something in
between fixing everything to fixing specific files.

Mimi

[Linux-ima-user] Reliability of IMA/EVM against power failure

[Lipinski, M. <mar...@in...>]

Hi,

I was wondering what are the possible problems for the IMA appraise/EVM-enabled system in case of sudden power failure or system crash.

Is it possible that we end up having a new content written to the file and IMA or EVM hash not correctly updated causing Permission denied after reboot?
Assuming file system integrity is ok or it was fixed by the fsck.

Regards,
Marek

Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

Re: [Linux-ima-user] Newbie question

[Olga C. <ol...@gm...>]

Mimi,
Thanks so much for the reply! If anyone does have a sample policy, both
appraisal and measuring, it would really helpful!

thanks,
Olga

-- per aspera ad astra --


On Fri, Feb 21, 2014 at 2:33 PM, Mimi Zohar <zo...@li...>wrote:

> On Fri, 2014-02-21 at 10:12 -0500, Olga Chen wrote:
> > Hello everyone.
> > I apologize in advance for a newbie question.
> >
> > I have a RHEL 6 machine, and I am currently looking to replace tripwire
> > with IMA, so I have some questions.
>
> > My goal is to have local integrity verification (and notification of
> > failure to verify) for a certain number of files plus anything that is
> part
> > of the default IMA policy is OK too.
>
> So, the first thing you'll need to do is define a policy.  Both
> measuring and appraising files are policy based.  The new wiki
> ima-policy-examples section contains a few basic policies.
>
> [Side note: anyone using IMA/IMA-appraisal, please consider posting the
> policy here for others.]
>
> > I am not interested in remote attestation.
>
> Ok
>
> > I've been reading the Linux-IMA wiki, and it looks like I would need to
> > have IMA, IMA-Appraisal, and IMA-EVM enabled to achieve this. The last
> two
> > will require me to recompile the kernel.
>
> > Does this sound right to everyone? I am enabling the right things?
> > I would really appreciate any feedback/suggestions.
>
> To enforce local file integrity requires enabling just IMA-appraisal
> and, probably, EVM.
>
> Mimi
>
>

Re: [Linux-ima-user] Newbie question

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

On Fri, 2014-02-21 at 10:12 -0500, Olga Chen wrote: 
> Hello everyone.
> I apologize in advance for a newbie question.
> 
> I have a RHEL 6 machine, and I am currently looking to replace tripwire
> with IMA, so I have some questions.

> My goal is to have local integrity verification (and notification of
> failure to verify) for a certain number of files plus anything that is part
> of the default IMA policy is OK too.

So, the first thing you'll need to do is define a policy.  Both
measuring and appraising files are policy based.  The new wiki
ima-policy-examples section contains a few basic policies.

[Side note: anyone using IMA/IMA-appraisal, please consider posting the
policy here for others.]

> I am not interested in remote attestation.

Ok

> I've been reading the Linux-IMA wiki, and it looks like I would need to
> have IMA, IMA-Appraisal, and IMA-EVM enabled to achieve this. The last two
> will require me to recompile the kernel.

> Does this sound right to everyone? I am enabling the right things?
> I would really appreciate any feedback/suggestions.

To enforce local file integrity requires enabling just IMA-appraisal
and, probably, EVM.

Mimi

[Linux-ima-user] Newbie question

[Olga C. <ol...@gm...>]

Hello everyone.
I apologize in advance for a newbie question.

I have a RHEL 6 machine, and I am currently looking to replace tripwire
with IMA, so I have some questions.
My goal is to have local integrity verification (and notification of
failure to verify) for a certain number of files plus anything that is part
of the default IMA policy is OK too.
I am not interested in remote attestation.
I've been reading the Linux-IMA wiki, and it looks like I would need to
have IMA, IMA-Appraisal, and IMA-EVM enabled to achieve this. The last two
will require me to recompile the kernel.
Does this sound right to everyone? I am enabling the right things?
I would really appreciate any feedback/suggestions.

thanks,
Olga