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

[Linux-ima-user] [RFC] i.MX6 CAAM blob generator for IMA/EVM initialization

[Steffen T. <s.t...@pe...>]

Hi!

The RFC Patch attached after this cover letter is mostly for illustration
purposes, so please don't waste too much time reviewing the code ;-)

For context I'll try to describe the problem that this patch tries to solve.

I need to be able to boot an EVM signed (and dongled) rootfs. The CAAM on
the i.MX6 has support for an OTP key and can en/decrypt data.
It also has a feature for generating red blobs: basically a chunk of data,
that is encrypted with the OTP key, which can be saved on some medium as a
secret to decrypt the EVM HMAC secret for one specific device.

To open the rootfs, the secret is handed from the bootloader to the kernel
as a base64 encoded string via the cmdline to an initramfs.
In the initramfs the sysfs file "modifier" is set to something starting with
"kernel:evm" and the base64 string is written to the sysfs file "blob".
The CAAM than decodes the red blob and, in case of "kernel:evm", initializes
the EVM or otherwise writes the result to "payload" if the modifier starts
with "user:". Therefore a blob that was generated for EVM never leaves the
kernel on decryption.
Generation of blobs goes like: echoing "modifier" to something and echoing
the payload to "payload". The red blob can than be read from "blob".


So, the sysfs interface is not the best option, I guess. The question is:
What is the right approach for a setup like this?
I need to:
  - be able to encrypt the secret and store it somewhere
  - to load the stored secret and decrypt it later
  - initialize IMA/EVM with the secret

Would something like
  - security/keys/encrypted-keys/encrypted.c
be the correct approach?

Thanks,
Steffen


Steffen Trumtrar (1):
  crypto: caam - add red blobifier

 drivers/crypto/caam/Kconfig    |   9 +
 drivers/crypto/caam/Makefile   |   1 +
 drivers/crypto/caam/blob_gen.c | 528 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 538 insertions(+)
 create mode 100644 drivers/crypto/caam/blob_gen.c

-- 
2.6.1

Re: [Linux-ima-user] Invalid-HMAC Issue with IMA in Enforce Mode

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

Hello,

Shortly.... There are 2 type of public keys IMA/EVM support
1) plain RSA keys - digsig support
2) X509 certificates - asymmetric key support

The problem you have is that your use RSA keys, but sign for X509...

See inline...

In general you can also use X509 for EVM...

Dmitry


On Wed, Sep 16, 2015 at 2:49 PM, Calligan, Keith (US)
<kca...@cy...> wrote:
> I am trying to setup IMA/EVM but appear to be having a problem with setting
> IMA in enforce mode.  I am getting an invalid-HMAC error.  If I run
> EVM=enforce (and IMA_APPRAISE=FIX), I don’t receive this error.
>
>
>
> For background information, I am currently trying to get this to work on
> Kernel version 4.2 on Centos 7, but have tried Kernel 3.19 (and other
> Kernels newer than 3.13) and had the same types of issues.  I tried these
> different Kernels to rule-out the Kernel as the cause.
>
>
>
> When I compiled the Kernel, I enabled everything under Security à Integrity
> Subsystem with the exception of  FSUUID (Version 2) and “Require Signed
> User-Space Initialization.”  I used the scripts in the
> /usr/local/share/doc/ima-evm-utils directory to make the ima-local-ca.x509
> and x509_ima.der files.  The ima-local-ca.x509 was copied to the Kernel
> source directory the x509_ima.der was copied to the /etc/keys directory on
> the filesystem, and the INITRAMFS so I could load before the system booted.
> I also have the evmctl, kmk-user, evm-key, pubkey_evm.pem in the INITRAMFS.
>
>
>
> When this issue is occurring, I have “ima_appraise=enforce ima_appraise_tcb
> evm=fix rd.break” for the bootline parameters.  The rd.break is so I can
> load they keys before the system is booted.  The script loads the kmk-user,
> evm-encrypted, IMA public key, and EVM public key and is shown below.  This
> is a non-TPM system.
>
>
>
> —————————
>
>
>
> keyctl add user kmk-user "`cat /etc/keys/kmk-user.blob`" @u > /dev/null
>
> keyctl add encrypted evm-key "load `cat /etc/keys/evm-key`" @u > /dev/null
>
>
>
> # import IMA public key
>
> ima_id=`keyctl newring _ima @u`
>
> evmctl import /etc/keys/x509_ima.der $ima_id
>
>
>
> # import EVM public key
>
> evm_id=`keyctl newring _evm @u`
>
> evmctl import --rsa /etc/keys/pubkey_evm.pem $evm_id
>
>

'--rsa' is for RSA based key...

>
> # enable EVM
>
> echo "1" > /sys/kernel/security/evm
>
>
>
> # enable module checking
>
> #echo "1" > /sys/kernel/security/module_check
>

How did you get such entry? module_check???



> —————————
>
>
> To sign the binaries, I am running “evmctl sign –imasig $file.”  For non-ELF
> (binary) files, I am running “evmctl sign –imahash $file.”


You have also to use '--rsa' when signing...


>
>
> When I am booted into the system in IMA_APPRAISE=fix mode and run “evmctl
> ima_verify $file,” I see that the file is verified OK.
>
>
>
> When rebooting (after loading my script in initramfs), I receive the
> invalid-HMAC error.
>
>
>
> I have a feeling that I am loading the keys incorrectly somehow.  Here is
> the output of “keyctl show” and “cat /proc/keys”.  Is there anything obvious
> to anyone on the list?
>
>
>  —————————
>
> 02aa3014 I--Q---     1 perm 39010000     0     0 asymmetri
> localhost.localdomain: root signing key:
> ec0e32eb4c1fe167dbd7e9b58f7b88166895b433: X509.RSA 6895b433 []
>
> 0544c4ea I--Q---     1 perm 3f010000     0     0 user      kmk-user: 32
>
> 0dedbc46 I--Q---     7 perm 3f030000     0     0 keyring   _ses: 1
>
> 1076b9b6 I--Q---     1 perm 3f010000     0     0 user      1ECAF89B087F7A55:
> 142
>
> 11d778c2 I------     1 perm 1f0b0000     0     0 keyring   .system_keyring:
> 2
>
> 13e61baf I------     1 perm 1f0f0000     0     0 keyring   .ima: 1
>
> 15bc3e98 I--Q---     1 perm 3f010000     0     0 keyring   _ima: 1
>
> 177fedc0 I--Q---     2 perm 3f010000     0     0 keyring   _evm: 1
>
> 23e639aa I------     1 perm 1f030000     0     0 asymmetri IMA-CA: IMA/EVM
> certificate signing key: 917665242851040704755d74629778f08d472d28: X509.RSA
> 8d472d28 []
>
> 28c7c6ab I------     1 perm 1f030000     0     0 asymmetri
> localhost.localdomain: root signing key:
> ec0e32eb4c1fe167dbd7e9b58f7b88166895b433: X509.RSA 6895b433 []
>
> 2eee811b I--Q---     3 perm 1f3f0000     0 65534 keyring   _uid.0: 4
>
> 3474e666 I--Q---     1 perm 1f3f0000     0 65534 keyring   _uid_ses.0: 1
>
> 372bf168 I------     1 perm 1f030000     0     0 asymmetri Build time
> autogenerated kernel key: e209db6b68e553f3a73f248de32ff531fc3f4063: X509.RSA
> fc3f4063 []
>
> 3b573d90 I--Q---     1 perm 3f010000     0     0 encrypted evm-key: 139
>
> —————————
>
>
> I am a little confused on the difference between the .ima, _ima and
> occasionally seeing the _ivm.1 and _ivm.empty keyrings.  Am I loading the
> key in the wrong place (or doing something else incorrectly)?
>
>
>
> Here is my “keyctl show” output
>
>
>
> —————————
>
> Session Keyring
>
>  233684038 --alswrv      0     0  keyring: _ses
>
>  787382555 --alswrv      0 65534   \_ keyring: _uid.0
>
>   88392938 --alswrv      0     0       \_ user: kmk-user
>
>  394259904 --alswrv      0     0       \_ keyring: _evm
>
>  276216246 --alswrv      0     0       |   \_ user: 1ECAF89B087F7A55
>
>  364658328 --alswrv      0     0       \_ keyring: _ima
>
>   44707860 --als--v      0     0       |   \_ asymmetric:
> localhost.localdomain: root signing key:
> ec0e32eb4c1fe167dbd7e9b58f7b88166895b433
>
>  995573136 --alswrv      0     0       \_ encrypted: evm-key
>
> —————————
>
>
>
> Also, as reference, I am using an XFS filesystem but have tried on EXT4
> systems as well.  Has anyone tried on XFS?
>
>
>
> Sorry for the long email.  Any help is much appreciated.  Please let me know
> if you need any additional information.
>
>
>
> Thanks,
>
>
>
> Keith
>
>
>
> ------------------------------------------------------------------------------
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
> _______________________________________________
> Linux-ima-user mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-ima-user
>



-- 
Thanks,
Dmitry

Re: [Linux-ima-user] IMA hash update

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

On Tue, 2015-09-22 at 09:04 -0400, Mimi Zohar wrote:
> On Tue, 2015-09-22 at 14:58 +0200, Patrick Ohly wrote:
> > Would it be possible to intercept the in-kernel implementation of
> > fdatasync() and trigger a hash update *and* a flushing of the xattr?
> 
> That sounds like a good compromise, but would it be enough to resolve
> the problem?

I suspect that there's still a time window where a file content change
has hit the disk while the corresponding xattr change has not, for
example between writes and the fdatasync(). It would be much better, but
probably not good enough.

Primarily I wanted to raise the problem here and get opinions. My
conclusion is that writing databases probably should be done where it is
not in the IMA policy, even if the risk was reduced by also updating the
hash on fdatasync().

-- 
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] IMA hash update

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

On Tue, 2015-09-22 at 14:58 +0200, Patrick Ohly wrote:
> On Thu, 2015-09-17 at 17:38 -0400, Mimi Zohar wrote:
> > On Thu, 2015-09-17 at 12:48 +0200, Patrick Ohly wrote:
> > > Hello!
> > > 
> > > I have a system setup such that some files are hashed on the target
> > > device. That works fine in most cases: "echo foo >bar" creates bar with
> > > a valid security.ima and it can be updated with "echo abc >>bar", even
> > > after a reboot.
> > > 
> > > However, after a power off without properly shutting down first, a
> > > sqlite3 DB file ended up with an invalid hash in security.ima. That
> > > leads me to one question: when a file gets written to, when is the
> > > security.ima hash updated?
> > > 
> > > My theory is that sqlite3 has written and synced new data to the DB
> > > file, but the hash wasn't updated yet when the machine was powered off,
> > > or it wasn't synced to disk. If that's true, then I need to rethink
> > > where such DB files get stored and how they will be protected.
> > 
> > Updating the hash after each write would be a major performance hit.
> 
> Yes, that's what I thought, too. But there are also intermittent points
> where it would make sense, like fdatasync().
> 
> > The hash is updated after the last close for write, during __fput().
> 
> That's indeed the problem for sqlite then. It keeps the main .db file
> open after writes and only calls fdatasync() on the file descriptor.
> 
> That leaves the hash in an inconsistent state basically as long as the
> daemon which owns the DB lives, thus defeating one of the purposes of
> using sqlite (crash resilience).
> 
> I've reproduced the issue with strace and killing the machine => .db
> file becomes unreadable.
> 
> Would it be possible to intercept the in-kernel implementation of
> fdatasync() and trigger a hash update *and* a flushing of the xattr?

That sounds like a good compromise, but would it be enough to resolve
the problem?

Mimi

Re: [Linux-ima-user] IMA hash update

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

On Thu, 2015-09-17 at 17:38 -0400, Mimi Zohar wrote:
> On Thu, 2015-09-17 at 12:48 +0200, Patrick Ohly wrote:
> > Hello!
> > 
> > I have a system setup such that some files are hashed on the target
> > device. That works fine in most cases: "echo foo >bar" creates bar with
> > a valid security.ima and it can be updated with "echo abc >>bar", even
> > after a reboot.
> > 
> > However, after a power off without properly shutting down first, a
> > sqlite3 DB file ended up with an invalid hash in security.ima. That
> > leads me to one question: when a file gets written to, when is the
> > security.ima hash updated?
> > 
> > My theory is that sqlite3 has written and synced new data to the DB
> > file, but the hash wasn't updated yet when the machine was powered off,
> > or it wasn't synced to disk. If that's true, then I need to rethink
> > where such DB files get stored and how they will be protected.
> 
> Updating the hash after each write would be a major performance hit.

Yes, that's what I thought, too. But there are also intermittent points
where it would make sense, like fdatasync().

> The hash is updated after the last close for write, during __fput().

That's indeed the problem for sqlite then. It keeps the main .db file
open after writes and only calls fdatasync() on the file descriptor.

That leaves the hash in an inconsistent state basically as long as the
daemon which owns the DB lives, thus defeating one of the purposes of
using sqlite (crash resilience).

I've reproduced the issue with strace and killing the machine => .db
file becomes unreadable.

Would it be possible to intercept the in-kernel implementation of
fdatasync() and trigger a hash update *and* a flushing of the xattr?

-- 
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] Invalid-HMAC Issue with IMA in Enforce Mode

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

On Thu, 2015-09-17 at 12:48 +0000, Calligan, Keith (US) wrote:
> Hi,

> I am going to patch my Kernel today to use the Linux-next as you mentioned,
> but let me explain the issue I am having with the 4.2 build of the Kernel.
> If you believe that the Linux-next Kernel will fix these issues, I will
> immediately go to that.  Are the patches you made mostly enhancements or bug
> fixes as well? I know you specifically mentioned the
> CONFIG_SYSTEM_TRUSTED_KEYS being new but can I still do this the old-way
> (copying IMA local x509 to Kernel source)?

The change from storing the x509 keys in the root build directory to
having the keys stored in a single file is not a "bug" fix per-se, but
rather a clean up. 
 
> Background:  
>  
> I am still receiving the request for unknown key/invalid-HMAC error when
> running the /bin/ls command.
> 
> I am able to see the kmk-user, evm:encrypted, and IMA/EVM keyrings when
> running the ³keyctl show² command.  See below:

>  Session Keyring
>  312013873 --alswrv      0     0 keyring: _ses
>  853140663 --alswrv      0 65534   \_ keyring: _uid.0
>  332453814 --alswrv      0     0      \_ user: kmk-user
>  673567069 --alswrv      0     0      \_ keyring: _ima 
>  489008419 --als--v      0     0      |   \_ asymmetric:
> localhost.localdomain: root signing key:

If you've enabled the IMA trusted keyring, there should not be an
'_ima' keyring.

> ec0e32eb4c1fe167dbd7e9b58f7b88166895b433
>  584906645 --alswrv      0     0      \_ keyring: _evm
>  366138436 --als--v      0     0      |   \_ asymmetric:
> localhost.localdomain: root signing key:
> ec0e32eb4c1fe167dbd7e9b58f7b88166895b433
>  666325898 --alswrv      0    0       \_ encrypted: evm-key
>  
> The ³keyctl show² command from above shows that the EVM key is signed by the
> same root signing key as IMA. I decided to use the x509_ima.der file for
> both for troubleshooting purposes.  I will outline my testing steps below.

That's fine.

> For testing, I am currently only labelling /bin/ls with the ³evmctl sign
> ­imasig /bin/ls² command.
>  
> First, I boot into ³ima=fix² and ³evm=fix² mode.  Label the /bin/ls file.

With the ima_appraise_tcb boot command line option specified, the entire
file system needs to be labeled, not just a single file.

> I reboot into ³ima=enforce ima_appraise_tcb ima_policy=tcb evm=enforce²
> mode.

I'm surprised you can boot in enforce mode without labeling the
filesystem. (BTW, the default mode is "enforce" mode. No need to specify
it on the boot command line.)

> In the initramfs (after loading all of the keys), I run the /sysroot/bin/ls
> command.  I receive the request for unknown key/permission denied
> (invalid-HMAC) error.

> To figure out if it is EVM or IMA causing the issue, I changed the boot time
> parameters to ³ima=fix evm=enforce². Now, I can run the /bin/ls command
> (without any errors), but I am still able to run other binaries as well even
> though they have not been signed.  From this, I¹m assuming EVM isn¹t really
> working?

In fix mode, the secure xattr is "fixed", meaning that the security.ima
in this case is updated with the current file hash.
 
> As I mentioned previously, to rule out an issue with the EVM signing key, I
> changed the ³evmctl import² command in my INITRAMFS to use the x509_ima.der
> file for both IMA and EVM. Originally, EVM was using the x509_evm.der file.
> I did this assuming that possibly the EVM key needed to be signed by the
> IMA/CA authority as well.  Let me know if this is incorrect thinking.

The patches to require signed EVM keys has not yet been upstreamed.  EVM
is enabled by writing to <securityfs>/evm.  ( eg. for dracut, disable
98integrity/evm_enable.sh.)

> Before making the change with the EVM key, I took note of the output of
> ³getfattr ­m . ­d /bin/ls² command.
>  
> After changing EVM to use the IMA key, I relabeled the /bin/ls file (evmctl
> sign ­imasig /bin/ls).  The IMA and EVM hash stayed the same. I would have
> expected the EVM hash to change?

To modify either the IMA and EVM security xattrs, the existing xattrs
values must either be correct or the system must be in "fix" mode.

> Even with these issues occurring, I am running ³evmctl verify/ima_verify
> $file² commands.  The output of these commands shows everything is ok.

That would imply the public key was not properly loaded on the right
keyring.

Please show the IMA public keys on the '.ima' keyring and display the
xattrs for /bin/ls.  
- keyctl show %keyring:.ima
- getfattr -m ^security -e hex --dump /sysroot/bin/ls 

Mimi

> Thanks for any help you can provide.  Let me know if you need me to clarify
> or provide any additional info.
>  
> Keith

Re: [Linux-ima-user] IMA hash update

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

On Thu, 2015-09-17 at 12:48 +0200, Patrick Ohly wrote:
> Hello!
> 
> I have a system setup such that some files are hashed on the target
> device. That works fine in most cases: "echo foo >bar" creates bar with
> a valid security.ima and it can be updated with "echo abc >>bar", even
> after a reboot.
> 
> However, after a power off without properly shutting down first, a
> sqlite3 DB file ended up with an invalid hash in security.ima. That
> leads me to one question: when a file gets written to, when is the
> security.ima hash updated?
> 
> My theory is that sqlite3 has written and synced new data to the DB
> file, but the hash wasn't updated yet when the machine was powered off,
> or it wasn't synced to disk. If that's true, then I need to rethink
> where such DB files get stored and how they will be protected.

Updating the hash after each write would be a major performance hit.
The hash is updated after the last close for write, during __fput().

Mimi

Re: [Linux-ima-user] Invalid-HMAC Issue with IMA in Enforce Mode

[Calligan, K. (US) <kca...@cy...>]

Hi,


I am going to patch my Kernel today to use the Linux-next as you mentioned,
but let me explain the issue I am having with the 4.2 build of the Kernel.
If you believe that the Linux-next Kernel will fix these issues, I will
immediately go to that.  Are the patches you made mostly enhancements or bug
fixes as well? I know you specifically mentioned the
CONFIG_SYSTEM_TRUSTED_KEYS being new but can I still do this the old-way
(copying IMA local x509 to Kernel source)?
 
Background:  
 
I am still receiving the request for unknown key/invalid-HMAC error when
running the /bin/ls command.

I am able to see the kmk-user, evm:encrypted, and IMA/EVM keyrings when
running the ³keyctl show² command.  See below:
 
 Session Keyring
 312013873 --alswrv      0     0 keyring: _ses
 853140663 --alswrv      0 65534   \_ keyring: _uid.0
 332453814 --alswrv      0     0      \_ user: kmk-user
 673567069 --alswrv      0     0      \_ keyring: _ima
 489008419 --als--v      0     0      |   \_ asymmetric:
localhost.localdomain: root signing key:
ec0e32eb4c1fe167dbd7e9b58f7b88166895b433
 584906645 --alswrv      0     0      \_ keyring: _evm
 366138436 --als--v      0     0      |   \_ asymmetric:
localhost.localdomain: root signing key:
ec0e32eb4c1fe167dbd7e9b58f7b88166895b433
 666325898 --alswrv      0    0       \_ encrypted: evm-key
 
The ³keyctl show² command from above shows that the EVM key is signed by the
same root signing key as IMA. I decided to use the x509_ima.der file for
both for troubleshooting purposes.  I will outline my testing steps below.
 
For testing, I am currently only labelling /bin/ls with the ³evmctl sign
­imasig /bin/ls² command.
 
First, I boot into ³ima=fix² and ³evm=fix² mode.  Label the /bin/ls file.
 
I reboot into ³ima=enforce ima_appraise_tcb ima_policy=tcb evm=enforce²
mode.
 
In the initramfs (after loading all of the keys), I run the /sysroot/bin/ls
command.  I receive the request for unknown key/permission denied
(invalid-HMAC) error.
 
To figure out if it is EVM or IMA causing the issue, I changed the boot time
parameters to ³ima=fix evm=enforce². Now, I can run the /bin/ls command
(without any errors), but I am still able to run other binaries as well even
though they have not been signed.  From this, I¹m assuming EVM isn¹t really
working?
 
As I mentioned previously, to rule out an issue with the EVM signing key, I
changed the ³evmctl import² command in my INITRAMFS to use the x509_ima.der
file for both IMA and EVM. Originally, EVM was using the x509_evm.der file.
I did this assuming that possibly the EVM key needed to be signed by the
IMA/CA authority as well.  Let me know if this is incorrect thinking.

Before making the change with the EVM key, I took note of the output of
³getfattr ­m . ­d /bin/ls² command.
 
After changing EVM to use the IMA key, I relabeled the /bin/ls file (evmctl
sign ­imasig /bin/ls).  The IMA and EVM hash stayed the same. I would have
expected the EVM hash to change?
 
Even with these issues occurring, I am running ³evmctl verify/ima_verify
$file² commands.  The output of these commands shows everything is ok.
 
Thanks for any help you can provide.  Let me know if you need me to clarify
or provide any additional info.
 
Keith

[Linux-ima-user] IMA hash update

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

Hello!

I have a system setup such that some files are hashed on the target
device. That works fine in most cases: "echo foo >bar" creates bar with
a valid security.ima and it can be updated with "echo abc >>bar", even
after a reboot.

However, after a power off without properly shutting down first, a
sqlite3 DB file ended up with an invalid hash in security.ima. That
leads me to one question: when a file gets written to, when is the
security.ima hash updated?

My theory is that sqlite3 has written and synced new data to the DB
file, but the hash wasn't updated yet when the machine was powered off,
or it wasn't synced to disk. If that's true, then I need to rethink
where such DB files get stored and how they will be protected.

-- 
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] Invalid-HMAC Issue with IMA in Enforce Mode

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

On Wed, 2015-09-16 at 13:12 -0400, Mimi Zohar wrote:
> On Wed, 2015-09-16 at 16:02 +0000, Calligan, Keith (US) wrote:
> > Hi Mimi,
> > 
> > Sorry for not understanding this completely.
> 
> Sorry, I should have been clearer.  This change is being upstreamed now.

The two commits involved are:
84706ca extract-cert: Cope with multiple X.509 certificates in a single file
99d27b1 modsign: Add explicit CONFIG_SYSTEM_TRUSTED_KEYS option

and can be found in linux-security/next and Linus' tree.

Mimi

Re: [Linux-ima-user] Invalid-HMAC Issue with IMA in Enforce Mode

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

On Wed, 2015-09-16 at 16:02 +0000, Calligan, Keith (US) wrote:
> Hi Mimi,
> 
> Sorry for not understanding this completely.

Sorry, I should have been clearer.  This change is being upstreamed now.

Mimi

> I don’t see CONFIG_SYSTEM_TRUSTED_KEYS as an option in the Kernel.  I
> searched for it when I ran “make menuconfig”.  Is there a patch I need for
> this? Are you referring to the “IMA_X509_PATH” setting instead? This was
> previously set to “/etc/keys/x509_ima.der"

> Also, if I understand correctly, I am going to remove ima-local-ca.x509
> from the Kernel source directory? I know when I had this defined, I could
> see the IVM CA when running “cat /proc/keys”.  I no longer see this after
> recompiling.   
> 
> Thanks,
> 
> Keith

Re: [Linux-ima-user] Invalid-HMAC Issue with IMA in Enforce Mode

[Calligan, K. (US) <kca...@cy...>]

Hi Petko/Mimi,

Thanks for the responses.  I am searching specifically for
CONFIG_SYSTEM_TRUSTED_KEYS (not CONFIG_SYSTEM_TRUSTED_KEYRING).  From
Mimi¹s description, it appeared as though CONFIG_SYSTEM_TRUSTED_KEYS
allowed me to define the location of the IMA CA public key file (PEM file)
as an alternative to copying the ima-local-ca.x509 file.  I apologize if
I¹m understanding this incorrectly.  I already have module signing enabled
(default) and CONFIG_SYSTEM_TRUSTED_KEYRING is set to ³y"

I have copied back the ima-local.x509 file back to the Kernel source to
get back where I was.

I also defined ³IMA_X509_PATH² to be /etc/keys/x509_ima.der.  What is the
significance of this setting? I ran a ³make -V=1² to increase the
verbosity of the build but don¹t see this getting loaded.  I only see
reference to it in the $KERNEL_SRC/security/ima_init.c file.  Is this an
alternative to loading through the INITRAMFS?


Thanks,

Keith


On 9/16/15, 12:22 PM, "Petko Manolov" <pe...@mi...> wrote:

>On 15-09-16 16:02:16, Calligan, Keith (US) wrote:
>> Hi Mimi,
>> 
>> Sorry for not understanding this completely.
>> 
>> I don¹t see CONFIG_SYSTEM_TRUSTED_KEYS as an option in the Kernel.  I
>>searched 
>> for it when I ran ³make menuconfig².  Is there a patch I need for this?
>>Are 
>> you referring to the ³IMA_X509_PATH² setting instead? This was
>>previously set 
>> to ³/etc/keys/x509_ima.der"
>
>Currently CONFIG_SYSTEM_TRUSTED_KEYRING can be enabled when you select
>kernel 
>module signing - CONFIG_SYSTEM_TRUSTED_KEYRING and
>CONFIG_MODULE_SIG_FORCE.
>
>I've written a patch that corrects this, but it only applies on top of my
>other 
>patches.  I guess i should do another one without this dependency.
>
>> Also, if I understand correctly, I am going to remove ima-local-ca.x509
>>from 
>> the Kernel source directory? I know when I had this defined, I could
>>see the 
>> IVM CA when running ³cat /proc/keys².  I no longer see this after
>>recompiling.
>
>Err, why would you remove your public key if you're going to use IMA?
>
>
>		Petko

Re: [Linux-ima-user] Invalid-HMAC Issue with IMA in Enforce Mode

[Petko M. <pe...@mi...>]

On 15-09-16 16:02:16, Calligan, Keith (US) wrote:
> Hi Mimi,
> 
> Sorry for not understanding this completely.
> 
> I don’t see CONFIG_SYSTEM_TRUSTED_KEYS as an option in the Kernel.  I searched 
> for it when I ran “make menuconfig”.  Is there a patch I need for this? Are 
> you referring to the “IMA_X509_PATH” setting instead? This was previously set 
> to “/etc/keys/x509_ima.der"

Currently CONFIG_SYSTEM_TRUSTED_KEYRING can be enabled when you select kernel 
module signing - CONFIG_SYSTEM_TRUSTED_KEYRING and CONFIG_MODULE_SIG_FORCE.

I've written a patch that corrects this, but it only applies on top of my other 
patches.  I guess i should do another one without this dependency.

> Also, if I understand correctly, I am going to remove ima-local-ca.x509 from 
> the Kernel source directory? I know when I had this defined, I could see the 
> IVM CA when running “cat /proc/keys”.  I no longer see this after recompiling.

Err, why would you remove your public key if you're going to use IMA?


		Petko

Re: [Linux-ima-user] Invalid-HMAC Issue with IMA in Enforce Mode

[Calligan, K. (US) <kca...@cy...>]

Hi Mimi,

Sorry for not understanding this completely.

I don’t see CONFIG_SYSTEM_TRUSTED_KEYS as an option in the Kernel.  I
searched for it when I ran “make menuconfig”.  Is there a patch I need for
this? Are you referring to the “IMA_X509_PATH” setting instead? This was
previously set to “/etc/keys/x509_ima.der"

Also, if I understand correctly, I am going to remove ima-local-ca.x509
from the Kernel source directory? I know when I had this defined, I could
see the IVM CA when running “cat /proc/keys”.  I no longer see this after
recompiling.   

Thanks,

Keith





On 9/16/15, 10:52 AM, "Mimi Zohar" <zo...@li...> wrote:

>On Wed, 2015-09-16 at 14:28 +0000, Calligan, Keith (US) wrote:
>> Hi Mimi,
>> 
>> Thanks for the info.
>> 
>> I¹m assuming that you mean copy the IMA public key to the Kernel source
>> directory? Do I need to specify the name of this file somewhere as I¹m
>> compiling the Kernel? Is there a default name or location to copy this
>> file?
>
>No, we're discussing the public key (eg. local ima-ca) used for
>verifying the signed IMA keys.  Until recently, all .x509 keys (DER
>format) in the kernel build root were builtin into the kernel image and
>loaded onto the system keyring.  Currently, the keys are stored in a
>single file as defined in CONFIG_SYSTEM_TRUSTED_KEYS.  The keys in this
>file are in PEM format.
>
>> I downloaded the newer version of Dracut from the link you sent and was
>> looking at the scripts in the 98integrity directory.  Most of it makes
>> sense to me.  I see that the EVM encrypted key is loaded as part of the
>> module as well.  I¹m assuming I would only need to enable ³integrity and
>> masterkey² as I build the INITRAMFS?
>
>The masterkey decrypts the EVM symmetric key.  In your case, without a
>TPM, you're using a "user" type masterkey.
>
>> 
>> CONFIG_IMA_TRUSTED_KEYRING was already enabled when I built the Kernel.
>> 
>> Here is the output of the 2 commands you provided with my current
>> configuration.
>> 
>> *****keyctl show %keyring:.system_keyring*****
>> 
>> 
>> Keyring
>>  299333826 --alswrv      0     0  keyring: .system_keyring
>>  925626728 --alswrv      0     0   \_ asymmetric: Build time
>>autogenerated
>> kernel key: e209db6b68e553f3a73f248de32ff531fc3f4063
>>  602290602 --alswrv      0     0   \_ asymmetric: IMA-CA: IMA/EVM
>> certificate signing key: 917665242851040704755d74629778f08d472d28
>
>> 
>> *****keyctl show %keyring:.ima*****
>> Keyring
>>  333847471 --alswrv      0     0  keyring: .ima
>>  684181163 --alswrv      0     0   \_ asymmetric: localhost.localdomain:
>> root signing key: ec0e32eb4c1fe167dbd7e9b58f7b88166895b433
>
>This looks good.  You've loaded the "local IMA-CA" used for verifying
>the IMA keys on the system keyring and loaded the signed IMA key on
>the .ima keyring.
>
>Mimi
>

Re: [Linux-ima-user] Invalid-HMAC Issue with IMA in Enforce Mode

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

On Wed, 2015-09-16 at 14:28 +0000, Calligan, Keith (US) wrote:
> Hi Mimi,
> 
> Thanks for the info.
> 
> I¹m assuming that you mean copy the IMA public key to the Kernel source
> directory? Do I need to specify the name of this file somewhere as I¹m
> compiling the Kernel? Is there a default name or location to copy this
> file?

No, we're discussing the public key (eg. local ima-ca) used for
verifying the signed IMA keys.  Until recently, all .x509 keys (DER
format) in the kernel build root were builtin into the kernel image and
loaded onto the system keyring.  Currently, the keys are stored in a
single file as defined in CONFIG_SYSTEM_TRUSTED_KEYS.  The keys in this
file are in PEM format.

> I downloaded the newer version of Dracut from the link you sent and was
> looking at the scripts in the 98integrity directory.  Most of it makes
> sense to me.  I see that the EVM encrypted key is loaded as part of the
> module as well.  I¹m assuming I would only need to enable ³integrity and
> masterkey² as I build the INITRAMFS?

The masterkey decrypts the EVM symmetric key.  In your case, without a
TPM, you're using a "user" type masterkey.

> 
> CONFIG_IMA_TRUSTED_KEYRING was already enabled when I built the Kernel.
> 
> Here is the output of the 2 commands you provided with my current
> configuration.
> 
> *****keyctl show %keyring:.system_keyring*****
> 
> 
> Keyring
>  299333826 --alswrv      0     0  keyring: .system_keyring
>  925626728 --alswrv      0     0   \_ asymmetric: Build time autogenerated
> kernel key: e209db6b68e553f3a73f248de32ff531fc3f4063
>  602290602 --alswrv      0     0   \_ asymmetric: IMA-CA: IMA/EVM
> certificate signing key: 917665242851040704755d74629778f08d472d28

> 
> *****keyctl show %keyring:.ima*****
> Keyring
>  333847471 --alswrv      0     0  keyring: .ima
>  684181163 --alswrv      0     0   \_ asymmetric: localhost.localdomain:
> root signing key: ec0e32eb4c1fe167dbd7e9b58f7b88166895b433

This looks good.  You've loaded the "local IMA-CA" used for verifying
the IMA keys on the system keyring and loaded the signed IMA key on
the .ima keyring.

Mimi

Re: [Linux-ima-user] Invalid-HMAC Issue with IMA in Enforce Mode

[Calligan, K. (US) <kca...@cy...>]

Hi Mimi,

Thanks for the info.

I¹m assuming that you mean copy the IMA public key to the Kernel source
directory? Do I need to specify the name of this file somewhere as I¹m
compiling the Kernel? Is there a default name or location to copy this
file?

I downloaded the newer version of Dracut from the link you sent and was
looking at the scripts in the 98integrity directory.  Most of it makes
sense to me.  I see that the EVM encrypted key is loaded as part of the
module as well.  I¹m assuming I would only need to enable ³integrity and
masterkey² as I build the INITRAMFS?

CONFIG_IMA_TRUSTED_KEYRING was already enabled when I built the Kernel.

Here is the output of the 2 commands you provided with my current
configuration.

*****keyctl show %keyring:.system_keyring*****


Keyring
 299333826 --alswrv      0     0  keyring: .system_keyring
 925626728 --alswrv      0     0   \_ asymmetric: Build time autogenerated
kernel key: e209db6b68e553f3a73f248de32ff531fc3f4063
 602290602 --alswrv      0     0   \_ asymmetric: IMA-CA: IMA/EVM
certificate signing key: 917665242851040704755d74629778f08d472d28



*****keyctl show %keyring:.ima*****
Keyring
 333847471 --alswrv      0     0  keyring: .ima
 684181163 --alswrv      0     0   \_ asymmetric: localhost.localdomain:
root signing key: ec0e32eb4c1fe167dbd7e9b58f7b88166895b433

Thanks,

Keith




On 9/16/15, 10:06 AM, "Mimi Zohar" <zo...@li...> wrote:

>On Wed, 2015-09-16 at 11:49 +0000, Calligan, Keith (US) wrote:
>
>> I am a little confused on the difference between the .ima, _ima and
>> occasionally seeing the _ivm.1 and _ivm.empty keyrings.  Am I loading
>> the key in the wrong place (or doing something else incorrectly)?
>
>Originally, keys being loaded onto the IMA keyring (_ima) did not need
>to be signed.  With the "CONFIG_IMA_TRUSTED_KEYRING" option enabled,
>only signed keys can be loaded onto the ".ima" keyring.  In addition,
>the public key needed for verifying these signed IMA keys needs to be
>loaded onto the .system_keyring.  The easiest method for loading this
>key on the system keyring is by recompiling the kernel with the public
>key builtin.
>
>The master dracut git repo
>(git://git.kernel.org/pub/scm/boot/dracut/dracut.git) contains a module
>for loading the signed IMA keys onto the .ima keyring.
> 
>> Here is my ³keyctl show² output
>
>With CONFIG_IMA_TRUSTED_KEYRING enabled, use:
>- keyctl show %keyring:.system_keyring
>- keyctl show %keyring:.ima
>
>Mimi
>
>> ‹‹‹‹‹‹‹‹‹
>> Session Keyring
>>  233684038 --alswrv      0     0  keyring: _ses
>>  787382555 --alswrv      0 65534   \_ keyring: _uid.0
>>   88392938 --alswrv      0     0       \_ user: kmk-user
>>  394259904 --alswrv      0     0       \_ keyring: _evm
>>  276216246 --alswrv      0     0       |   \_ user: 1ECAF89B087F7A55
>>  364658328 --alswrv      0     0       \_ keyring: _ima
>>   44707860 --als--v      0     0       |   \_ asymmetric:
>> localhost.localdomain: root signing key:
>> ec0e32eb4c1fe167dbd7e9b58f7b88166895b433
>>  995573136 --alswrv      0     0       \_ encrypted: evm-key
>> ‹‹‹‹‹‹‹‹‹
>> 
>> Also, as reference, I am using an XFS filesystem but have tried on
>> EXT4 systems as well.  Has anyone tried on XFS?
>> 
>> Sorry for the long email.  Any help is much appreciated.  Please let
>> me know if you need any additional information.
>> 
>> Thanks,
>> 
>> Keith
>

Re: [Linux-ima-user] Invalid-HMAC Issue with IMA in Enforce Mode

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

On Wed, 2015-09-16 at 11:49 +0000, Calligan, Keith (US) wrote:

> I am a little confused on the difference between the .ima, _ima and
> occasionally seeing the _ivm.1 and _ivm.empty keyrings.  Am I loading
> the key in the wrong place (or doing something else incorrectly)?

Originally, keys being loaded onto the IMA keyring (_ima) did not need
to be signed.  With the "CONFIG_IMA_TRUSTED_KEYRING" option enabled,
only signed keys can be loaded onto the ".ima" keyring.  In addition,
the public key needed for verifying these signed IMA keys needs to be
loaded onto the .system_keyring.  The easiest method for loading this
key on the system keyring is by recompiling the kernel with the public
key builtin.

The master dracut git repo
(git://git.kernel.org/pub/scm/boot/dracut/dracut.git) contains a module
for loading the signed IMA keys onto the .ima keyring.
 
> Here is my “keyctl show” output

With CONFIG_IMA_TRUSTED_KEYRING enabled, use: 
- keyctl show %keyring:.system_keyring
- keyctl show %keyring:.ima

Mimi

> —————————
> Session Keyring
>  233684038 --alswrv      0     0  keyring: _ses
>  787382555 --alswrv      0 65534   \_ keyring: _uid.0
>   88392938 --alswrv      0     0       \_ user: kmk-user
>  394259904 --alswrv      0     0       \_ keyring: _evm
>  276216246 --alswrv      0     0       |   \_ user: 1ECAF89B087F7A55
>  364658328 --alswrv      0     0       \_ keyring: _ima
>   44707860 --als--v      0     0       |   \_ asymmetric:
> localhost.localdomain: root signing key:
> ec0e32eb4c1fe167dbd7e9b58f7b88166895b433
>  995573136 --alswrv      0     0       \_ encrypted: evm-key
> —————————
> 
> Also, as reference, I am using an XFS filesystem but have tried on
> EXT4 systems as well.  Has anyone tried on XFS?
> 
> Sorry for the long email.  Any help is much appreciated.  Please let
> me know if you need any additional information.
> 
> Thanks,
> 
> Keith

[Linux-ima-user] Invalid-HMAC Issue with IMA in Enforce Mode

[Calligan, K. (US) <kca...@cy...>]

I am trying to setup IMA/EVM but appear to be having a problem with setting IMA in enforce mode.  I am getting an invalid-HMAC error.  If I run EVM=enforce (and IMA_APPRAISE=FIX), I don’t receive this error.

For background information, I am currently trying to get this to work on Kernel version 4.2 on Centos 7, but have tried Kernel 3.19 (and other Kernels newer than 3.13) and had the same types of issues.  I tried these different Kernels to rule-out the Kernel as the cause.

When I compiled the Kernel, I enabled everything under Security --> Integrity Subsystem with the exception of  FSUUID (Version 2) and “Require Signed User-Space Initialization.”  I used the scripts in the /usr/local/share/doc/ima-evm-utils directory to make the ima-local-ca.x509 and x509_ima.der files.  The ima-local-ca.x509 was copied to the Kernel source directory the x509_ima.der was copied to the /etc/keys directory on the filesystem, and the INITRAMFS so I could load before the system booted.  I also have the evmctl, kmk-user, evm-key, pubkey_evm.pem in the INITRAMFS.

When this issue is occurring, I have “ima_appraise=enforce ima_appraise_tcb evm=fix rd.break” for the bootline parameters.  The rd.break is so I can load they keys before the system is booted.  The script loads the kmk-user, evm-encrypted, IMA public key, and EVM public key and is shown below.  This is a non-TPM system.


—————————

keyctl add user kmk-user "`cat /etc/keys/kmk-user.blob`" @u > /dev/null
keyctl add encrypted evm-key "load `cat /etc/keys/evm-key`" @u > /dev/null

# import IMA public key
ima_id=`keyctl newring _ima @u`
evmctl import /etc/keys/x509_ima.der $ima_id

# import EVM public key
evm_id=`keyctl newring _evm @u`
evmctl import --rsa /etc/keys/pubkey_evm.pem $evm_id

# enable EVM
echo "1" > /sys/kernel/security/evm

# enable module checking
#echo "1" > /sys/kernel/security/module_check
—————————

To sign the binaries, I am running “evmctl sign –imasig $file.”  For non-ELF (binary) files, I am running “evmctl sign –imahash $file.”

When I am booted into the system in IMA_APPRAISE=fix mode and run “evmctl ima_verify $file,” I see that the file is verified OK.

When rebooting (after loading my script in initramfs), I receive the invalid-HMAC error.

I have a feeling that I am loading the keys incorrectly somehow.  Here is the output of “keyctl show” and “cat /proc/keys”.  Is there anything obvious to anyone on the list?

 —————————
02aa3014 I--Q---     1 perm 39010000     0     0 asymmetri localhost.localdomain: root signing key: ec0e32eb4c1fe167dbd7e9b58f7b88166895b433: X509.RSA 6895b433 []
0544c4ea I--Q---     1 perm 3f010000     0     0 user      kmk-user: 32
0dedbc46 I--Q---     7 perm 3f030000     0     0 keyring   _ses: 1
1076b9b6 I--Q---     1 perm 3f010000     0     0 user      1ECAF89B087F7A55: 142
11d778c2 I------     1 perm 1f0b0000     0     0 keyring   .system_keyring: 2
13e61baf I------     1 perm 1f0f0000     0     0 keyring   .ima: 1
15bc3e98 I--Q---     1 perm 3f010000     0     0 keyring   _ima: 1
177fedc0 I--Q---     2 perm 3f010000     0     0 keyring   _evm: 1
23e639aa I------     1 perm 1f030000     0     0 asymmetri IMA-CA: IMA/EVM certificate signing key: 917665242851040704755d74629778f08d472d28: X509.RSA 8d472d28 []
28c7c6ab I------     1 perm 1f030000     0     0 asymmetri localhost.localdomain: root signing key: ec0e32eb4c1fe167dbd7e9b58f7b88166895b433: X509.RSA 6895b433 []
2eee811b I--Q---     3 perm 1f3f0000     0 65534 keyring   _uid.0: 4
3474e666 I--Q---     1 perm 1f3f0000     0 65534 keyring   _uid_ses.0: 1
372bf168 I------     1 perm 1f030000     0     0 asymmetri Build time autogenerated kernel key: e209db6b68e553f3a73f248de32ff531fc3f4063: X509.RSA fc3f4063 []
3b573d90 I--Q---     1 perm 3f010000     0     0 encrypted evm-key: 139
—————————

I am a little confused on the difference between the .ima, _ima and occasionally seeing the _ivm.1 and _ivm.empty keyrings.  Am I loading the key in the wrong place (or doing something else incorrectly)?

Here is my “keyctl show” output

—————————
Session Keyring
 233684038 --alswrv      0     0  keyring: _ses
 787382555 --alswrv      0 65534   \_ keyring: _uid.0
  88392938 --alswrv      0     0       \_ user: kmk-user
 394259904 --alswrv      0     0       \_ keyring: _evm
 276216246 --alswrv      0     0       |   \_ user: 1ECAF89B087F7A55
 364658328 --alswrv      0     0       \_ keyring: _ima
  44707860 --als--v      0     0       |   \_ asymmetric: localhost.localdomain: root signing key: ec0e32eb4c1fe167dbd7e9b58f7b88166895b433
 995573136 --alswrv      0     0       \_ encrypted: evm-key
—————————

Also, as reference, I am using an XFS filesystem but have tried on EXT4 systems as well.  Has anyone tried on XFS?

Sorry for the long email.  Any help is much appreciated.  Please let me know if you need any additional information.

Thanks,

Keith

Re: [Linux-ima-user] [PATCH v3 1/2] Allows for persistent IMA policy sysfs entry;

[Petko M. <pe...@mi...>]

On 15-09-11 13:50:33, Mimi Zohar wrote:
> On Fri, 2015-09-11 at 19:54 +0300, Petko Manolov wrote:
> 
> > 
> > Actually it is a hard requirement in our usecase.  The last thing we want is 
> > somebody replacing the whole policy.  We may as well not have IMA enabled.
> 
> Glad to hear.  The prior policy patches that were posted replaced the policy.

If there are strong arguments for this we can always add a configuration option 
alternating between the two modes.

> > Last time i looked at this part of the code: the new policy will be accepted 
> > up to the faulty rule.  The rest will be ignored.
> 
> Is that safe?  I would prefer accepting all of the rules or nothing.  I don't 
> think it would be too hard to implement.  Perhaps, keep a pointer to the last 
> rule of the existing policy.  If there is a malformed rule, delete everything 
> from after the last existing policy rule.

No, it is not safe.  I was merely noting the current state of affairs.  What you 
suggest is the right thing to do and will be present in the next version of the 
patches.

> > In order to prevent this i've written user-space tool that generates 
> > syntactically correct rules.  However the issue must be addressed in some 
> > other way as wall.  Do you think it is worth to be more verbose when the 
> > parser runs into malformed rule?
> 
> It currently isn't easy to detect which rule is malformed.  Part of the 
> problem is that when there are too many messages, message are dropped. Adding 
> more messages might aggravate the situation.

There shouldn't be too many messages when rejecting new policy rule.

> With a patch for displaying the current policy, there's no need for displaying 
> the policies during boot or any other time that the policy is being extended.  
> We might then be able to actually see the malformed rule.  I'm pretty sure 
> someone has already posted an initial patch. [cc'ing linux-ima-user mailing 
> list]

This is also in my todo list, but i'd gladly take an existing patch.  It is also 
a good idea to make the 'read' property a configuration option.


		Petko

Re: [Linux-ima-user] [PATCH v3 1/2] Allows for persistent IMA policy sysfs entry;

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

On Fri, 2015-09-11 at 19:54 +0300, Petko Manolov wrote:

> On 15-09-11 09:58:22, Mimi Zohar wrote:
> > On Thu, 2015-09-10 at 14:17 +0300, Petko Manolov wrote:
> > > It is often useful to be able to add rules to the IMA policy without restarting
> > > the kernel.  This patch keeps the sysfs entry alive so the policy may be
> > > extended once new user is introduced along with corresponding credentials.
> > > 
> > > Signed-off-by: Petko Manolov <pe...@mi...>
> > 
> > Hi Petko,
> > 
> > I don't have a problem with extending the policy rules, as opposed to
> > replacing them, but my main concern is being able to do it safely.
> 
> Actually it is a hard requirement in our usecase.  The last thing we want is 
> somebody replacing the whole policy.  We may as well not have IMA enabled.

Glad to hear.   The prior policy patches that were posted replaced the
policy.

> > > ---
> > >  security/integrity/ima/Kconfig      | 15 +++++++++++++++
> > >  security/integrity/ima/ima_fs.c     |  4 ++++
> > >  security/integrity/ima/ima_policy.c | 17 +++++++++++++++++
> > >  3 files changed, 36 insertions(+)
> > > 
> > > diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
> > > index df30334..ebe7a907 100644
> > > --- a/security/integrity/ima/Kconfig
> > > +++ b/security/integrity/ima/Kconfig
> > > @@ -107,6 +107,21 @@ config IMA_DEFAULT_HASH
> > >  	default "sha512" if IMA_DEFAULT_HASH_SHA512
> > >  	default "wp512" if IMA_DEFAULT_HASH_WP512
> > > 
> > > +config IMA_DEV_POLICY
> > > +	bool "Enable persistent ima_policy entry in securityfs"
> > > +	depends on IMA
> > > +	default n
> > > +	help
> > > +
> > > +	  Prevents "ima_policy" removal in securityfs once the IMA policy is
> > > +	  written into the file. This allows for multiple IMA policy updates
> > > +	  while the system is running.
> > 
> > Currently, when we attempt to load a new policy, if any of the rules are 
> > malformed, loading the new policy fails.  It looks like the new rules extend 
> > the existing list.  What should happen if one of the new rules is malformed?  
> > Will the entire set of new rules be removed?
> 
> Last time i looked at this part of the code: the new policy will be accepted up 
> to the faulty rule.  The rest will be ignored.

Is that safe?  I would prefer accepting all of the rules or nothing.  I
don't think it would be too hard to implement.  Perhaps, keep a pointer
to the last rule of the existing policy.  If there is a malformed rule,
delete everything from after the last existing policy rule.

> In order to prevent this i've written user-space tool that generates 
> syntactically correct rules.  However the issue must be addressed in some other 
> way as wall.  Do you think it is worth to be more verbose when the parser runs 
> into malformed rule?

It currently isn't easy to detect which rule is malformed.  Part of the
problem is that when there are too many messages, message are dropped.
Adding more messages might aggravate the situation.

With a patch for displaying the current policy, there's no need for
displaying the policies during boot or any other time that the policy is
being extended.  We might then be able to actually see the malformed
rule.   I'm pretty sure someone has already posted an initial patch.
[cc'ing linux-ima-user mailing list] 

> > > +	  WARNING: Potential security hole - should not be used in production
> > > +	  grade kernels!
> > 
> > Agreed.  Like all other data the kernel consumes, policies should be signed 
> > and verified before being used.  I could see allowing new rules to be added, 
> > only if they're signed.  (I think Dmitry has some code that defines a new hook 
> > called POLICY_CHECK.)
> 
> POLICY_CHECK not mainlined yet.  Any plans for this to happen soon?

The last time the patches were posted, it was included in a patch bomb.
Lets try to extract the worthwhile patches.  Maybe clean them up a bit. 

> Our setup refuses to read anything that is not signed, including the new policy 
> file(s).  This, however, does hot save us from piping the rules from a script...
> 
> > > +	  If unsure, say N.
> > > +
> > >  config IMA_APPRAISE
> > >  	bool "Appraise integrity measurements"
> > >  	depends on IMA
> > > diff --git a/security/integrity/ima/ima_fs.c b/security/integrity/ima/ima_fs.c
> > > index 816d175..b0df2b8 100644
> > > --- a/security/integrity/ima/ima_fs.c
> > > +++ b/security/integrity/ima/ima_fs.c
> > > @@ -337,8 +337,12 @@ static int ima_release_policy(struct inode *inode, struct file *file)
> > >  		return 0;
> > >  	}
> > >  	ima_update_policy();
> > > +#ifndef	CONFIG_IMA_DEV_POLICY
> > >  	securityfs_remove(ima_policy);
> > >  	ima_policy = NULL;
> > > +#else
> > > +	clear_bit(IMA_FS_BUSY, &ima_fs_flags);
> > > +#endif
> > >  	return 0;
> > >  }
> > > 
> > > diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
> > > index 3997e20..eef99d6 100644
> > > --- a/security/integrity/ima/ima_policy.c
> > > +++ b/security/integrity/ima/ima_policy.c
> > > @@ -140,6 +140,19 @@ static struct list_head *ima_rules;
> > >  static DEFINE_MUTEX(ima_rules_mutex);
> > > 
> > >  static int ima_policy __initdata;
> > > +
> > > +/*
> > > + * macros to lock/unlock code that is related to dynamically
> > > + * loadable IMA policy.
> > > + */
> > > +#ifdef	CONFIG_IMA_DEV_POLICY
> > > +#define	ima_dev_policy_lock()	mutex_lock(&ima_rules_mutex)
> > > +#define	ima_dev_policy_unlock()	mutex_unlock(&ima_rules_mutex)
> > > +#else
> > > +#define	ima_dev_policy_lock()
> > > +#define	ima_dev_policy_unlock()
> > > +#endif	/* CONFIG_IMA_DEV_POLICY */
> > > +
> > 
> > As the existing policy rules never changed, we didn't need locking, With this 
> > change, the list of rules can be extended so we need locking. Instead of using 
> > a mutex, as the number of readers is far greater than writers, we should use 
> > RCU locking.
> 
> Yeah, this was stupid on my part.  I should have done something better.  Will 
> replace the mutex with proper RCU locking.

Thanks.

Mimi

[Linux-ima-user] Fwd: [PATCH 1/1] integrity: prevent loading untrusted certificates to IMA trusted keyring

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

FYI

---------- Forwarded message ----------
From: Dmitry Kasatkin <dmi...@gm...>
Date: Thu, Sep 10, 2015 at 10:06 PM
Subject: [PATCH 1/1] integrity: prevent loading untrusted certificates
to IMA trusted keyring
To: zo...@li..., lin...@vg...,
lin...@vg...
Cc: Dmitry Kasatkin <dmi...@hu...>, st...@vg...


If IMA_LOAD_X509 is enabled either directly or indirectly via
IMA_APPRAISE_SIGNED_INIT, it enables certificate loading to the IMA trusted
keyring from the kernel. Due to the overlook, KEY_ALLOC_TRUSTED was used in the
key_create_or_update() to create keys within the kernel, which caused
overriding certificate verification result and allowed to load self-signed or
wrongly signed certificates.

This patch just removes this option.

Signed-off-by: Dmitry Kasatkin <dmi...@hu...>
Cc:  <st...@vg...> # 3.19+
---
 security/integrity/digsig.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
index 36fb6b5..5be9ffb 100644
--- a/security/integrity/digsig.c
+++ b/security/integrity/digsig.c
@@ -105,7 +105,7 @@ int __init integrity_load_x509(const unsigned int
id, const char *path)
                                   rc,
                                   ((KEY_POS_ALL & ~KEY_POS_SETATTR) |
                                    KEY_USR_VIEW | KEY_USR_READ),
-                                  KEY_ALLOC_NOT_IN_QUOTA | KEY_ALLOC_TRUSTED);
+                                  KEY_ALLOC_NOT_IN_QUOTA);
        if (IS_ERR(key)) {
                rc = PTR_ERR(key);
                pr_err("Problem loading X.509 certificate (%d): %s\n",
--
2.1.4



-- 
Thanks,
Dmitry

Re: [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...>]

On Thu, 2015-08-06 at 14:23 -0400, Mimi Zohar wrote:
> The existing IMA/EVM can provide complete protection against on-line and
> off-line attacks, given the right policy. If the policy says that root
> cannot read or execute any file unless it is signed, then you have a
> complete Biba model. We don't do this by default, as most systems are
> badly designed and won't even boot with such a policy.

You are right. I had come to the same conclusion (complete protection of
a read-only file system works), but forgot to mention it here because
the focus of the mail thread was on systems with read/write files.

-- 
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] example policy for appraisal with read/write files (was: Re: IMA (latest patches) do not allow creation of in policy files.)

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

On Thu, 2015-08-06 at 12:39 +0200, Patrick Ohly wrote:
> On Wed, 2015-08-05 at 16:35 -0400, Mimi Zohar wrote:
> > On Tue, 2015-08-04 at 15:17 +0200, Patrick Ohly wrote:
> > 
> > > 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.
> > 
> > True, the builtin appraisal policy only verifies files owned by root.
> > This policy could be replaced with a more comprehensive one similar to
> > the measurement policy, where all files executed or read by root are
> > appraised, or even with a more constrained policy that appraises all
> > files.
> > 
> > You might be interested in David Safford's presentation at last year's
> > LSS titled "Extending the Linux Integrity Subsystem for TCB Protection"
> > -
> > http://kernsec.org/wiki/index.php/Linux_Security_Summit_2014/Abstracts/Safford
> 
> The threat model described there is explicitly about attacks on a
> running device, and in that context IMA appraisal starts to make a lot
> more sense to me than in the offline attack scenario that I described.
> 
> This IMA "locked" mode is not yet in the upstream kernel, is it? And
> without it, IMA appraisal still has to be considered ineffective (or at
> least not as complete as it should be) regarding online attacks?

The existing IMA/EVM can provide complete protection against on-line and
off-line attacks, given the right policy. If the policy says that root
cannot read or execute any file unless it is signed, then you have a
complete Biba model. We don't do this by default, as most systems are
badly designed and won't even boot with such a policy.

The problem is privileged applications which write and read sensitive
local files, which cannot be securely signed. The coming locked mode can
protect these.  In the meantime, there are some Linux environments
(hypervisor, embedded...) which don't have such troublesome
applications, and which can have all TCB files signed, and can have a
policy for complete protection. The existing IMA and EVM are useful in
these environments.

Dave Safford
Mimi Zohar

Re: [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...>]

On Wed, 2015-08-05 at 16:35 -0400, Mimi Zohar wrote:
> On Tue, 2015-08-04 at 15:17 +0200, Patrick Ohly wrote:
> 
> > 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.
> 
> True, the builtin appraisal policy only verifies files owned by root.
> This policy could be replaced with a more comprehensive one similar to
> the measurement policy, where all files executed or read by root are
> appraised, or even with a more constrained policy that appraises all
> files.
> 
> You might be interested in David Safford's presentation at last year's
> LSS titled "Extending the Linux Integrity Subsystem for TCB Protection"
> -
> http://kernsec.org/wiki/index.php/Linux_Security_Summit_2014/Abstracts/Safford

The threat model described there is explicitly about attacks on a
running device, and in that context IMA appraisal starts to make a lot
more sense to me than in the offline attack scenario that I described.

This IMA "locked" mode is not yet in the upstream kernel, is it? And
without it, IMA appraisal still has to be considered ineffective (or at
least not as complete as it should be) regarding online attacks?

-- 
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] example policy for appraisal with read/write files (was: Re: IMA (latest patches) do not allow creation of in policy files.)

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

On Tue, 2015-08-04 at 15:17 +0200, Patrick Ohly wrote:

> 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.

True, the builtin appraisal policy only verifies files owned by root.
This policy could be replaced with a more comprehensive one similar to
the measurement policy, where all files executed or read by root are
appraised, or even with a more constrained policy that appraises all
files.

You might be interested in David Safford's presentation at last year's
LSS titled "Extending the Linux Integrity Subsystem for TCB Protection"
-
http://kernsec.org/wiki/index.php/Linux_Security_Summit_2014/Abstracts/Safford

Mimi

>      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?