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

[Linux-ima-user] example policy for appraisal with read/write files (was: Re: IMA (latest patches) do not allow creation of in policy files.)

[Patrick O. <pat...@in...>]

Hello Curtis!

Thanks for sharing your policy with the list. I found that very helpful.
May I ask some questions about it?

Is the appraisal part supposed to protect against offline attacks (i.e.
device turned off, partition mounted and modified)? What do you expect
to happen when that occurs?

You probably use both IMA and EVM, right?

My expectation is that a device protected by appraisal refuses access to
files that an attacker has tampered with while offline, without relying
on measurements and a remote service that checks these measurements.
Otherwise, what would be the benefit of appraisal?

For example, suppose there is a data file read by the init process (for
systemd, /lib/systemd/system/systemd-networkd.service would be a
specific example). I can think of two approaches how an attacker could
get systemd to use a modified file (for example, one which
invokes /bin/sh on a shell script which then runs as root).

     1. Edit the file, change owner from root:root to some other owner.
        Because appraisal is limited to files owned by certain groups,
        it is no longer covered by the policy and thus access is granted
        despite the modified content.
     2. Replace the file with a symlink to a file on the special
        partitions, modify it there.

Symlinks are explicitly allowed by systemd, and I also don't expect that
it cares about file ownership, so I don't see how such an attack would
be prevented. Do I miss anything?

On Mon, 2015-06-22 at 11:03 -0600, Curtis Veit wrote:
> -------------------------------------------------------------------------
> # Default Rules
> dont_measure fsmagic=0x9fa0
> dont_appraise fsmagic=0x9fa0
> dont_measure fsmagic=0x62656572
> dont_appraise fsmagic=0x62656572
> dont_measure fsmagic=0x64626720
> dont_appraise fsmagic=0x64626720
> dont_measure fsmagic=0x01021994
> dont_appraise fsmagic=0x01021994
> dont_measure fsmagic=0x858458f6
> dont_appraise fsmagic=0x858458f6
> dont_measure fsmagic=0x73636673
> dont_appraise fsmagic=0x73636673
> #
> # Special partition
> dont_measure  fsuuid=a11234...
> dont_appraise fsuuid=a11243...
> 
> # Special immutable group 
> appraise appraise_type=imasig func=FILE_CHECK mask=MAY_READ fgroup=200
> 
> # this area allows hashed executables
> appraise func=FILE_MMAP  mask=MAY_EXEC fsuuid=0761e0f1...
> appraise func=BPRM_CHECK mask=MAY_EXEC fsuuid=0761e0f1...
> #
> # All executables must be signed
> appraise appraise_type=imasig func=FILE_MMAP mask=MAY_EXEC
> appraise appraise_type=imasig func=BPRM_CHECK mask=MAY_EXEC
> #
> # Attempt to avoid log and cache file (etc) 
> # This may belong above the previous appraise group
> # sda7=/tmp sda8=/var
> dont_measure  fsuuid=ac010c7... this is /tmp
> dont_appraise fsuuid=ac010c7... 
> dont_measure  fsuuid=...        this is /var 
> dont_appraise fsuuid=...
> 
> # Is there a better way to handle the text based log files 
> # that linux creates?
> 
> # Using groups instead of uid mainly for testing
> # gid functionality
> # group root = 0 may want to go by owner or group?
> # group shadow = 42 needed if above not by owner
> measure func=FILE_CHECK mask=MAY_READ fgroup=0
> appraise func=FILE_CHECK mask=MAY_READ fgroup=0
> measure func=FILE_CHECK mask=MAY_READ fgroup=42
> appraise func=FILE_CHECK mask=MAY_READ fgroup=42
> #
> # non-root group to protect with hashes = 201
> # also protect www-data group = 33
> measure func=FILE_CHECK mask=MAY_READ fgroup=33
> appraise func=FILE_CHECK mask=MAY_READ fgroup=33
> measure func=FILE_CHECK mask=MAY_READ fgroup=201
> appraise func=FILE_CHECK mask=MAY_READ fgroup=201
> #
> # remaining default rules 
> measure func=BPRM_CHECK
> measure func=MODULE_CHECK
> measure func=FIRMWARE_CHECK

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: [Linux-ima-user] Boot options to log the hash of every executable?

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

On Mon, 2015-07-27 at 11:54 -0700, Ben Scarlato wrote:
> Hello,
> 
> Is there a way to get IMA to log the hash of every file executed without
> using a custom policy?
> 
> I'd like to log the hash of every file executed on a system, and produce
> audit log messages such as:
> 
> *type=INTEGRITY_RULE msg=audit(1437966844.301:162811): file="/usr/bin/less"
> hash="sha1:c0ddf750a49a96e69173c772747ffd4467fa5d89" ….*
> 
> 
> I know you can set this up using a custom policy with rules along the lines
> of  “*audit func=BPRM_CHECK **mask=MAY_EXEC*”, but I'm exploring using IMA
> on a read-only filesystem. For instance, in CoreOS <https://coreos.com/>
> most of the filesystem is read-only and I haven't been able to successfully
> load a custom policy.
> 
> I'm wondering if there's any options that can be used with either the
> ima_tcb or ima_appraise_tcb policies to log hashes. I've tried a few
> different setups, and while I can trigger audit messages on file execution,
> I just see INTEGRITY_DATA messages without a hash and a field saying
> *cause=“missing-hash”*.
> 
> Can boot command line options or kernel configuration produce
> INTEGRITY_RULE hashes without requiring a custom policy?

The "audit" rule is not in either of the builtin policies.  The ima_tcb
policy measures all executables, files mmapped, and files read by root.
These measurements are stored in memory and can be displayed by cat'ing
<security>/ima/ascii_runtime_measurements. 

Mimi

[Linux-ima-user] Boot options to log the hash of every executable?

[Ben S. <ak...@go...>]

Hello,

Is there a way to get IMA to log the hash of every file executed without
using a custom policy?

I'd like to log the hash of every file executed on a system, and produce
audit log messages such as:

*type=INTEGRITY_RULE msg=audit(1437966844.301:162811): file="/usr/bin/less"
hash="sha1:c0ddf750a49a96e69173c772747ffd4467fa5d89" ….*


I know you can set this up using a custom policy with rules along the lines
of  “*audit func=BPRM_CHECK **mask=MAY_EXEC*”, but I'm exploring using IMA
on a read-only filesystem. For instance, in CoreOS <https://coreos.com/>
most of the filesystem is read-only and I haven't been able to successfully
load a custom policy.

I'm wondering if there's any options that can be used with either the
ima_tcb or ima_appraise_tcb policies to log hashes. I've tried a few
different setups, and while I can trigger audit messages on file execution,
I just see INTEGRITY_DATA messages without a hash and a field saying
*cause=“missing-hash”*.

Can boot command line options or kernel configuration produce
INTEGRITY_RULE hashes without requiring a custom policy?

Thanks!

Re: [Linux-ima-user] looking for suggestions on rule use

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

On Tue, 2015-07-14 at 20:10 +0200, Patrick Ohly wrote:
> On Tue, 2015-07-14 at 11:53 -0400, Mimi Zohar wrote:
> > On Tue, 2015-07-14 at 17:11 +0200, Patrick Ohly wrote:
> > > On Tue, 2015-07-14 at 09:52 -0400, Mimi Zohar wrote:
> > > > On Tue, 2015-07-14 at 15:44 +0200, Patrick Ohly wrote:
> > > > > Then the only appraisal rule is:
> > > > > 
> > > > >         # Appraise all operations on files with floor label.
> > > > >         appraise obj_user=_
> > > > > 
> > > > > But IMHO such a system is not really secure, because an attacker could
> > > > > simply turn a protected file (label _) into an unprotected one (label
> > > > > System), either at runtime or offline. System services then wouldn't
> > > > > notice a difference (they can read System files just like _ files) and
> > > > > use a potentially modified file.
> > > > > 
> > > > > Do I miss something here or is my conclusion correct?
> > > > 
> > > > On a running system with Smack enabled, Smack should be limiting who can
> > > > modify security xattrs.
> > > 
> > > There will be privileged processes which can modify the Smack label; if
> > > an attacker manages to take control of those, they could disable IMA.
> > 
> > No, changing the xattr doesn't disable IMA nor affect the existing
> > policy.  If your policy measures/appraises everything, then the file
> > would still be measured/appraised appropriately.
> 
> But it doesn't appraise everything - that was exactly my concern about a
> policy with just the one rule above.

When discussing this issue with Dave Safford,  Dave reminded me that the
EVM function evm_verifyxattr() is exported and could be called from the
LSM to verify that its security xattr hasn't been modified.

> > > My understanding was that by requiring signing and not having private
> > > keys on the device, such a breach could be detected even for privileged
> > > processes.

The comment refers to any file changes or new "malicious" files being
included in the measurement list should be detected by attestation.
Detecting an LSM xattr change would require a measurement list template
that includes the xattr.

Mimi

Re: [Linux-ima-user] looking for suggestions on rule use

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

[CC'ing Dmitry this time]

On Thu, 2015-07-16 at 10:22 -0400, Mimi Zohar wrote:
> On Wed, 2015-07-15 at 08:52 +0200, Patrick Ohly wrote:
> > On Tue, 2015-07-14 at 16:59 -0400, Mimi Zohar wrote:
> > > On Tue, 2015-07-14 at 20:10 +0200, Patrick Ohly wrote:
> > > > The problem which keeps coming up is that such a policy is not practical
> > > > when root processes are meant to modify files on the device.
> > > 
> > > Even if root was modifying files, it isn't modifying all files.
> > > Normally it's limited to configuration files.   The above BPRM_CHECK
> > > rule verifies executables.
> > 
> > Do you have an example of a complete policy using that?
> 
> [CC'ing Dmitry for his comments.]
> 
> It really depends on your environment and what you want to achieve.
> 
> Try using the built-in policy, but add a BPRM_CHECK rule to require file
> signatures, before the existing appraisal rule.
> 
> eg. appraise fowner=0 func=BPRM_CHECK appraise_type=imasig
> 
> Mimi

Re: [Linux-ima-user] looking for suggestions on rule use

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

On Wed, 2015-07-15 at 08:52 +0200, Patrick Ohly wrote:
> On Tue, 2015-07-14 at 16:59 -0400, Mimi Zohar wrote:
> > On Tue, 2015-07-14 at 20:10 +0200, Patrick Ohly wrote:
> > > The problem which keeps coming up is that such a policy is not practical
> > > when root processes are meant to modify files on the device.
> > 
> > Even if root was modifying files, it isn't modifying all files.
> > Normally it's limited to configuration files.   The above BPRM_CHECK
> > rule verifies executables.
> 
> Do you have an example of a complete policy using that?

[CC'ing Dmitry for his comments.]

It really depends on your environment and what you want to achieve.

Try using the built-in policy, but add a BPRM_CHECK rule to require file
signatures, before the existing appraisal rule.

eg. appraise fowner=0 func=BPRM_CHECK appraise_type=imasig

Mimi

Re: [Linux-ima-user] looking for suggestions on rule use

[Patrick O. <pat...@in...>]

On Tue, 2015-07-14 at 16:59 -0400, Mimi Zohar wrote:
> On Tue, 2015-07-14 at 20:10 +0200, Patrick Ohly wrote:
> > The problem which keeps coming up is that such a policy is not practical
> > when root processes are meant to modify files on the device.
> 
> Even if root was modifying files, it isn't modifying all files.
> Normally it's limited to configuration files.   The above BPRM_CHECK
> rule verifies executables.

Do you have an example of a complete policy using that?

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: [Linux-ima-user] looking for suggestions on rule use

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

On Tue, 2015-07-14 at 20:10 +0200, Patrick Ohly wrote:
> On Tue, 2015-07-14 at 11:53 -0400, Mimi Zohar wrote:
> > On Tue, 2015-07-14 at 17:11 +0200, Patrick Ohly wrote:
> > > On Tue, 2015-07-14 at 09:52 -0400, Mimi Zohar wrote:
> > > > On Tue, 2015-07-14 at 15:44 +0200, Patrick Ohly wrote:
> > > > > Then the only appraisal rule is:
> > > > > 
> > > > >         # Appraise all operations on files with floor label.
> > > > >         appraise obj_user=_
> > > > > 
> > > > > But IMHO such a system is not really secure, because an attacker could
> > > > > simply turn a protected file (label _) into an unprotected one (label
> > > > > System), either at runtime or offline. System services then wouldn't
> > > > > notice a difference (they can read System files just like _ files) and
> > > > > use a potentially modified file.
> > > > > 
> > > > > Do I miss something here or is my conclusion correct?
> > > > 
> > > > On a running system with Smack enabled, Smack should be limiting who can
> > > > modify security xattrs.
> > > 
> > > There will be privileged processes which can modify the Smack label; if
> > > an attacker manages to take control of those, they could disable IMA.
> > 
> > No, changing the xattr doesn't disable IMA nor affect the existing
> > policy.  If your policy measures/appraises everything, then the file
> > would still be measured/appraised appropriately.
> 
> But it doesn't appraise everything - that was exactly my concern about a
> policy with just the one rule above.
> 
> > > My understanding was that by requiring signing and not having private
> > > keys on the device, such a breach could be detected even for privileged
> > > processes.
> > 
> > The rule "appraise fowner=0 func=BPRM_CHECK appraise_type=imasig"
> > requires all files owned by root to be signed.  Signed files in policy
> > are considered "immutable".
> 
> The problem which keeps coming up is that such a policy is not practical
> when root processes are meant to modify files on the device.

Even if root was modifying files, it isn't modifying all files.
Normally it's limited to configuration files.   The above BPRM_CHECK
rule verifies executables.

Mimi

> > > If an attacker changes the Smack label, EVM indeed becomes invalid, but
> > > because the Smack label was changed, the appraise rule no longer matches
> > > and the kernel will not raise any error when using the modified file,
> > > will it?
> > 
> > Right, so the issue is defining an appropriate policy.  If you can't
> > trust the Smack labels, then don't write a policy based on them.
> 
> Agreed.
> 

Re: [Linux-ima-user] looking for suggestions on rule use

[Patrick O. <pat...@in...>]

On Tue, 2015-07-14 at 11:53 -0400, Mimi Zohar wrote:
> On Tue, 2015-07-14 at 17:11 +0200, Patrick Ohly wrote:
> > On Tue, 2015-07-14 at 09:52 -0400, Mimi Zohar wrote:
> > > On Tue, 2015-07-14 at 15:44 +0200, Patrick Ohly wrote:
> > > > Then the only appraisal rule is:
> > > > 
> > > >         # Appraise all operations on files with floor label.
> > > >         appraise obj_user=_
> > > > 
> > > > But IMHO such a system is not really secure, because an attacker could
> > > > simply turn a protected file (label _) into an unprotected one (label
> > > > System), either at runtime or offline. System services then wouldn't
> > > > notice a difference (they can read System files just like _ files) and
> > > > use a potentially modified file.
> > > > 
> > > > Do I miss something here or is my conclusion correct?
> > > 
> > > On a running system with Smack enabled, Smack should be limiting who can
> > > modify security xattrs.
> > 
> > There will be privileged processes which can modify the Smack label; if
> > an attacker manages to take control of those, they could disable IMA.
> 
> No, changing the xattr doesn't disable IMA nor affect the existing
> policy.  If your policy measures/appraises everything, then the file
> would still be measured/appraised appropriately.

But it doesn't appraise everything - that was exactly my concern about a
policy with just the one rule above.

> > My understanding was that by requiring signing and not having private
> > keys on the device, such a breach could be detected even for privileged
> > processes.
> 
> The rule "appraise fowner=0 func=BPRM_CHECK appraise_type=imasig"
> requires all files owned by root to be signed.  Signed files in policy
> are considered "immutable".

The problem which keeps coming up is that such a policy is not practical
when root processes are meant to modify files on the device.

> > If an attacker changes the Smack label, EVM indeed becomes invalid, but
> > because the Smack label was changed, the appraise rule no longer matches
> > and the kernel will not raise any error when using the modified file,
> > will it?
> 
> Right, so the issue is defining an appropriate policy.  If you can't
> trust the Smack labels, then don't write a policy based on them.

Agreed.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: [Linux-ima-user] looking for suggestions on rule use

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

On Tue, 2015-07-14 at 17:11 +0200, Patrick Ohly wrote:
> On Tue, 2015-07-14 at 09:52 -0400, Mimi Zohar wrote:
> > On Tue, 2015-07-14 at 15:44 +0200, Patrick Ohly wrote:
> > > Hello!
> > > 
> > > I'm currently re-reading this mail thread because I am trying to achieve
> > > something similar using the Yocto/OpenEmbedded build system (see
> > > https://github.com/01org/meta-intel-iot-security/tree/master/meta-integrity).
> > > 
> > > One comment caught my eye:
> > > 
> > > On Wed, 2015-06-10 at 09:22 -0400, Mimi Zohar wrote:
> > > > On Tue, 2015-06-09 at 18:59 -0600, Curtis Veit wrote:
> > > > > I try to avoid issues with log (and other) files by mounting var on a
> > > > > separate filesystem and doing:
> > > > >   dont_measure fowner=0 fsuuid=xxxxx...(uuid for var fs)
> > > > >   dont_appraise fowner=0 fsuuid=xxxxx...
> > > > 
> > > > Ok.  Another option is to use LSM labels.
> > > 
> > > I tried that using Smack labels
> > > (https://github.com/pohly/meta-intel-iot-security/tree/ima-floor-policy). I depends on read-only files having the special "_" label, while read/write files are typically "System" (at least in our setup).
> > > 
> > > Then the only appraisal rule is:
> > > 
> > >         # Appraise all operations on files with floor label.
> > >         appraise obj_user=_
> > > 
> > > But IMHO such a system is not really secure, because an attacker could
> > > simply turn a protected file (label _) into an unprotected one (label
> > > System), either at runtime or offline. System services then wouldn't
> > > notice a difference (they can read System files just like _ files) and
> > > use a potentially modified file.
> > > 
> > > Do I miss something here or is my conclusion correct?
> > 
> > On a running system with Smack enabled, Smack should be limiting who can
> > modify security xattrs.
> 
> There will be privileged processes which can modify the Smack label; if
> an attacker manages to take control of those, they could disable IMA.

No, changing the xattr doesn't disable IMA nor affect the existing
policy.  If your policy measures/appraises everything, then the file
would still be measured/appraised appropriately. 

> My understanding was that by requiring signing and not having private
> keys on the device, such a breach could be detected even for privileged
> processes.

The rule "appraise fowner=0 func=BPRM_CHECK appraise_type=imasig"
requires all files owned by root to be signed.  Signed files in policy
are considered "immutable".

> >   For offline protection,  I assume they're using
> > EVM to protect file metadata from being modified.
> 
> But isn't EVM only checked if a file gets appraised?

Or when  writing a security extended attribute.

> If an attacker changes the Smack label, EVM indeed becomes invalid, but
> because the Smack label was changed, the appraise rule no longer matches
> and the kernel will not raise any error when using the modified file,
> will it?

Right, so the issue is defining an appropriate policy.  If you can't
trust the Smack labels, then don't write a policy based on them.

Mimi

Re: [Linux-ima-user] looking for suggestions on rule use

[Patrick O. <pat...@in...>]

On Tue, 2015-07-14 at 09:52 -0400, Mimi Zohar wrote:
> On Tue, 2015-07-14 at 15:44 +0200, Patrick Ohly wrote:
> > Hello!
> > 
> > I'm currently re-reading this mail thread because I am trying to achieve
> > something similar using the Yocto/OpenEmbedded build system (see
> > https://github.com/01org/meta-intel-iot-security/tree/master/meta-integrity).
> > 
> > One comment caught my eye:
> > 
> > On Wed, 2015-06-10 at 09:22 -0400, Mimi Zohar wrote:
> > > On Tue, 2015-06-09 at 18:59 -0600, Curtis Veit wrote:
> > > > I try to avoid issues with log (and other) files by mounting var on a
> > > > separate filesystem and doing:
> > > >   dont_measure fowner=0 fsuuid=xxxxx...(uuid for var fs)
> > > >   dont_appraise fowner=0 fsuuid=xxxxx...
> > > 
> > > Ok.  Another option is to use LSM labels.
> > 
> > I tried that using Smack labels
> > (https://github.com/pohly/meta-intel-iot-security/tree/ima-floor-policy). I depends on read-only files having the special "_" label, while read/write files are typically "System" (at least in our setup).
> > 
> > Then the only appraisal rule is:
> > 
> >         # Appraise all operations on files with floor label.
> >         appraise obj_user=_
> > 
> > But IMHO such a system is not really secure, because an attacker could
> > simply turn a protected file (label _) into an unprotected one (label
> > System), either at runtime or offline. System services then wouldn't
> > notice a difference (they can read System files just like _ files) and
> > use a potentially modified file.
> > 
> > Do I miss something here or is my conclusion correct?
> 
> On a running system with Smack enabled, Smack should be limiting who can
> modify security xattrs.

There will be privileged processes which can modify the Smack label; if
an attacker manages to take control of those, they could disable IMA.

My understanding was that by requiring signing and not having private
keys on the device, such a breach could be detected even for privileged
processes.

>   For offline protection,  I assume they're using
> EVM to protect file metadata from being modified.

But isn't EVM only checked if a file gets appraised?

If an attacker changes the Smack label, EVM indeed becomes invalid, but
because the Smack label was changed, the appraise rule no longer matches
and the kernel will not raise any error when using the modified file,
will it?

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: [Linux-ima-user] looking for suggestions on rule use

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

On Tue, 2015-07-14 at 15:44 +0200, Patrick Ohly wrote:
> Hello!
> 
> I'm currently re-reading this mail thread because I am trying to achieve
> something similar using the Yocto/OpenEmbedded build system (see
> https://github.com/01org/meta-intel-iot-security/tree/master/meta-integrity).
> 
> One comment caught my eye:
> 
> On Wed, 2015-06-10 at 09:22 -0400, Mimi Zohar wrote:
> > On Tue, 2015-06-09 at 18:59 -0600, Curtis Veit wrote:
> > > I try to avoid issues with log (and other) files by mounting var on a
> > > separate filesystem and doing:
> > >   dont_measure fowner=0 fsuuid=xxxxx...(uuid for var fs)
> > >   dont_appraise fowner=0 fsuuid=xxxxx...
> > 
> > Ok.  Another option is to use LSM labels.
> 
> I tried that using Smack labels
> (https://github.com/pohly/meta-intel-iot-security/tree/ima-floor-policy). I depends on read-only files having the special "_" label, while read/write files are typically "System" (at least in our setup).
> 
> Then the only appraisal rule is:
> 
>         # Appraise all operations on files with floor label.
>         appraise obj_user=_
> 
> But IMHO such a system is not really secure, because an attacker could
> simply turn a protected file (label _) into an unprotected one (label
> System), either at runtime or offline. System services then wouldn't
> notice a difference (they can read System files just like _ files) and
> use a potentially modified file.
> 
> Do I miss something here or is my conclusion correct?

On a running system with Smack enabled, Smack should be limiting who can
modify security xattrs.  For offline protection,  I assume they're using
EVM to protect file metadata from being modified.

Mimi

Re: [Linux-ima-user] looking for suggestions on rule use

[Patrick O. <pat...@in...>]

Hello!

I'm currently re-reading this mail thread because I am trying to achieve
something similar using the Yocto/OpenEmbedded build system (see
https://github.com/01org/meta-intel-iot-security/tree/master/meta-integrity).

One comment caught my eye:

On Wed, 2015-06-10 at 09:22 -0400, Mimi Zohar wrote:
> On Tue, 2015-06-09 at 18:59 -0600, Curtis Veit wrote:
> > I try to avoid issues with log (and other) files by mounting var on a
> > separate filesystem and doing:
> >   dont_measure fowner=0 fsuuid=xxxxx...(uuid for var fs)
> >   dont_appraise fowner=0 fsuuid=xxxxx...
> 
> Ok.  Another option is to use LSM labels.

I tried that using Smack labels
(https://github.com/pohly/meta-intel-iot-security/tree/ima-floor-policy). I depends on read-only files having the special "_" label, while read/write files are typically "System" (at least in our setup).

Then the only appraisal rule is:

        # Appraise all operations on files with floor label.
        appraise obj_user=_

But IMHO such a system is not really secure, because an attacker could
simply turn a protected file (label _) into an unprotected one (label
System), either at runtime or offline. System services then wouldn't
notice a difference (they can read System files just like _ files) and
use a potentially modified file.

Do I miss something here or is my conclusion correct?

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: [Linux-ima-user] kernel warnings

[Patrick O. <pat...@in...>]

On Mon, 2015-07-13 at 08:50 -0400, Mimi Zohar wrote:
> On Mon, 2015-07-13 at 13:50 +0200, Patrick Ohly wrote:
> > However, I get kernel messages that I haven't seen before, about "Root
> > dentry has weird name" and "warn_slowpath_common". Not sure whether the
> > two are releated. At least they appear close to each other in the
> > "dmesg" output below. Any suggestions?
> 
> The following patches are bug fixes, which were upstreamed in this open
> window and will be (hopefully this week) backported.  "ima: do not
> measure or appraise the NSFS filesystem" should address the problem you
> are seeing.
> 
> 45b2613 ima: fix ima_show_template_data_ascii()
> f2b3dee KEYS: fix "ca_keys=" partial key matching
> 5101a18 evm: labeling pseudo filesystems exception
> cd025f7 ima: do not measure or appraise the NSFS filesystem

I updated my tentative IMA policy file (which I am using right now
instead if ima_appraise_tcb) with the dont_appraise for NSFS and the
kernel messages are indeed gone.

I wasn't sure why, though, until I read the commit message introducing
nsfs (e149ed2) into 3.19-rc1 where it was explained that nsfs cannot be
mounted and thus will not be visible to user space - how sneaky ;-}

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: [Linux-ima-user] CONFIG_IMA_LSM_RULES depends on CONFIG_AUDIT?

[Patrick O. <pat...@in...>]

On Mon, 2015-07-13 at 08:56 -0400, Mimi Zohar wrote:
> On Mon, 2015-07-13 at 14:49 +0200, Patrick Ohly wrote:
> > But why does CONFIG_IMA_LSM_RULES depend on audit support? The LSM part
> > of the policy has nothing to do with logging. I'm referring to the "&&
> > AUDIT" part in security/integrity/ima/Kconfig:
> > 
> > config IMA_LSM_RULES
> >         bool
> >         depends on IMA && AUDIT && (SECURITY_SELINUX || SECURITY_SMACK)
> >         default y
> >         help
> >           Disabling this option will disregard LSM based policy rules.
> > 
> 
> The commit "b53fab9 ima: fix build error" patch description gives a full
> explanation.

That points in the right direction (security_audit_rule_match), thanks.

Do you have an opinion about the performance impact of CONFIG_AUDIT?

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: [Linux-ima-user] CONFIG_IMA_LSM_RULES depends on CONFIG_AUDIT?

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

On Mon, 2015-07-13 at 14:49 +0200, Patrick Ohly wrote:
> On Mon, 2015-07-13 at 08:36 -0400, Mimi Zohar wrote:
> > On Mon, 2015-07-13 at 13:55 +0200, Patrick Ohly wrote:
> > > Hello!
> > > 
> > > I noticed that CONFIG_IMA_LSM_RULES can only be enabled when
> > > CONFIG_AUDIT is also enabled. Why is that? At first glance it seemed
> > > like it should be possible to compile the LSM code without auditing
> > > enabled (not tested, though).
> > > 
> > > I was warned that enabling auditing has a performance impact. Is that
> > > true even for just CONFIG_AUDIT=yes (and nothing else, in particular
> > > nothing that turns on syscall auditing)?
> > 
> > The linux-integrity subsystem error messages use the audit subsystem
> > facility.  Look at the security/integrity/integrity_audit.c:
> > integrity_audit_msg() function.  Prior to systemd, the messages either
> > went to the audit log, if enabled, or syslog.
> 
> Understood.
> 
> But why does CONFIG_IMA_LSM_RULES depend on audit support? The LSM part
> of the policy has nothing to do with logging. I'm referring to the "&&
> AUDIT" part in security/integrity/ima/Kconfig:
> 
> config IMA_LSM_RULES
>         bool
>         depends on IMA && AUDIT && (SECURITY_SELINUX || SECURITY_SMACK)
>         default y
>         help
>           Disabling this option will disregard LSM based policy rules.
> 

The commit "b53fab9 ima: fix build error" patch description gives a full
explanation.

Mimi

Re: [Linux-ima-user] kernel warnings

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

On Mon, 2015-07-13 at 13:50 +0200, Patrick Ohly wrote:
> Hello!
> 
> I am using IMA appraisal for files with a special Smack label (_ aka
> floor) on a 3.19 kernel:
> 
> # Several dont_appraise fsmagic= entries.
> ...
> # Appraise all operations on files with floor label.
> appraise obj_user=_
> 
> With that policy, the system appears to work (although I have doubts
> whether using that file attribute is really protecting against offline
> attacks).
> 
> However, I get kernel messages that I haven't seen before, about "Root
> dentry has weird name" and "warn_slowpath_common". Not sure whether the
> two are releated. At least they appear close to each other in the
> "dmesg" output below. Any suggestions?

The following patches are bug fixes, which were upstreamed in this open
window and will be (hopefully this week) backported.  "ima: do not
measure or appraise the NSFS filesystem" should address the problem you
are seeing.

45b2613 ima: fix ima_show_template_data_ascii()
f2b3dee KEYS: fix "ca_keys=" partial key matching
5101a18 evm: labeling pseudo filesystems exception
cd025f7 ima: do not measure or appraise the NSFS filesystem

Mimi

> systemd[1]: Started Journal Service.
> uvesafb: framebuffer at 0xfd000000, mapped to 0xd0900000, using 16384k, total 16384k
> fb0: VESA VGA frame buffer device
> systemd-journald[91]: Received request to flush runtime journal from PID 1
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 118 at /work/build/iot/x86/tmp-glibc/work-shared/qemux86/kernel-source/fs/dcache.c:2801 prepend_path+0x269/0x2d0()
> Root dentry has weird name <>
> Modules linked in: uvesafb
> CPU: 0 PID: 118 Comm: systemd-machine Not tainted 3.19.2-yocto-standard #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org 04/01/2014
>  00000000 00000000 cf3b5d14 c186f8b8 cf3b5d58 cf3b5d48 c104c61b c1ab3768
>  cf3b5d74 00000076 c1ab36b8 00000af1 c1171a19 00000af1 c1171a19 ce99cd80
>  cf81da10 cf81da00 cf3b5d60 c104c683 00000009 cf3b5d58 c1ab3768 cf3b5d74
> Call Trace:
>  [<c186f8b8>] dump_stack+0x4b/0x75
>  [<c104c61b>] warn_slowpath_common+0x8b/0xc0
>  [<c1171a19>] ? prepend_path+0x269/0x2d0
>  [<c1171a19>] ? prepend_path+0x269/0x2d0
>  [<c104c683>] warn_slowpath_fmt+0x33/0x40
>  [<c1171a19>] prepend_path+0x269/0x2d0
>  [<c1174414>] d_absolute_path+0x44/0x80
>  [<c1387d21>] ima_d_path+0x31/0x70
>  [<c1386937>] process_measurement+0x3b7/0x3d0
>  [<c138696b>] ima_file_check+0x1b/0x20
>  [<c116915b>] do_last.isra.35+0x32b/0xce0
>  [<c1179b25>] ? mntput_no_expire+0x25/0x130
>  [<c116bbc8>] path_openat+0x448/0x5d0
>  [<c106f57b>] ? get_parent_ip+0xb/0x40
>  [<c116c5a1>] do_filp_open+0x31/0x90
>  [<c115d427>] do_sys_open+0x117/0x210
>  [<c115f71d>] ? ____fput+0xd/0x10
>  [<c115d542>] SyS_open+0x22/0x30
>  [<c1875a4e>] syscall_call+0x7/0x7
> ---[ end trace 67874c631bfd91f2 ]---
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 118 at /work/build/iot/x86/tmp-glibc/work-shared/qemux86/kernel-source/fs/dcache.c:2801 prepend_path+0x269/0x2d0()
> Root dentry has weird name <>
> Modules linked in: uvesafb
> CPU: 0 PID: 118 Comm: systemd-machine Tainted: G        W      3.19.2-yocto-standard #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org 04/01/2014
>  00000000 00000000 cf3b5d14 c186f8b8 cf3b5d58 cf3b5d48 c104c61b c1ab3768
>  cf3b5d74 00000076 c1ab36b8 00000af1 c1171a19 00000af1 c1171a19 ce99cd80
>  cf81da10 cf81da00 cf3b5d60 c104c683 00000009 cf3b5d58 c1ab3768 cf3b5d74
> Call Trace:
>  [<c186f8b8>] dump_stack+0x4b/0x75
>  [<c104c61b>] warn_slowpath_common+0x8b/0xc0
>  [<c1171a19>] ? prepend_path+0x269/0x2d0
>  [<c1171a19>] ? prepend_path+0x269/0x2d0
>  [<c104c683>] warn_slowpath_fmt+0x33/0x40
>  [<c1171a19>] prepend_path+0x269/0x2d0
>  [<c1174414>] d_absolute_path+0x44/0x80
>  [<c1387d21>] ima_d_path+0x31/0x70
>  [<c1386937>] process_measurement+0x3b7/0x3d0
>  [<c138696b>] ima_file_check+0x1b/0x20
>  [<c116915b>] do_last.isra.35+0x32b/0xce0
>  [<c1179b25>] ? mntput_no_expire+0x25/0x130
>  [<c116bbc8>] path_openat+0x448/0x5d0
>  [<c106f57b>] ? get_parent_ip+0xb/0x40
>  [<c116c5a1>] do_filp_open+0x31/0x90
>  [<c115d427>] do_sys_open+0x117/0x210
>  [<c115f71d>] ? ____fput+0xd/0x10
>  [<c115d542>] SyS_open+0x22/0x30
>  [<c1875a4e>] syscall_call+0x7/0x7
> ---[ end trace 67874c631bfd91f3 ]---
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 167 at /work/build/iot/x86/tmp-glibc/work-shared/qemux86/kernel-source/fs/dcache.c:2801 prepend_path+0x269/0x2d0()
> Root dentry has weird name <>
> ...
> 

Re: [Linux-ima-user] kernel warnings

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

[ Resending as this post never made it to the mailing list. ]

On Mon, 2015-07-13 at 13:50 +0200, Patrick Ohly wrote:
> Hello!
> 
> I am using IMA appraisal for files with a special Smack label (_ aka
> floor) on a 3.19 kernel:
> 
> # Several dont_appraise fsmagic= entries.
> ...
> # Appraise all operations on files with floor label.
> appraise obj_user=_
> 
> With that policy, the system appears to work (although I have doubts
> whether using that file attribute is really protecting against offline
> attacks).
> 
> However, I get kernel messages that I haven't seen before, about "Root
> dentry has weird name" and "warn_slowpath_common". Not sure whether the
> two are releated. At least they appear close to each other in the
> "dmesg" output below. Any suggestions?

The following patches are bug fixes, which were upstreamed in this open
window and will be (hopefully this week) backported.  "ima: do not
measure or appraise the NSFS filesystem" should address the problem you
are seeing.

45b2613 ima: fix ima_show_template_data_ascii()
f2b3dee KEYS: fix "ca_keys=" partial key matching
5101a18 evm: labeling pseudo filesystems exception
cd025f7 ima: do not measure or appraise the NSFS filesystem

Mimi

> systemd[1]: Started Journal Service.
> uvesafb: framebuffer at 0xfd000000, mapped to 0xd0900000, using 16384k, total 16384k
> fb0: VESA VGA frame buffer device
> systemd-journald[91]: Received request to flush runtime journal from PID 1
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 118 at /work/build/iot/x86/tmp-glibc/work-shared/qemux86/kernel-source/fs/dcache.c:2801 prepend_path+0x269/0x2d0()
> Root dentry has weird name <>
> Modules linked in: uvesafb
> CPU: 0 PID: 118 Comm: systemd-machine Not tainted 3.19.2-yocto-standard #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org 04/01/2014
>  00000000 00000000 cf3b5d14 c186f8b8 cf3b5d58 cf3b5d48 c104c61b c1ab3768
>  cf3b5d74 00000076 c1ab36b8 00000af1 c1171a19 00000af1 c1171a19 ce99cd80
>  cf81da10 cf81da00 cf3b5d60 c104c683 00000009 cf3b5d58 c1ab3768 cf3b5d74
> Call Trace:
>  [<c186f8b8>] dump_stack+0x4b/0x75
>  [<c104c61b>] warn_slowpath_common+0x8b/0xc0
>  [<c1171a19>] ? prepend_path+0x269/0x2d0
>  [<c1171a19>] ? prepend_path+0x269/0x2d0
>  [<c104c683>] warn_slowpath_fmt+0x33/0x40
>  [<c1171a19>] prepend_path+0x269/0x2d0
>  [<c1174414>] d_absolute_path+0x44/0x80
>  [<c1387d21>] ima_d_path+0x31/0x70
>  [<c1386937>] process_measurement+0x3b7/0x3d0
>  [<c138696b>] ima_file_check+0x1b/0x20
>  [<c116915b>] do_last.isra.35+0x32b/0xce0
>  [<c1179b25>] ? mntput_no_expire+0x25/0x130
>  [<c116bbc8>] path_openat+0x448/0x5d0
>  [<c106f57b>] ? get_parent_ip+0xb/0x40
>  [<c116c5a1>] do_filp_open+0x31/0x90
>  [<c115d427>] do_sys_open+0x117/0x210
>  [<c115f71d>] ? ____fput+0xd/0x10
>  [<c115d542>] SyS_open+0x22/0x30
>  [<c1875a4e>] syscall_call+0x7/0x7
> ---[ end trace 67874c631bfd91f2 ]---
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 118 at /work/build/iot/x86/tmp-glibc/work-shared/qemux86/kernel-source/fs/dcache.c:2801 prepend_path+0x269/0x2d0()
> Root dentry has weird name <>
> Modules linked in: uvesafb
> CPU: 0 PID: 118 Comm: systemd-machine Tainted: G        W      3.19.2-yocto-standard #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org 04/01/2014
>  00000000 00000000 cf3b5d14 c186f8b8 cf3b5d58 cf3b5d48 c104c61b c1ab3768
>  cf3b5d74 00000076 c1ab36b8 00000af1 c1171a19 00000af1 c1171a19 ce99cd80
>  cf81da10 cf81da00 cf3b5d60 c104c683 00000009 cf3b5d58 c1ab3768 cf3b5d74
> Call Trace:
>  [<c186f8b8>] dump_stack+0x4b/0x75
>  [<c104c61b>] warn_slowpath_common+0x8b/0xc0
>  [<c1171a19>] ? prepend_path+0x269/0x2d0
>  [<c1171a19>] ? prepend_path+0x269/0x2d0
>  [<c104c683>] warn_slowpath_fmt+0x33/0x40
>  [<c1171a19>] prepend_path+0x269/0x2d0
>  [<c1174414>] d_absolute_path+0x44/0x80
>  [<c1387d21>] ima_d_path+0x31/0x70
>  [<c1386937>] process_measurement+0x3b7/0x3d0
>  [<c138696b>] ima_file_check+0x1b/0x20
>  [<c116915b>] do_last.isra.35+0x32b/0xce0
>  [<c1179b25>] ? mntput_no_expire+0x25/0x130
>  [<c116bbc8>] path_openat+0x448/0x5d0
>  [<c106f57b>] ? get_parent_ip+0xb/0x40
>  [<c116c5a1>] do_filp_open+0x31/0x90
>  [<c115d427>] do_sys_open+0x117/0x210
>  [<c115f71d>] ? ____fput+0xd/0x10
>  [<c115d542>] SyS_open+0x22/0x30
>  [<c1875a4e>] syscall_call+0x7/0x7
> ---[ end trace 67874c631bfd91f3 ]---
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 167 at /work/build/iot/x86/tmp-glibc/work-shared/qemux86/kernel-source/fs/dcache.c:2801 prepend_path+0x269/0x2d0()
> Root dentry has weird name <>
> ...
> 

Re: [Linux-ima-user] CONFIG_IMA_LSM_RULES depends on CONFIG_AUDIT?

[Patrick O. <pat...@in...>]

On Mon, 2015-07-13 at 08:36 -0400, Mimi Zohar wrote:
> On Mon, 2015-07-13 at 13:55 +0200, Patrick Ohly wrote:
> > Hello!
> > 
> > I noticed that CONFIG_IMA_LSM_RULES can only be enabled when
> > CONFIG_AUDIT is also enabled. Why is that? At first glance it seemed
> > like it should be possible to compile the LSM code without auditing
> > enabled (not tested, though).
> > 
> > I was warned that enabling auditing has a performance impact. Is that
> > true even for just CONFIG_AUDIT=yes (and nothing else, in particular
> > nothing that turns on syscall auditing)?
> 
> The linux-integrity subsystem error messages use the audit subsystem
> facility.  Look at the security/integrity/integrity_audit.c:
> integrity_audit_msg() function.  Prior to systemd, the messages either
> went to the audit log, if enabled, or syslog.

Understood.

But why does CONFIG_IMA_LSM_RULES depend on audit support? The LSM part
of the policy has nothing to do with logging. I'm referring to the "&&
AUDIT" part in security/integrity/ima/Kconfig:

config IMA_LSM_RULES
        bool
        depends on IMA && AUDIT && (SECURITY_SELINUX || SECURITY_SMACK)
        default y
        help
          Disabling this option will disregard LSM based policy rules.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: [Linux-ima-user] CONFIG_IMA_LSM_RULES depends on CONFIG_AUDIT?

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

On Mon, 2015-07-13 at 13:55 +0200, Patrick Ohly wrote:
> Hello!
> 
> I noticed that CONFIG_IMA_LSM_RULES can only be enabled when
> CONFIG_AUDIT is also enabled. Why is that? At first glance it seemed
> like it should be possible to compile the LSM code without auditing
> enabled (not tested, though).
> 
> I was warned that enabling auditing has a performance impact. Is that
> true even for just CONFIG_AUDIT=yes (and nothing else, in particular
> nothing that turns on syscall auditing)?

The linux-integrity subsystem error messages use the audit subsystem
facility.  Look at the security/integrity/integrity_audit.c:
integrity_audit_msg() function.  Prior to systemd, the messages either
went to the audit log, if enabled, or syslog.

Mimi

[Linux-ima-user] CONFIG_IMA_LSM_RULES depends on CONFIG_AUDIT?

[Patrick O. <pat...@in...>]

Hello!

I noticed that CONFIG_IMA_LSM_RULES can only be enabled when
CONFIG_AUDIT is also enabled. Why is that? At first glance it seemed
like it should be possible to compile the LSM code without auditing
enabled (not tested, though).

I was warned that enabling auditing has a performance impact. Is that
true even for just CONFIG_AUDIT=yes (and nothing else, in particular
nothing that turns on syscall auditing)?

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

[Linux-ima-user] kernel warnings

[Patrick O. <pat...@in...>]

Hello!

I am using IMA appraisal for files with a special Smack label (_ aka
floor) on a 3.19 kernel:

# Several dont_appraise fsmagic= entries.
...
# Appraise all operations on files with floor label.
appraise obj_user=_

With that policy, the system appears to work (although I have doubts
whether using that file attribute is really protecting against offline
attacks).

However, I get kernel messages that I haven't seen before, about "Root
dentry has weird name" and "warn_slowpath_common". Not sure whether the
two are releated. At least they appear close to each other in the
"dmesg" output below. Any suggestions?

systemd[1]: Started Journal Service.
uvesafb: framebuffer at 0xfd000000, mapped to 0xd0900000, using 16384k, total 16384k
fb0: VESA VGA frame buffer device
systemd-journald[91]: Received request to flush runtime journal from PID 1
------------[ cut here ]------------
WARNING: CPU: 0 PID: 118 at /work/build/iot/x86/tmp-glibc/work-shared/qemux86/kernel-source/fs/dcache.c:2801 prepend_path+0x269/0x2d0()
Root dentry has weird name <>
Modules linked in: uvesafb
CPU: 0 PID: 118 Comm: systemd-machine Not tainted 3.19.2-yocto-standard #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org 04/01/2014
 00000000 00000000 cf3b5d14 c186f8b8 cf3b5d58 cf3b5d48 c104c61b c1ab3768
 cf3b5d74 00000076 c1ab36b8 00000af1 c1171a19 00000af1 c1171a19 ce99cd80
 cf81da10 cf81da00 cf3b5d60 c104c683 00000009 cf3b5d58 c1ab3768 cf3b5d74
Call Trace:
 [<c186f8b8>] dump_stack+0x4b/0x75
 [<c104c61b>] warn_slowpath_common+0x8b/0xc0
 [<c1171a19>] ? prepend_path+0x269/0x2d0
 [<c1171a19>] ? prepend_path+0x269/0x2d0
 [<c104c683>] warn_slowpath_fmt+0x33/0x40
 [<c1171a19>] prepend_path+0x269/0x2d0
 [<c1174414>] d_absolute_path+0x44/0x80
 [<c1387d21>] ima_d_path+0x31/0x70
 [<c1386937>] process_measurement+0x3b7/0x3d0
 [<c138696b>] ima_file_check+0x1b/0x20
 [<c116915b>] do_last.isra.35+0x32b/0xce0
 [<c1179b25>] ? mntput_no_expire+0x25/0x130
 [<c116bbc8>] path_openat+0x448/0x5d0
 [<c106f57b>] ? get_parent_ip+0xb/0x40
 [<c116c5a1>] do_filp_open+0x31/0x90
 [<c115d427>] do_sys_open+0x117/0x210
 [<c115f71d>] ? ____fput+0xd/0x10
 [<c115d542>] SyS_open+0x22/0x30
 [<c1875a4e>] syscall_call+0x7/0x7
---[ end trace 67874c631bfd91f2 ]---
------------[ cut here ]------------
WARNING: CPU: 0 PID: 118 at /work/build/iot/x86/tmp-glibc/work-shared/qemux86/kernel-source/fs/dcache.c:2801 prepend_path+0x269/0x2d0()
Root dentry has weird name <>
Modules linked in: uvesafb
CPU: 0 PID: 118 Comm: systemd-machine Tainted: G        W      3.19.2-yocto-standard #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org 04/01/2014
 00000000 00000000 cf3b5d14 c186f8b8 cf3b5d58 cf3b5d48 c104c61b c1ab3768
 cf3b5d74 00000076 c1ab36b8 00000af1 c1171a19 00000af1 c1171a19 ce99cd80
 cf81da10 cf81da00 cf3b5d60 c104c683 00000009 cf3b5d58 c1ab3768 cf3b5d74
Call Trace:
 [<c186f8b8>] dump_stack+0x4b/0x75
 [<c104c61b>] warn_slowpath_common+0x8b/0xc0
 [<c1171a19>] ? prepend_path+0x269/0x2d0
 [<c1171a19>] ? prepend_path+0x269/0x2d0
 [<c104c683>] warn_slowpath_fmt+0x33/0x40
 [<c1171a19>] prepend_path+0x269/0x2d0
 [<c1174414>] d_absolute_path+0x44/0x80
 [<c1387d21>] ima_d_path+0x31/0x70
 [<c1386937>] process_measurement+0x3b7/0x3d0
 [<c138696b>] ima_file_check+0x1b/0x20
 [<c116915b>] do_last.isra.35+0x32b/0xce0
 [<c1179b25>] ? mntput_no_expire+0x25/0x130
 [<c116bbc8>] path_openat+0x448/0x5d0
 [<c106f57b>] ? get_parent_ip+0xb/0x40
 [<c116c5a1>] do_filp_open+0x31/0x90
 [<c115d427>] do_sys_open+0x117/0x210
 [<c115f71d>] ? ____fput+0xd/0x10
 [<c115d542>] SyS_open+0x22/0x30
 [<c1875a4e>] syscall_call+0x7/0x7
---[ end trace 67874c631bfd91f3 ]---
------------[ cut here ]------------
WARNING: CPU: 0 PID: 167 at /work/build/iot/x86/tmp-glibc/work-shared/qemux86/kernel-source/fs/dcache.c:2801 prepend_path+0x269/0x2d0()
Root dentry has weird name <>
...

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: [Linux-ima-user] evmctl ima_sign + ima_verify failure

[Patrick O. <pat...@in...>]

On Sat, 2015-07-11 at 09:48 +0200, Patrick Ohly wrote:
> On Fri, 2015-07-10 at 18:56 -0400, Mimi Zohar wrote:
> > On Fri, 2015-07-10 at 22:14 +0200, Patrick Ohly wrote:
> > > I'm running these commands on a build host which does not have IMA
> > > enabled. So it's really a test of the code inside evmctl. It seems to
> > > produce a bad security.ima; both the kernel (on a different system) and
> > > evmctl's own signature check code agree on that.
> > 
> > Weird!  evmctl has support for signing hashes.  Create a sha256sums (eg.
> > sha256sum  <filename> > ./sha256sums.)   Then sign the hash(es) in the
> > sha256sums file.  
> > 
> > eg.  cat ./sha256sums | evmctl sign_hash -a sha256 --key "${PRIVKEY}" > sha256sums.sig
> > 
> > Compare the resulting signature in the sha256sums.sig file with the
> > extended attribute.  If the file hasn't changed, then they should be the
> > same.

They are not the same, even in the environment where sign/verify works:

$ evmctl ima_sign --key privkey_ima.pem pam_securetty.so
$ getfattr -d -m . -e hex pam_securetty.so
# file: pam_securetty.so
security.ima=0x030202d82d4efd008011035eb431eef56f999f96e92fe702d81bdd90936ce862244b91260fbe4c5eb93e2b47b418b64e980ab02db7bf8ce9ec9f0d3459bb61a86e71a3b568a7ec831a735594653de5843529012a0b739920b905e60c98f3c014fd3df2e9419ae55975144bd4ae9e1a54e5264f0a8ee969bf6d5b499cd8a587192f448b6354d715812f
$evmctl ima_verify --key x509_ima.der pam_securetty.so
Verification is OK
$ sha256sum  pam_securetty.so > ./sha256sums
$ cat ./sha256sums | $evmctl sign_hash -a sha256 --key privkey_ima.pem > sha256sums.sig
$ cat sha256sums_2.sig
6c1984303181d429bf48f9145303cc8181c2068417261e6f4c4285b9044997d5  pam_securetty.so 030204d82d4efd0080afe82fcc40638fc52c951aacf591972fb8f5f546a091c438be25f733f2077fab082de2a8db5f5b6d01f43fd70a915b68b153dbd6624298f7b61b2c1905b1202559bc3695d06effea278b834b999db7e35e20786212952e96fca34e3c91512e415b53029798fbba90f9df5e03169bc8634b46bb8ca352525b30956dc7d005dfec

Not sure what that means.

> I was about to test that in a slightly different environment (same
> binary) when I double-checked my previous results and noticed that they
> now succeeded. The security.ima is slightly different (last few bytes
> differ).

I tracked it down to a bug in they cross-compile environment: it catches
privileged calls like lsetxattr() and records the change in a database
instead of actually calling the kernel. That way, creating an image can
work without root privileges. But something goes wrong in the
lsetxattr() handling such that the value gets truncated in case the
value ends with a slash. I've submitted a patch to the upstream authors
(https://bugzilla.yoctoproject.org/show_bug.cgi?id=7990).

Sorry for the noise here!

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: [Linux-ima-user] evmctl ima_sign + ima_verify failure

[Patrick O. <pat...@in...>]

On Fri, 2015-07-10 at 18:56 -0400, Mimi Zohar wrote:
> On Fri, 2015-07-10 at 22:14 +0200, Patrick Ohly wrote:
> > I'm running these commands on a build host which does not have IMA
> > enabled. So it's really a test of the code inside evmctl. It seems to
> > produce a bad security.ima; both the kernel (on a different system) and
> > evmctl's own signature check code agree on that.
> 
> Weird!  evmctl has support for signing hashes.  Create a sha256sums (eg.
> sha256sum  <filename> > ./sha256sums.)   Then sign the hash(es) in the
> sha256sums file.  
> 
> eg.  cat ./sha256sums | evmctl sign_hash -a sha256 --key "${PRIVKEY}" > sha256sums.sig
> 
> Compare the resulting signature in the sha256sums.sig file with the
> extended attribute.  If the file hasn't changed, then they should be the
> same.

I was about to test that in a slightly different environment (same
binary) when I double-checked my previous results and noticed that they
now succeeded. The security.ima is slightly different (last few bytes
differ).

Running "evmctl ima_sign" under valgrind throws up a large  number of
warnings about uninitialized memory. Is that normal?

I'll compile a binary with debug information and have a closer look - on
Monday.

> Please list the public keys loaded on the IMA keyring that are used to
> verify the signature.

I'm running this on a build host without IMA and without any keys on the
kernel keyring. The public key is the one specified explicitly on the
evmctl command line.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: [Linux-ima-user] evmctl ima_sign + ima_verify failure

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

On Fri, 2015-07-10 at 22:14 +0200, Patrick Ohly wrote:
> On Fri, 2015-07-10 at 15:51 -0400, Mimi Zohar wrote:
> > On Fri, 2015-07-10 at 15:46 +0200, Patrick Ohly wrote:
> > > Hello!
> > > 
> > > I have (at least) one file where verifying the signature created by
> > > evmctl ima_sign fails. ima-evm-utils is 0.9 (git rev 3d9bdc1de2, the
> > > current master).
> > 
> > Was the file previously signed before this?   In enforcing mode,
> > existing signatures are considered to be "immutable" and can not be
> > removed/replaced.
> 
> I'm running these commands on a build host which does not have IMA
> enabled. So it's really a test of the code inside evmctl. It seems to
> produce a bad security.ima; both the kernel (on a different system) and
> evmctl's own signature check code agree on that.

Weird!  evmctl has support for signing hashes.  Create a sha256sums (eg.
sha256sum  <filename> > ./sha256sums.)   Then sign the hash(es) in the
sha256sums file.  

eg.  cat ./sha256sums | evmctl sign_hash -a sha256 --key "${PRIVKEY}" > sha256sums.sig

Compare the resulting signature in the sha256sums.sig file with the
extended attribute.  If the file hasn't changed, then they should be the
same.

> > > $ evmctl ima_sign privkey_ima.pem pam_securetty.so
> > > $ getfattr -d -m . pam_securetty.so 
> > > getfattr: Removing leading '/' from absolute path names
> > > # file: tmp/pam_securetty.so
> > > security.ima=0sAwIC2C1O/QCAEQNetDHu9W+Zn5bpL+cC2BvdkJNs6GIkS5EmD75MXrk+K0e0GLZOmAqwLbe/jOnsnw00WbthqG5xo7Vop+yDGnNVlGU95YQ1KQEqC3OZILkF5gyY88AU/T3y6UGa5Vl1FEvUrp4aVOUmTwqO6Wm/bVtJnNilhxkvRItjVNcVgQ==
> > > $ evmctl ima_verify --key x509_ima.der pam_securetty.so 
> > > RSA_public_decrypt() failed: -1
> > > error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01
> > > error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed
> > 
> > When displaying security.ima, please use the "-e hex" option. 
> 
> Then I get:
> security.ima=0x030202d82d4efd008011035eb431eef56f999f96e92fe702d81bdd90936ce862244b91260fbe4c5eb93e2b47b418b64e980ab02db7bf8ce9ec9f0d3459bb61a86e71a3b568a7ec831a735594653de5843529012a0b739920b905e60c98f3c014fd3df2e9419ae55975144bd4ae9e1a54e5264f0a8ee969bf6d5b499cd8a587192f448b6354d71581
> 
> > > The signature check done by the Linux kernel 3.19.2 also fails.
> > 
> > Compare the key embedded in the signature with the key on the IMA
> > keyring.  For example, /bin/more on my system is signed with the pseudo
> > fedora signing key - 0x96042912.   (The keyid are the last bytes of the
> > key.)
> 
> In this case, I specify the keys explicitly (privkey_ima.pem and
> x509_ima.der). I know that they match, because signing some other file
> and verifying it works.

Please list the public keys loaded on the IMA keyring that are used to
verify the signature.

Mimi