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

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

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

On 15-06-10 09:01:54, Curtis Veit wrote:
> I'm going to break this into several replies due to the length...
> On Wed, Jun 10, 2015 at 09:22:30AM -0400, Mimi Zohar wrote:
> > On Tue, 2015-06-09 at 18:59 -0600, Curtis Veit wrote:
> > > I have had excellent success with IMA appraising signed executables.
> > > I am trying to take the next step by adding other rules but hit a 
> > > number of issues.
> > > 
> > > my added rules for executables:
> > >   appraise appraise_type=imasig func=FILE_MMAP mask=MAY_EXEC
> > >   appraise appraise_type=imasig func=BPRM_CHECK mask=MAY_EXEC
> > >   appraise appraise_type=imasig func=FILE_CHECK mask=MAY_EXEC
> > > One issue on executables, I seem to have broken my previously 
> > > correct behavior. I was able to prevent execution of the command 
> > > "sh foo.sh" where bash is signed but foo.sh is not.  
> > > The above prevents "foo.sh" but allows "sh foo.sh". 
> > > Can anyone clue me in?
> > 
> > source/sh/include opens the file, but the FILE_CHECK rule is only
> > appraising files opened MAY_EXEC.  This rule is not needed.
> > 
> Thanks, explains why adding that rule did not help...  
> I am certain I found a way to prevent 
>   sh  foo.sh
> from running the script foo.sh if it was not signed. The first two
> rules above do not accomplish that.  What rules should be used to 
> prevent 'sh' from running an unsigned script?

Have you tried:

appraise appraise_type=imasig func=FILE_CHECK mask=MAY_READ

I guess an attempt to read unsigned 'foo.sh' should fail.


		Petko

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

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

On Wed, 2015-06-10 at 10:32 -0600, Curtis Veit wrote:
> On Wed, Jun 10, 2015 at 11:40:01AM -0400, Mimi Zohar wrote:
> > On Wed, 2015-06-10 at 09:29 -0600, Curtis Veit wrote:
> > > On Wed, Jun 10, 2015 at 09:22:30AM -0400, Mimi Zohar wrote:
> > > > On Tue, 2015-06-09 at 18:59 -0600, Curtis Veit wrote:
> > > > > I am also noticing that when using appraise rules looking for a hash 
> > > > > that I can get errors when I update a file and then update the hash. 
> > > > > Is there an approach for solving that? (Hopefully without either 
> > > > > dropping appraise and only measuring or without rewriting various 
> > > > > system utils to be IMA aware.) 
> > > > 
> > > > As long as the file is in policy, an updated hash should automatically
> > > > be written out on file close.   When security.ima is a signature,
> > > > neither the file or the file signature can be modified.  I've just
> > > > upstreamed a patch by Dmitry Kasitkin to also prevent userspace from
> > > > modifying the security.ima hash value.
> > > > 
> > > > c68ed80 ima: limit file hash setting by user to fix and log modes
> > > Thanks for the reference, looks like I need to rethink a few things.
> > > > 
> > > Sounds like I need to check my rules and try this out again.
> > > Just one question about the auto-update of the hash on file close...
> > > I am running 3.18 kernel. Is the auto update behaviour present in
> > > that version?
> > > 
> > > If not, when did it appear?
> > 
> > Setting the file hash has been there from the beginning.  For
> > development it made sense to permit userspace (eg. root) to change the
> > file hash, but there's really no good reason for it.  This patch
> > prevents userspace from modifying it.
> > 
> > Mimi
> 
> Two separate thoughts:
> First, I am wondering how this will affect my ability to deploy an embedded
> system using IMA. 
> 
> Does it allow pre-writing hashes before an image is deployed?
> 
> Currently I build an image of the system and create the
> signatures and hashes as I deploy the image to the disk. What I hope to do is 
> just to sign and hash the image once and deploy with those in place (currently
> that does not work for me - see the recent post about tar and rsync.) 
> 
> Second,
> Just exactly what is the expected sequence of events that is allowed in
> signing (signature and hashes) a fresh system?  How about when installing
> updates?
> 
> Sorry but I feel like I am missing something crucial here.

In "fix" mode, the file can be properly labeled.  Add "ima_appraise=tcb"
to the boot command line.

Mimi

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

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

On Wed, 2015-06-10 at 09:01 -0600, Curtis Veit wrote:
> I'm going to break this into several replies due to the length...
> On Wed, Jun 10, 2015 at 09:22:30AM -0400, Mimi Zohar wrote:
> > On Tue, 2015-06-09 at 18:59 -0600, Curtis Veit wrote:
> > > I have had excellent success with IMA appraising signed executables.
> > > I am trying to take the next step by adding other rules but hit a 
> > > number of issues.
> > > 
> > > my added rules for executables:
> > >   appraise appraise_type=imasig func=FILE_MMAP mask=MAY_EXEC
> > >   appraise appraise_type=imasig func=BPRM_CHECK mask=MAY_EXEC
> > >   appraise appraise_type=imasig func=FILE_CHECK mask=MAY_EXEC
> > > One issue on executables, I seem to have broken my previously 
> > > correct behavior. I was able to prevent execution of the command 
> > > "sh foo.sh" where bash is signed but foo.sh is not.  
> > > The above prevents "foo.sh" but allows "sh foo.sh". 
> > > Can anyone clue me in?
> > 
> > source/sh/include opens the file, but the FILE_CHECK rule is only
> > appraising files opened MAY_EXEC.  This rule is not needed.
> > 
> Thanks, explains why adding that rule did not help...  
> I am certain I found a way to prevent 
>   sh  foo.sh
> from running the script foo.sh if it was not signed. The first two
> rules above do not accomplish that.  What rules should be used to 
> prevent 'sh' from running an unsigned script?

With the existing hooks, there is no good way of differentiating between
between an interpreter reading a file and any other read.  Different
methods have been proposed over the years:
- Modifying the interpreter to take measurements - original method prior
to IMA being upstreamed as described in the original paper.
- Rely on an LSM to enforce access control.  Based on the LSM labels,
appraise file integrity. 
- More recently, prevent "mutable" files from changing after a certain
point in the boot process.  Refer to Dave Safford's "Extending the Linux
Integrity Subsystem for TCB Protection" 
http://kernsec.org/wiki/index.php/Linux_Security_Summit_2014/Abstracts/Safford 

> > > 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.
> 
> Yes I am very interested in starting to use LSM labels. Is there any 
> helpful documentation like examples or tutorials?

For SELinux, there should be quite a bit of material online.  Perhaps
someone on this mailing list can direct you to the Smack documentation.
 
> Does that require the use of either Smack or Selinux for the labels or
> is it possible to create arbitrary labels for ad hoc IMA related purposes?
> 
> I'd be happy to write something up if I can get a better understanding.

Both SElinux and Smack prevent their labels from being modified.

Mimi

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

[Curtis V. <cr...@so...>]

On Wed, Jun 10, 2015 at 11:40:01AM -0400, Mimi Zohar wrote:
> On Wed, 2015-06-10 at 09:29 -0600, Curtis Veit wrote:
> > On Wed, Jun 10, 2015 at 09:22:30AM -0400, Mimi Zohar wrote:
> > > On Tue, 2015-06-09 at 18:59 -0600, Curtis Veit wrote:
> > > > I am also noticing that when using appraise rules looking for a hash 
> > > > that I can get errors when I update a file and then update the hash. 
> > > > Is there an approach for solving that? (Hopefully without either 
> > > > dropping appraise and only measuring or without rewriting various 
> > > > system utils to be IMA aware.) 
> > > 
> > > As long as the file is in policy, an updated hash should automatically
> > > be written out on file close.   When security.ima is a signature,
> > > neither the file or the file signature can be modified.  I've just
> > > upstreamed a patch by Dmitry Kasitkin to also prevent userspace from
> > > modifying the security.ima hash value.
> > > 
> > > c68ed80 ima: limit file hash setting by user to fix and log modes
> > Thanks for the reference, looks like I need to rethink a few things.
> > > 
> > Sounds like I need to check my rules and try this out again.
> > Just one question about the auto-update of the hash on file close...
> > I am running 3.18 kernel. Is the auto update behaviour present in
> > that version?
> > 
> > If not, when did it appear?
> 
> Setting the file hash has been there from the beginning.  For
> development it made sense to permit userspace (eg. root) to change the
> file hash, but there's really no good reason for it.  This patch
> prevents userspace from modifying it.
> 
> Mimi

Two separate thoughts:
First, I am wondering how this will affect my ability to deploy an embedded
system using IMA. 

Does it allow pre-writing hashes before an image is deployed?

Currently I build an image of the system and create the
signatures and hashes as I deploy the image to the disk. What I hope to do is 
just to sign and hash the image once and deploy with those in place (currently
that does not work for me - see the recent post about tar and rsync.) 

Second,
Just exactly what is the expected sequence of events that is allowed in
signing (signature and hashes) a fresh system?  How about when installing
updates?

Sorry but I feel like I am missing something crucial here.

Curtis

[Linux-ima-user] How can I replace signed files?

[Curtis V. <cr...@so...>]

History: I am working on embedded systems and working toward a cut-over to
a version supporting IMA. Currently on kernel 3.18.2 (but should update when
I have time)

I have been using tar and/or rsync to deploy and update my target systems. 
I have been anticipating a cut over to using IMA so I had planned on using 
the following commands to carry the security signatures/hashes to the target 
system.

capture the system:
tar -C devspace --numeric-owner --acls --xattrs -zcvplf file.tar.gz .

and to deploy to a mounted target disk:
tar -C mnt_point --numeric_owner --acls --xattrs -zxvplf file.tar.gz

Interestingly enough I can see the security xattrs inside the ungziped
tar file that I create but they seem to disappear when I unpack them.

I am unpacking on a filesystem that seems to support xattrs fine as I 
can create them locally with evmctl.

Similarly I have tried
rsync -avAHX --numeric-ids --specials --devices devspace/* root@target/
This is perhaps more mysterious as I am successfully getting the 
security.evm=0x...  xattrs but the security.ima=0x... xattrs have 
disappeared. (does rsync only support sending a single xattr?)
If I was on a really recent kernel I would wonder if Dimetry's recent
patch to not allow user-space to modify the ima xattr was involved.

Comments? Suggestions?  Seems like work was going on for cpio support, 
do I need to be using that?

Best regards,
Curtis

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

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

On Wed, 2015-06-10 at 09:29 -0600, Curtis Veit wrote:
> On Wed, Jun 10, 2015 at 09:22:30AM -0400, Mimi Zohar wrote:
> > On Tue, 2015-06-09 at 18:59 -0600, Curtis Veit wrote:
> > > I am also noticing that when using appraise rules looking for a hash 
> > > that I can get errors when I update a file and then update the hash. 
> > > Is there an approach for solving that? (Hopefully without either 
> > > dropping appraise and only measuring or without rewriting various 
> > > system utils to be IMA aware.) 
> > 
> > As long as the file is in policy, an updated hash should automatically
> > be written out on file close.   When security.ima is a signature,
> > neither the file or the file signature can be modified.  I've just
> > upstreamed a patch by Dmitry Kasitkin to also prevent userspace from
> > modifying the security.ima hash value.
> > 
> > c68ed80 ima: limit file hash setting by user to fix and log modes
> Thanks for the reference, looks like I need to rethink a few things.
> > 
> Sounds like I need to check my rules and try this out again.
> Just one question about the auto-update of the hash on file close...
> I am running 3.18 kernel. Is the auto update behaviour present in
> that version?
> 
> If not, when did it appear?

Setting the file hash has been there from the beginning.  For
development it made sense to permit userspace (eg. root) to change the
file hash, but there's really no good reason for it.  This patch
prevents userspace from modifying it.

Mimi

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

[Curtis V. <cr...@so...>]

On Wed, Jun 10, 2015 at 09:22:30AM -0400, Mimi Zohar wrote:
> On Tue, 2015-06-09 at 18:59 -0600, Curtis Veit wrote:
> > I am also noticing that when using appraise rules looking for a hash 
> > that I can get errors when I update a file and then update the hash. 
> > Is there an approach for solving that? (Hopefully without either 
> > dropping appraise and only measuring or without rewriting various 
> > system utils to be IMA aware.) 
> 
> As long as the file is in policy, an updated hash should automatically
> be written out on file close.   When security.ima is a signature,
> neither the file or the file signature can be modified.  I've just
> upstreamed a patch by Dmitry Kasitkin to also prevent userspace from
> modifying the security.ima hash value.
> 
> c68ed80 ima: limit file hash setting by user to fix and log modes
Thanks for the reference, looks like I need to rethink a few things.
> 
Sounds like I need to check my rules and try this out again.
Just one question about the auto-update of the hash on file close...
I am running 3.18 kernel. Is the auto update behaviour present in
that version?

If not, when did it appear?

Curtis

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

[Curtis V. <cr...@so...>]

On Wed, Jun 10, 2015 at 09:22:30AM -0400, Mimi Zohar wrote:
> 
> > I then attempt to protect some things owned by root like config files
> > with:
> >   appraise appraise_type=imasig func=FILE_CHECK mask=MAY_READ fowner=0
> > Unfortunatly I find that this gives me problems with things I need to
> > update like /etc/ld.so.cache , i suppose I can do one of the following:
> > - Switch to allowing hashes
> > - switch to measuring not appraising
> > - install a signed update /etc/ld.so.cache with signed libraries.
> 
> Replacing signed files as opposed to updating should work. 

Right, I have definatly made this mistake before. If a file ends up
defined as immutable the only way to update is to replace with a signed 
version from the official build machine that can sign the file. (or to 
change the rules so that hashed files are allowed.) 

I guess the question should have been, "Which solution is most acceptable
for the case where a file must be updated on the machine?"
In the case on an embedded system I can replace this file with a signed
one from the build machine. But this will be unacceptable for general
use case as every target machine may have a different set of libraries
installed. (So ld.so.cache must be updated on the system)

The "old" solution used when placing a system on a ro fs was to create 
a link on the ro fs to a rw fs that would have the actual file.
Is that acceptable for our purpose? (ie. we seem to be able to have
different rules on a per-filesystem basis.)

> 
> > - make this a link to a file in an fs with different rules.
> > or maybe something else... A recommendation would be greatly appreciated. 
> > ( I can see that this is going to be tricky for general systems. I am 
> > working on an embedded device so should be able to solve more easily - 
> > but would prefer a solution that is also good for general desktops.)
> 
> Thanks for thinking about the other usecase scenarios.  Package managers
> (eg. rpm/deb) need to support including and installing file signatures.
> The distros could then start including them.  
> 
> Would you be interested in reviewing these package manager patches?
> 
Yes, I would like to review the patches. Hopefully I can be helpful.

Let me know where to find them.

Best regards,
Curtis

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

[Curtis V. <cr...@so...>]

I'm going to break this into several replies due to the length...
On Wed, Jun 10, 2015 at 09:22:30AM -0400, Mimi Zohar wrote:
> On Tue, 2015-06-09 at 18:59 -0600, Curtis Veit wrote:
> > I have had excellent success with IMA appraising signed executables.
> > I am trying to take the next step by adding other rules but hit a 
> > number of issues.
> > 
> > my added rules for executables:
> >   appraise appraise_type=imasig func=FILE_MMAP mask=MAY_EXEC
> >   appraise appraise_type=imasig func=BPRM_CHECK mask=MAY_EXEC
> >   appraise appraise_type=imasig func=FILE_CHECK mask=MAY_EXEC
> > One issue on executables, I seem to have broken my previously 
> > correct behavior. I was able to prevent execution of the command 
> > "sh foo.sh" where bash is signed but foo.sh is not.  
> > The above prevents "foo.sh" but allows "sh foo.sh". 
> > Can anyone clue me in?
> 
> source/sh/include opens the file, but the FILE_CHECK rule is only
> appraising files opened MAY_EXEC.  This rule is not needed.
> 
Thanks, explains why adding that rule did not help...  
I am certain I found a way to prevent 
  sh  foo.sh
from running the script foo.sh if it was not signed. The first two
rules above do not accomplish that.  What rules should be used to 
prevent 'sh' from running an unsigned script?


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

Yes I am very interested in starting to use LSM labels. Is there any 
helpful documentation like examples or tutorials?

Does that require the use of either Smack or Selinux for the labels or
is it possible to create arbitrary labels for ad hoc IMA related purposes?

I'd be happy to write something up if I can get a better understanding.

Regards,
Curtis

Re: [Linux-ima-user] need comments on gid and fgroup patch

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

On Tue, 2015-06-09 at 17:20 -0600, Curtis Veit wrote:
> Here is a preliminary patch that I've been using that adds gid and fgroup
> functionality to IMA similar to uid and fowner. (as discussed in January,
> very sorry about the delay getting this out!)
> It seems to test fine but I want to get comments and clean it up a bit before
> submitting...

Please include the motivation for defining these new fields in the patch
description.

> My biggest nitpick is wondering if I should be doing something with
> LSM_SUBJ_GROUP (see the commented out line in the patch near 212)
> 
> Anyway looking for comments before I sign off on it.

A couple of patches in the #for-next-4.2 branch still need to be
upstreamed. Could you  please rebase your patch on top of them.

Thanks!

Mimi

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

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

On Tue, 2015-06-09 at 18:59 -0600, Curtis Veit wrote:
> I have had excellent success with IMA appraising signed executables.
> I am trying to take the next step by adding other rules but hit a 
> number of issues.
> 
> my added rules for executables:
>   appraise appraise_type=imasig func=FILE_MMAP mask=MAY_EXEC
>   appraise appraise_type=imasig func=BPRM_CHECK mask=MAY_EXEC
>   appraise appraise_type=imasig func=FILE_CHECK mask=MAY_EXEC
> One issue on executables, I seem to have broken my previously 
> correct behavior. I was able to prevent execution of the command 
> "sh foo.sh" where bash is signed but foo.sh is not.  
> The above prevents "foo.sh" but allows "sh foo.sh". 
> Can anyone clue me in?

source/sh/include opens the file, but the FILE_CHECK rule is only
appraising files opened MAY_EXEC.  This rule is not needed.

> 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 then attempt to protect some things owned by root like config files
> with:
>   appraise appraise_type=imasig func=FILE_CHECK mask=MAY_READ fowner=0
> Unfortunatly I find that this gives me problems with things I need to
> update like /etc/ld.so.cache , i suppose I can do one of the following:
> - Switch to allowing hashes
> - switch to measuring not appraising
> - install a signed update /etc/ld.so.cache with signed libraries.

Replacing signed files as opposed to updating should work. 

> - make this a link to a file in an fs with different rules.
> or maybe something else... A recommendation would be greatly appreciated. 
> ( I can see that this is going to be tricky for general systems. I am 
> working on an embedded device so should be able to solve more easily - 
> but would prefer a solution that is also good for general desktops.)

Thanks for thinking about the other usecase scenarios.  Package managers
(eg. rpm/deb) need to support including and installing file signatures.
The distros could then start including them.  

Would you be interested in reviewing these package manager patches?

> I am also noticing that when using appraise rules looking for a hash 
> that I can get errors when I update a file and then update the hash. 
> Is there an approach for solving that? (Hopefully without either 
> dropping appraise and only measuring or without rewriting various 
> system utils to be IMA aware.) 

As long as the file is in policy, an updated hash should automatically
be written out on file close.   When security.ima is a signature,
neither the file or the file signature can be modified.  I've just
upstreamed a patch by Dmitry Kasitkin to also prevent userspace from
modifying the security.ima hash value.

c68ed80 ima: limit file hash setting by user to fix and log modes

> Or perhaps my test was flawed? 
> What is the correct approach to using appraisal with files that 
> are updated by software on the running system?

This shouldn't be a problem.

Mimi

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

[Curtis V. <cr...@so...>]

I have had excellent success with IMA appraising signed executables.
I am trying to take the next step by adding other rules but hit a 
number of issues.

my added rules for executables:
  appraise appraise_type=imasig func=FILE_MMAP mask=MAY_EXEC
  appraise appraise_type=imasig func=BPRM_CHECK mask=MAY_EXEC
  appraise appraise_type=imasig func=FILE_CHECK mask=MAY_EXEC
One issue on executables, I seem to have broken my previously 
correct behavior. I was able to prevent execution of the command 
"sh foo.sh" where bash is signed but foo.sh is not.  
The above prevents "foo.sh" but allows "sh foo.sh". 
Can anyone clue me in?

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


I then attempt to protect some things owned by root like config files
with:
  appraise appraise_type=imasig func=FILE_CHECK mask=MAY_READ fowner=0
Unfortunatly I find that this gives me problems with things I need to
update like /etc/ld.so.cache , i suppose I can do one of the following:
- Switch to allowing hashes
- switch to measuring not appraising
- install a signed update /etc/ld.so.cache with signed libraries.
- make this a link to a file in an fs with different rules.
or maybe something else... A recommendation would be greatly appreciated. 
( I can see that this is going to be tricky for general systems. I am 
working on an embedded device so should be able to solve more easily - 
but would prefer a solution that is also good for general desktops.)

I am also noticing that when using appraise rules looking for a hash 
that I can get errors when I update a file and then update the hash. 
Is there an approach for solving that? (Hopefully without either 
dropping appraise and only measuring or without rewriting various 
system utils to be IMA aware.) Or perhaps my test was flawed? 
What is the correct approach to using appraisal with files that 
are updated by software on the running system?

Thanks very much!
Curtis

[Linux-ima-user] need comments on gid and fgroup patch

[Curtis V. <cr...@so...>]

Here is a preliminary patch that I've been using that adds gid and fgroup
functionality to IMA similar to uid and fowner. (as discussed in January,
very sorry about the delay getting this out!)
It seems to test fine but I want to get comments and clean it up a bit before
submitting...
My biggest nitpick is wondering if I should be doing something with
LSM_SUBJ_GROUP (see the commented out line in the patch near 212)

Anyway looking for comments before I sign off on it.

Thanks,
Curtis


6def190 IMA support for gid and fgroup
diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy
index d0d0c57..556a827 100644
--- a/Documentation/ABI/testing/ima_policy
+++ b/Documentation/ABI/testing/ima_policy
@@ -31,7 +31,9 @@ Description:
 			fsmagic:= hex value
 			fsuuid:= file system UUID (e.g 8bcbe394-4f13-4144-be8e-5aa9ea2ce2f6)
 			uid:= decimal value
+			gid:= decimal value, the group id of the access attempt
 			fowner:=decimal value
+			fgroup:=decimal value, group id of the file owner
 		lsm:  	are LSM specific
 		option:	appraise_type:= [imasig]
 
diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
index d1eefb9..e1b7864 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -27,6 +27,8 @@
 #define IMA_UID		0x0008
 #define IMA_FOWNER	0x0010
 #define IMA_FSUUID	0x0020
+#define IMA_GID		0x0040
+#define IMA_FGROUP	0x0080
 
 #define UNKNOWN		0
 #define MEASURE		0x0001	/* same as IMA_MEASURE */
@@ -52,6 +54,8 @@ struct ima_rule_entry {
 	u8 fsuuid[16];
 	kuid_t uid;
 	kuid_t fowner;
+	kgid_t gid;
+	kgid_t fgroup;
 	struct {
 		void *rule;	/* LSM file metadata specific */
 		void *args_p;	/* audit value */
@@ -61,7 +65,8 @@ struct ima_rule_entry {
 
 /*
  * Without LSM specific knowledge, the default policy can only be
- * written in terms of .action, .func, .mask, .fsmagic, .uid, and .fowner
+ * written in terms of .action, .func, .mask, .fsmagic, .uid, .fowner
+ * .gid, and .fgroup.
  */
 
 /*
@@ -192,6 +197,10 @@ static bool ima_match_rules(struct ima_rule_entry *rule,
 		return false;
 	if ((rule->flags & IMA_FOWNER) && !uid_eq(rule->fowner, inode->i_uid))
 		return false;
+	if ((rule->flags & IMA_GID) && !gid_eq(rule->gid, cred->gid))
+		return false;
+	if ((rule->flags & IMA_FGROUP) && !gid_eq(rule->fgroup, inode->i_gid))
+		return false;
 	for (i = 0; i < MAX_LSM_RULES; i++) {
 		int rc = 0;
 		u32 osid, sid;
@@ -212,6 +221,7 @@ retry:
 							NULL);
 			break;
 		case LSM_SUBJ_USER:
+		//case LSM_SUBJ_GROUP: //if needed
 		case LSM_SUBJ_ROLE:
 		case LSM_SUBJ_TYPE:
 			security_task_getsecid(tsk, &sid);
@@ -374,7 +384,8 @@ enum {
 	Opt_obj_user, Opt_obj_role, Opt_obj_type,
 	Opt_subj_user, Opt_subj_role, Opt_subj_type,
 	Opt_func, Opt_mask, Opt_fsmagic, Opt_uid, Opt_fowner,
-	Opt_appraise_type, Opt_fsuuid, Opt_permit_directio
+	Opt_appraise_type, Opt_fsuuid, Opt_permit_directio,
+	Opt_gid, Opt_fgroup
 };
 
 static match_table_t policy_tokens = {
@@ -395,6 +406,8 @@ static match_table_t policy_tokens = {
 	{Opt_fsuuid, "fsuuid=%s"},
 	{Opt_uid, "uid=%s"},
 	{Opt_fowner, "fowner=%s"},
+	{Opt_gid, "gid=%s"},
+	{Opt_fgroup, "fgroup=%s"},
 	{Opt_appraise_type, "appraise_type=%s"},
 	{Opt_permit_directio, "permit_directio"},
 	{Opt_err, NULL}
@@ -442,6 +455,8 @@ static int ima_parse_rule(char *rule, struct ima_rule_entry *entry)
 
 	entry->uid = INVALID_UID;
 	entry->fowner = INVALID_UID;
+	entry->gid = INVALID_GID;
+	entry->fgroup = INVALID_GID;
 	entry->action = UNKNOWN;
 	while ((p = strsep(&rule, " \t")) != NULL) {
 		substring_t args[MAX_OPT_ARGS];
@@ -598,6 +613,40 @@ static int ima_parse_rule(char *rule, struct ima_rule_entry *entry)
 					entry->flags |= IMA_FOWNER;
 			}
 			break;
+		case Opt_gid:
+			ima_log_string(ab, "gid", args[0].from);
+
+			if (gid_valid(entry->gid)) {
+				result = -EINVAL;
+				break;
+			}
+
+			result = kstrtoul(args[0].from, 10, &lnum);
+			if (!result) {
+				entry->gid = make_kgid(current_user_ns(), (gid_t)lnum);
+				if (!gid_valid(entry->gid) || (((gid_t)lnum) != lnum))
+					result = -EINVAL;
+				else
+					entry->flags |= IMA_GID;
+			}
+			break;
+		case Opt_fgroup:
+			ima_log_string(ab, "fgroup", args[0].from);
+
+			if (gid_valid(entry->fgroup)) {
+				result = -EINVAL;
+				break;
+			}
+
+			result = kstrtoul(args[0].from, 10, &lnum);
+			if (!result) {
+				entry->fgroup = make_kgid(current_user_ns(), (gid_t)lnum);
+				if (!gid_valid(entry->fgroup) || (((gid_t)lnum) != lnum))
+					result = -EINVAL;
+				else
+					entry->flags |= IMA_FGROUP;
+			}
+			break;
 		case Opt_obj_user:
 			ima_log_string(ab, "obj_user", args[0].from);
 			result = ima_lsm_rule_init(entry, args,

Re: [Linux-ima-user] Problem in determining IMA is already enable or not

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

On Fri, 2015-06-05 at 22:47 +0800, r0uruni Zzzz wrote:
> Hi,
> Im new in this area and using the Fedora 22. I try to determine whether the
> IMA has been enable or not by inputting "*sudo* *mount -t securityfs
> security /sys/kernel/security*" . However, the output is "*mount: already
> mount or /sys/kernel/security is busy*" . Does this mean that IMA is
> already supported ?

In general, to check whether or not a system has IMA enabled, once
<securityfs> is mounted, check to see if any IMA files exist
<securityfs>/ima (eg. binary_runtime_measurements,
ascii_runtime_measurements, policy, etc).

The linux-integrity (eg. IMA) is enabled on RHEL, but not Fedora.

Mimi

[Linux-ima-user] Problem in determining IMA is already enable or not

[r0uruni Z. <r0u...@gm...>]

Hi,
Im new in this area and using the Fedora 22. I try to determine whether the
IMA has been enable or not by inputting "*sudo* *mount -t securityfs
security /sys/kernel/security*" . However, the output is "*mount: already
mount or /sys/kernel/security is busy*" . Does this mean that IMA is
already supported ?

Thank you.

Re: [Linux-ima-user] [RFC] IMA Root certificate hierarchy keyring

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

On Mon, 2015-05-18 at 15:42 +0300, Petko Manolov wrote:
> On 15-05-14 18:01:35, Mimi Zohar wrote:
> > On Thu, 2015-05-14 at 15:05 +0300, Petko Manolov wrote:
> > > 
> > > What do you mean by "brokenness"?
> > 
> > The CA trust model is broken.  Lets say A trusts B, and B trusts C, and
> > C trusts  X, Y, & Z.  That means that A not only trusts B, but also C
> > and everything that C trusts (X, Y, & Z).   There are a number of
> > articles about the problem.  Here's a recent example
> > https://www.schneier.com/blog/archives/2015/03/chinese_ca_issu.html.
> 
> Oh, this has always been broken.  The environment we're going to deploy the 
> system in is much more restricted.  It will seldom have more than a couple of 
> certificates, but we'd like to have some sort of hierarchy just in case.
> 
> The end users of this system are supposed to be well educated in terms of 
> cryptography technologies and security protocols.

Ok

> Patch number 4 (the one that introduces owner_keyring) does not seem to be 
> mainlined as of v4.0.4.

Up to now, "ca_keys" provided the necessary functionality without the
need for an additional keyring.  The use case scenario you described
seems to require an additional keyring.   As long as this new keyring is
not enabled by default, I don't have a problem with it.  The term
"root_ca" has too many connotations associated with it.  Instead of
calling the new keyring 'ima_root_ca_keyring' or 'owner_kerying',
consider using '.trusted_ca_keyring'  or '.ima_trusted_ca_keyring'. 

> As root i was able to revoke just about any keyring except for the 
> .system_keyring.  I guess this is due to KEY_USR_WRITE.  Maybe a special check 
> must be performed so trusted keyrings can't be revoked and/or removed.

Like the .system_keyring, userspace shouldn't be able to remove the .ima
keyring either.   Please ensure the new keyring can not be removed by
userspace either.

thanks,

Mimi

Re: [Linux-ima-user] [RFC] IMA Root certificate hierarchy keyring

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

On 15-05-14 18:01:35, Mimi Zohar wrote:
> On Thu, 2015-05-14 at 15:05 +0300, Petko Manolov wrote:
> > 
> > What do you mean by "brokenness"?
> 
> The CA trust model is broken.  Lets say A trusts B, and B trusts C, and
> C trusts  X, Y, & Z.  That means that A not only trusts B, but also C
> and everything that C trusts (X, Y, & Z).   There are a number of
> articles about the problem.  Here's a recent example
> https://www.schneier.com/blog/archives/2015/03/chinese_ca_issu.html.

Oh, this has always been broken.  The environment we're going to deploy the 
system in is much more restricted.  It will seldom have more than a couple of 
certificates, but we'd like to have some sort of hierarchy just in case.

The end users of this system are supposed to be well educated in terms of 
cryptography technologies and security protocols.

> > Having just one key in .system_keyring is essentially like initializing ca_keys 
> > with a specific id, right?
> 
> If you've built your own kernel, the builtin key used to sign kernel
> modules could probably be used to sign other keys being loaded onto the
> IMA keyring.  In that scenario, then yes it would be the same thing.

OK.

> > The problem is that the system and owner trusted keyrings are both read-only, 
> > IOW it is impossible to load new certificates into them.  
> 
> I was definitely able to load keys onto the owner keyring, when the
> patches were posted.  Perhaps something has changed.  I'll have to take
> a look.   At the time, one of the problems was userspace could delete
> keyrings.  Check and see if you can delete the keyring from userspace.

Patch number 4 (the one that introduces owner_keyring) does not seem to be 
mainlined as of v4.0.4.

As a root i was able to revoke just about any keyring except for the 
.system_keyring.  I guess this is due to KEY_USR_WRITE.  Maybe a special check 
must be performed so trusted keyrings can't be revoked and/or removed.

> > These 'owner' certificates are used to further authenticate the IMA keys that go 
> > to .ima and nothing else.  Here is an example: company A is the system 
> > manufacturer (only A's cert is in the system trusted keyring), company B is the 
> > user.  B wants to be able to sign and run their own binaries on the said system. 
> > There are two options - send the stuff to A for signing and wait to get it back 
> > or ask A to sign B's certificate, which B will use to sign their objects 
> > locally.
> 
> The other option would be to sign company B's certificate with the private key 
> of the mini CA key stored in the MoK db.

Yep, either this or something similar is the most likely scenario.

> > Having their own trusted certificate allows B to do everything they need in a 
> > timely manner without going back and forth to A.  Things are getting even more 
> > complex if there is another simultaneous user of the same machine - company C.
> 
> They both can't own the system, can they?  Or does company B own the
> system, while company C is a tenant?

The latter, if there ever is company C.  We need to support this case if it ever 
comes to that.

> > The way i see it we have no other choice.  Please correct me if i am wrong.
> 
> If company C has root privileges, it can load its own key in the MoK db.
> Otherwise company B could load it for company C.  In that case, we could
> extend ca_keys to identify multiple keys. 

I am under the impression that MoK db is read-only and the keys are harvested 
from the corresponding UEFI variable(s) at boot, just like those in the kernel 
root directory at build time?


		Petko

Re: [Linux-ima-user] [RFC] IMA Root certificate hierarchy keyring

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

On Thu, 2015-05-14 at 15:05 +0300, Petko Manolov wrote:
> On 15-05-13 13:52:34, Mimi Zohar wrote:
> > 
> > Versions 3 - 5 had two keyrings.  Refer to the fourth patch "KEYS:
> > define an owner trusted keyring" in the patchset.
> > http://marc.info/?l=linux-security-module&m=140181833100961&w=2
> 
> Thanks.

> > This intermediary keyring that you're introducing unfortunately perpetuates 
> > the x509 certificate chain brokenness, by introducing a level of transitive 
> > trust in IMA. The existing "ca_keys=id:xxxxxx" boot command line parameter 
> > intentionally limits the root CA to a specific key, preferably created by the 
> > machine owner.  Only this key will then be used to verify third party 
> > certificates.
> 
> What do you mean by "brokenness"?

The CA trust model is broken.  Lets say A trusts B, and B trusts C, and
C trusts  X, Y, & Z.  That means that A not only trusts B, but also C
and everything that C trusts (X, Y, & Z).   There are a number of
articles about the problem.  Here's a recent example
https://www.schneier.com/blog/archives/2015/03/chinese_ca_issu.html.

> Having just one key in .system_keyring is essentially like initializing ca_keys 
> with a specific id, right?

If you've built your own kernel, the builtin key used to sign kernel
modules could probably be used to sign other keys being loaded onto the
IMA keyring.  In that scenario, then yes it would be the same thing.

> The problem is that the system and owner trusted keyrings are both read-only, 
> IOW it is impossible to load new certificates into them.  

I was definitely able to load keys onto the owner keyring, when the
patches were posted.  Perhaps something has changed.  I'll have to take
a look.   At the time, one of the problems was userspace could delete
keyrings.  Check and see if you can delete the keyring from userspace.

> We need to be able to 
> import new certificates without restarting the machine to boot new kernel or 
> read UEFI variables.

By creating a local mini-CA and installing it's key on the system
keyring (eg. the MoK db), the system owner controls which software is
allowed to run on the system by controlling which keys are signed and
loaded onto the IMA keyring.  With the local mini-ca key, the system
owner can sign new certificates and load them on the IMA keyring.

> These 'owner' certificates are used to further authenticate the IMA keys that go 
> to .ima and nothing else.  Here is an example: company A is the system 
> manufacturer (only A's cert is in the system trusted keyring), company B is the 
> user.  B wants to be able to sign and run their own binaries on the said system. 
> There are two options - send the stuff to A for signing and wait to get it back 
> or ask A to sign B's certificate, which B will use to sign their objects 
> locally.

The other option would be to sign company B's certificate with the
private key of the mini CA key stored in the MoK db.

> Having their own trusted certificate allows B to do everything they need in a 
> timely manner without going back and forth to A.  Things are getting even more 
> complex if there is another simultaneous user of the same machine - company C.

They both can't own the system, can they?  Or does company B own the
system, while company C is a tenant?
  
> The way i see it we have no other choice.  Please correct me if i am wrong.

If company C has root privileges, it can load its own key in the MoK db.
Otherwise company B could load it for company C.  In that case, we could
extend ca_keys to identify multiple keys. 

> > Right, the original patches referred to this keyring as owner trusted, not 
> > root_ca trusted.
> 
> Giving proper names is not my strong side. :)

Me either.

Mimi

Re: [Linux-ima-user] [RFC] IMA Root certificate hierarchy keyring

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

On 15-05-13 13:52:34, Mimi Zohar wrote:
> 
> Versions 3 - 5 had two keyrings.  Refer to the fourth patch "KEYS:
> define an owner trusted keyring" in the patchset.
> http://marc.info/?l=linux-security-module&m=140181833100961&w=2

Thanks.

> This intermediary keyring that you're introducing unfortunately perpetuates 
> the x509 certificate chain brokenness, by introducing a level of transitive 
> trust in IMA. The existing "ca_keys=id:xxxxxx" boot command line parameter 
> intentionally limits the root CA to a specific key, preferably created by the 
> machine owner.  Only this key will then be used to verify third party 
> certificates.

What do you mean by "brokenness"?

Having just one key in .system_keyring is essentially like initializing ca_keys 
with a specific id, right?

The problem is that the system and owner trusted keyrings are both read-only, 
IOW it is impossible to load new certificates into them.  We need to be able to 
import new certificates without restarting the machine to boot new kernel or 
read UEFI variables.

These 'owner' certificates are used to further authenticate the IMA keys that go 
to .ima and nothing else.  Here is an example: company A is the system 
manufacturer (only A's cert is in the system trusted keyring), company B is the 
user.  B wants to be able to sign and run their own binaries on the said system.  
There are two options - send the stuff to A for signing and wait to get it back 
or ask A to sign B's certificate, which B will use to sign their objects 
locally.

Having their own trusted certificate allows B to do everything they need in a 
timely manner without going back and forth to A.  Things are getting even more 
complex if there is another simultaneous user of the same machine - company C.  
The way i see it we have no other choice.  Please correct me if i am wrong.

> Right, the original patches referred to this keyring as owner trusted, not 
> root_ca trusted.

Giving proper names is not my strong side. :)


		Petko

Re: [Linux-ima-user] [RFC] IMA Root certificate hierarchy keyring

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

On Wed, 2015-05-13 at 10:45 +0300, Petko Manolov wrote:
> On 15-05-12 14:55:35, Mimi Zohar wrote:
> >
> > The original trusted keys patch set defined two separate keyrings.  One for 
> > the keys used for verifying the IMA certificate and another for the IMA keys 
> > themselves.  Until a use case was defined, only the trusted IMA keyring was 
> > upstreamed.  The "ca_keys=" boot command line option was defined to limit the 
> > system keyring to either the builtin keys or a specific key.
> 
> I'm relatively new to the game so please send a pointer to the original patch.

Versions 3 - 5 had two keyrings.  Refer to the fourth patch "KEYS:
define an owner trusted keyring" in the patchset.
http://marc.info/?l=linux-security-module&m=140181833100961&w=2

> > Keys can be added to the IMA keyring without rebooting the system.  Why the 
> > need for the additional keyring?
> 
> The system we're building has a bunch of requirements in terms of security - use 
> signed keys only, all immutable files must be signed, certificates have lifespan 
> of one year, etc.
> 
> On the other side third parties should be able to easily run their own software 
> without rebooting the machine to introduce their own certificates.  Uptime is 
> extremely important in this case.
> 
> Since .system_keyring is hardcoded and read-only it is impossible to import new 
> certificates.  Adding intermediate keyring (which is read-write) to keep these 
> third party, short-lived certificates nicely solves the above requirements.
> 
> The architecture typically look like this:
> 
> 
> Root_CA (.system_keyring) ---> Cert_A (.ima_root_ca) ---> Key_A (.ima)
>                            |
>                            +-> Cert_B (.ima_root_ca) ---> Key_B (.ima)
>                            |
>                            |-> Cert_C (.ima_root_ca) ---> Key_C (.ima)
> 
> Root_CA has long life-span and its replacement requires new kernel/initramfs.  
> These events should be very rare.  Cert_[A..C] must be signed by Root_CA's 
> private key, but are expendable.  If Key_[A..C] private key get compromised or 
> expire it may be revoked and replaced with another one without system reboot.
> 
> Intermediate certificates gives third parties flexibility to build their own 
> hierarchy without bothering to go to the vendor to sign every bugfix.

This intermediary keyring that you're introducing unfortunately
perpetuates the x509 certificate chain brokenness, by introducing a
level of transitive trust in IMA. The existing "ca_keys=id:xxxxxx" boot
command line parameter intentionally limits the root CA to a specific
key, preferably created by the machine owner.  Only this key will then
be used to verify third party certificates.

> I admit the name .ima_root_ca_keyring is technically incorrect as it is in the 
> search path to all users of trusted system keyring.  However, creating 
> IMA-specific intermediate keyring will require changing a lot more code than i 
> feel comfortable with.  As it is impossible for unsigned certificate to land on 
> .ima_root_ca_keyring i think this is not a security issue.

Right, the original patches referred to this keyring as owner trusted,
not root_ca trusted.

Mimi

[Linux-ima-user] [PATCH 2/2] ima: extend "mask" policy matching support

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

The current "mask" policy option matches files opened as MAY_READ,
MAY_WRITE, MAY_APPEND or MAY_EXEC.  This patch extends the "mask"
option to match files opened containing one of these modes.  For
example, "mask=^MAY_READ" would match files opened read-write.

Signed-off-by: Mimi Zohar <zo...@li...>
---
 Documentation/ABI/testing/ima_policy |  3 ++-
 security/integrity/ima/ima_policy.c  | 20 +++++++++++++++-----
 2 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy
index 4a571fa..0a378a8 100644
--- a/Documentation/ABI/testing/ima_policy
+++ b/Documentation/ABI/testing/ima_policy
@@ -27,7 +27,8 @@ Description:
 
 		base: 	func:= [BPRM_CHECK][MMAP_CHECK][FILE_CHECK][MODULE_CHECK]
 				[FIRMWARE_CHECK]
-			mask:= [MAY_READ] [MAY_WRITE] [MAY_APPEND] [MAY_EXEC]
+			mask:= [[^]MAY_READ] [[^]MAY_WRITE] [[^]MAY_APPEND]
+			       [[^]MAY_EXEC]
 			fsmagic:= hex value
 			fsuuid:= file system UUID (e.g 8bcbe394-4f13-4144-be8e-5aa9ea2ce2f6)
 			uid:= decimal value
diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
index fcefa5c..162789e 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -27,6 +27,7 @@
 #define IMA_UID		0x0008
 #define IMA_FOWNER	0x0010
 #define IMA_FSUUID	0x0020
+#define IMA_INMASK	0x0040
 #define IMA_EUID	0x0080
 
 #define UNKNOWN		0
@@ -186,6 +187,9 @@ static bool ima_match_rules(struct ima_rule_entry *rule,
 	if ((rule->flags & IMA_MASK) &&
 	    (rule->mask != mask && func != POST_SETATTR))
 		return false;
+	if ((rule->flags & IMA_INMASK) &&
+	    (!(rule->mask & mask) && func != POST_SETATTR))
+		return false;
 	if ((rule->flags & IMA_FSMAGIC)
 	    && rule->fsmagic != inode->i_sb->s_magic)
 		return false;
@@ -447,6 +451,7 @@ static void ima_log_string(struct audit_buffer *ab, char *key, char *value)
 static int ima_parse_rule(char *rule, struct ima_rule_entry *entry)
 {
 	struct audit_buffer *ab;
+	char *from;
 	char *p;
 	int result = 0;
 
@@ -537,18 +542,23 @@ static int ima_parse_rule(char *rule, struct ima_rule_entry *entry)
 			if (entry->mask)
 				result = -EINVAL;
 
-			if ((strcmp(args[0].from, "MAY_EXEC")) == 0)
+			from = args[0].from;
+			if (*from == '^')
+				from++;
+
+			if ((strcmp(from, "MAY_EXEC")) == 0)
 				entry->mask = MAY_EXEC;
-			else if (strcmp(args[0].from, "MAY_WRITE") == 0)
+			else if (strcmp(from, "MAY_WRITE") == 0)
 				entry->mask = MAY_WRITE;
-			else if (strcmp(args[0].from, "MAY_READ") == 0)
+			else if (strcmp(from, "MAY_READ") == 0)
 				entry->mask = MAY_READ;
-			else if (strcmp(args[0].from, "MAY_APPEND") == 0)
+			else if (strcmp(from, "MAY_APPEND") == 0)
 				entry->mask = MAY_APPEND;
 			else
 				result = -EINVAL;
 			if (!result)
-				entry->flags |= IMA_MASK;
+				entry->flags |= (*args[0].from == '^')
+				     ? IMA_INMASK : IMA_MASK;
 			break;
 		case Opt_fsmagic:
 			ima_log_string(ab, "fsmagic", args[0].from);
-- 
2.1.0

[Linux-ima-user] [PATCH 1/2] ima: add support for new "euid" policy condition

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

The new "euid" policy condition measures files with the specified
effective uid (euid).  In addition, for CAP_SETUID files it measures
files with the specified uid or suid.

Signed-off-by: Mimi Zohar <zo...@li...>
---
 Documentation/ABI/testing/ima_policy |  3 ++-
 security/integrity/ima/ima_policy.c  | 21 +++++++++++++++++++--
 2 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy
index 8ae3f57..4a571fa 100644
--- a/Documentation/ABI/testing/ima_policy
+++ b/Documentation/ABI/testing/ima_policy
@@ -20,7 +20,7 @@ Description:
 		action: measure | dont_measure | appraise | dont_appraise | audit
 		condition:= base | lsm  [option]
 			base:	[[func=] [mask=] [fsmagic=] [fsuuid=] [uid=]
-				 [fowner]]
+				[euid=] [fowner=]]
 			lsm:	[[subj_user=] [subj_role=] [subj_type=]
 				 [obj_user=] [obj_role=] [obj_type=]]
 			option:	[[appraise_type=]] [permit_directio]
@@ -31,6 +31,7 @@ Description:
 			fsmagic:= hex value
 			fsuuid:= file system UUID (e.g 8bcbe394-4f13-4144-be8e-5aa9ea2ce2f6)
 			uid:= decimal value
+			euid:= decimal value
 			fowner:=decimal value
 		lsm:  	are LSM specific
 		option:	appraise_type:= [imasig]
diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
index b4f9021..fcefa5c 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -27,6 +27,7 @@
 #define IMA_UID		0x0008
 #define IMA_FOWNER	0x0010
 #define IMA_FSUUID	0x0020
+#define IMA_EUID	0x0080
 
 #define UNKNOWN		0
 #define MEASURE		0x0001	/* same as IMA_MEASURE */
@@ -193,6 +194,16 @@ static bool ima_match_rules(struct ima_rule_entry *rule,
 		return false;
 	if ((rule->flags & IMA_UID) && !uid_eq(rule->uid, cred->uid))
 		return false;
+	if (rule->flags & IMA_EUID) {
+		if (capable(CAP_SETUID)) {
+			if (!uid_eq(rule->uid, cred->euid)
+			    && !uid_eq(rule->uid, cred->suid)
+			    && !uid_eq(rule->uid, cred->uid))
+			return false;
+		} else if (!uid_eq(rule->uid, cred->euid))
+			return false;
+	}
+
 	if ((rule->flags & IMA_FOWNER) && !uid_eq(rule->fowner, inode->i_uid))
 		return false;
 	for (i = 0; i < MAX_LSM_RULES; i++) {
@@ -372,7 +383,8 @@ enum {
 	Opt_audit,
 	Opt_obj_user, Opt_obj_role, Opt_obj_type,
 	Opt_subj_user, Opt_subj_role, Opt_subj_type,
-	Opt_func, Opt_mask, Opt_fsmagic, Opt_uid, Opt_fowner,
+	Opt_func, Opt_mask, Opt_fsmagic,
+	Opt_uid, Opt_euid, Opt_fowner,
 	Opt_appraise_type, Opt_fsuuid, Opt_permit_directio
 };
 
@@ -393,6 +405,7 @@ static match_table_t policy_tokens = {
 	{Opt_fsmagic, "fsmagic=%s"},
 	{Opt_fsuuid, "fsuuid=%s"},
 	{Opt_uid, "uid=%s"},
+	{Opt_euid, "euid=%s"},
 	{Opt_fowner, "fowner=%s"},
 	{Opt_appraise_type, "appraise_type=%s"},
 	{Opt_permit_directio, "permit_directio"},
@@ -565,6 +578,9 @@ static int ima_parse_rule(char *rule, struct ima_rule_entry *entry)
 			break;
 		case Opt_uid:
 			ima_log_string(ab, "uid", args[0].from);
+		case Opt_euid:
+			if (token == Opt_euid)
+				ima_log_string(ab, "euid", args[0].from);
 
 			if (uid_valid(entry->uid)) {
 				result = -EINVAL;
@@ -577,7 +593,8 @@ static int ima_parse_rule(char *rule, struct ima_rule_entry *entry)
 				if (!uid_valid(entry->uid) || (((uid_t)lnum) != lnum))
 					result = -EINVAL;
 				else
-					entry->flags |= IMA_UID;
+					entry->flags |= (token == Opt_uid)
+					    ? IMA_UID : IMA_EUID;
 			}
 			break;
 		case Opt_fowner:
-- 
2.1.0

Re: [Linux-ima-user] [RFC] IMA Root certificate hierarchy keyring

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

On 15-05-12 14:55:35, Mimi Zohar wrote:
>
> The original trusted keys patch set defined two separate keyrings.  One for 
> the keys used for verifying the IMA certificate and another for the IMA keys 
> themselves.  Until a use case was defined, only the trusted IMA keyring was 
> upstreamed.  The "ca_keys=" boot command line option was defined to limit the 
> system keyring to either the builtin keys or a specific key.

I'm relatively new to the game so please send a pointer to the original patch.

> Keys can be added to the IMA keyring without rebooting the system.  Why the 
> need for the additional keyring?

The system we're building has a bunch of requirements in terms of security - use 
signed keys only, all immutable files must be signed, certificates have lifespan 
of one year, etc.

On the other side third parties should be able to easily run their own software 
without rebooting the machine to introduce their own certificates.  Uptime is 
extremely important in this case.

Since .system_keyring is hardcoded and read-only it is impossible to import new 
certificates.  Adding intermediate keyring (which is read-write) to keep these 
third party, short-lived certificates nicely solves the above requirements.

The architecture typically look like this:


Root_CA (.system_keyring) ---> Cert_A (.ima_root_ca) ---> Key_A (.ima)
                           |
                           +-> Cert_B (.ima_root_ca) ---> Key_B (.ima)
                           |
                           |-> Cert_C (.ima_root_ca) ---> Key_C (.ima)

Root_CA has long life-span and its replacement requires new kernel/initramfs.  
These events should be very rare.  Cert_[A..C] must be signed by Root_CA's 
private key, but are expendable.  If Key_[A..C] private key get compromised or 
expire it may be revoked and replaced with another one without system reboot.

Intermediate certificates gives third parties flexibility to build their own 
hierarchy without bothering to go to the vendor to sign every bugfix.

I admit the name .ima_root_ca_keyring is technically incorrect as it is in the 
search path to all users of trusted system keyring.  However, creating 
IMA-specific intermediate keyring will require changing a lot more code than i 
feel comfortable with.  As it is impossible for unsigned certificate to land on 
.ima_root_ca_keyring i think this is not a security issue.


cheers,
Petko

Re: [Linux-ima-user] [RFC] IMA Root certificate hierarchy keyring

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

On Tue, 2015-05-12 at 19:36 +0300, Petko Manolov wrote:
> On 15-05-12 19:00:58, Petko Manolov wrote:
> > 	Hi guys,
> > 
> > Please excuse the monolithic patch - it is small and meant for RFC only.

The size is fine.

> > The project i am currently working on requires dynamic add/revoke of both IMA 
> > keys and their respective signing certificates.  This requirement pivots around 
> > two things: machine uptime and achieving some sort of CA hierarchy.
> > 
> > The name is misleading but shows its primary use: .ima_root_ca_keyring - it is 
> > in fact system-wide keyring storing intermediate CA public keys, which are used 
> > to verify the actual IMA key's signature.
  
The original trusted keys patch set defined two separate keyrings.  One
for the keys used for verifying the IMA certificate and another for the
IMA keys themselves.  Until a use case was defined, only the trusted IMA
keyring was upstreamed.  The "ca_keys=" boot command line option was
defined to limit the system keyring to either the builtin keys or a
specific key.

> > .ima_root_ca_keyring allows the root user to dynamically add new certificate and 
> > signed IMA key to the system, mount new FS with properly signed objects and 
> > read/execute files off it without going through reboot cycle.  It also gives us 
> > the ability to import IMA keys signed by different entities/certificates, all 
> > having their root at a certificate in .system_keyring.

Keys can be added to the IMA keyring without rebooting the system.  Why
the need for the additional keyring?

Mimi

> > The patch is tested and, as far as i can tell, does what it was designed for.  
> > Any comment would be greatly appreciated.
> > 
> > 
> > thanks,
> > Petko
> 
> Posting the patch again as a non-attachment.
> 
> 
> 		Petko
> 
> 
> ---
> 
> diff --git a/crypto/asymmetric_keys/x509_public_key.c b/crypto/asymmetric_keys/x509_public_key.c
> index a6c4203..83a0425 100644
> --- a/crypto/asymmetric_keys/x509_public_key.c
> +++ b/crypto/asymmetric_keys/x509_public_key.c
> @@ -281,6 +281,8 @@ static int x509_key_preparse(struct key_preparsed_payload *prep)
>  			goto error_free_cert;
>  	} else if (!prep->trusted) {
>  		ret = x509_validate_trust(cert, get_system_trusted_keyring());
> +		if (ret)
> +			ret = x509_validate_trust(cert, get_ima_root_ca_keyring());
>  		if (!ret)
>  			prep->trusted = 1;
>  	}
> diff --git a/include/keys/system_keyring.h b/include/keys/system_keyring.h
> index 72665eb..7a632e1 100644
> --- a/include/keys/system_keyring.h
> +++ b/include/keys/system_keyring.h
> @@ -28,4 +28,17 @@ static inline struct key *get_system_trusted_keyring(void)
>  }
>  #endif
> 
> +#ifdef CONFIG_IMA_ROOT_CA_KEYRING
> +extern struct key *ima_root_ca_keyring;
> +static inline struct key *get_ima_root_ca_keyring(void)
> +{
> +	return ima_root_ca_keyring;
> +}
> +#else
> +static inline struct key *get_ima_root_ca_keyring(void)
> +{
> +	return NULL;
> +}
> +#endif /* CONFIG_IMA_ROOT_CA_KEYRING */
> +
>  #endif /* _KEYS_SYSTEM_KEYRING_H */
> diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
> index df30334..f859451 100644
> --- a/security/integrity/ima/Kconfig
> +++ b/security/integrity/ima/Kconfig
> @@ -131,6 +131,15 @@ config IMA_TRUSTED_KEYRING
>  	   This option requires that all keys added to the .ima
>  	   keyring be signed by a key on the system trusted keyring.
> 
> +config IMA_ROOT_CA_KEYRING
> +	bool "Create IMA Root CA keyring"
> +	depends on IMA_TRUSTED_KEYRING
> +	default y
> +	help
> +	   This option creates IMA Root CA keyring.  All keys in it must be
> +	   signed either by a key in the .system keyring or one which is already
> +	   in .ima_root_ca_keyring.
> +
>  config IMA_LOAD_X509
>  	bool "Load X509 certificate onto the '.ima' trusted keyring"
>  	depends on IMA_TRUSTED_KEYRING
> diff --git a/security/integrity/ima/Makefile b/security/integrity/ima/Makefile
> index d79263d..b2f9aa0 100644
> --- a/security/integrity/ima/Makefile
> +++ b/security/integrity/ima/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_IMA) += ima.o
>  ima-y := ima_fs.o ima_queue.o ima_init.o ima_main.o ima_crypto.o ima_api.o \
>  	 ima_policy.o ima_template.o ima_template_lib.o
>  ima-$(CONFIG_IMA_APPRAISE) += ima_appraise.o
> +obj-$(CONFIG_IMA_ROOT_CA_KEYRING) += ima_root_ca.o
> diff --git a/security/integrity/ima/ima_root_ca.c b/security/integrity/ima/ima_root_ca.c
> new file mode 100644
> index 0000000..95d2526
> --- /dev/null
> +++ b/security/integrity/ima/ima_root_ca.c
> @@ -0,0 +1,41 @@
> +/*
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation, version 2 of the
> + * License.
> + *
> + */
> +
> +#include <linux/export.h>
> +#include <linux/kernel.h>
> +#include <linux/sched.h>
> +#include <linux/cred.h>
> +#include <linux/err.h>
> +#include <linux/module.h>
> +#include <keys/asymmetric-type.h>
> +
> +MODULE_LICENSE("GPL");
> +
> +struct key *ima_root_ca_keyring = NULL;
> +EXPORT_SYMBOL_GPL(ima_root_ca_keyring);
> +
> +/*
> + * Allocate the IMA Root CA keyring
> + */
> +__init int ima_root_ca_init(void)
> +{
> +	pr_notice("Initialise IMA Root CA keyring.\n");
> +
> +	ima_root_ca_keyring = keyring_alloc(".ima_root_ca",
> +			      KUIDT_INIT(0), KGIDT_INIT(0), current_cred(),
> +			      (KEY_POS_ALL & ~KEY_POS_SETATTR) |
> +			      KEY_USR_VIEW | KEY_USR_READ |
> +			      KEY_USR_WRITE | KEY_USR_SEARCH,
> +			      KEY_ALLOC_NOT_IN_QUOTA, NULL);
> +	if (IS_ERR(ima_root_ca_keyring))
> +		panic("Can't allocate IMA Root CA keyring.");
> +	set_bit(KEY_FLAG_TRUSTED_ONLY, &ima_root_ca_keyring->flags);
> +	return 0;
> +}
> +
> +module_init(ima_root_ca_init);
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to maj...@vg...
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [Linux-ima-user] [patch] ima: cleanup ima_init_policy() a little

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

On Tue, 2015-04-07 at 12:22 +0300, Dan Carpenter wrote: 
> It's a bit easier to read this if we split it up into two for loops.

Agreed

> Signed-off-by: Dan Carpenter <dan...@or...>
Signed-off-by: Mimi Zohar <zo...@li...> 

Mimi

> diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
> index d1eefb9..e86b58d 100644
> --- a/security/integrity/ima/ima_policy.c
> +++ b/security/integrity/ima/ima_policy.c
> @@ -338,16 +338,12 @@ void __init ima_init_policy(void)
>  	appraise_entries = ima_use_appraise_tcb ?
>  			 ARRAY_SIZE(default_appraise_rules) : 0;
> 
> -	for (i = 0; i < measure_entries + appraise_entries; i++) {
> -		if (i < measure_entries)
> -			list_add_tail(&default_rules[i].list,
> -				      &ima_default_rules);
> -		else {
> -			int j = i - measure_entries;
> -
> -			list_add_tail(&default_appraise_rules[j].list,
> -				      &ima_default_rules);
> -		}
> +	for (i = 0; i < measure_entries; i++)
> +		list_add_tail(&default_rules[i].list, &ima_default_rules);
> +
> +	for (i = 0; i < appraise_entries; i++) {
> +		list_add_tail(&default_appraise_rules[i].list,
> +			      &ima_default_rules);
>  	}
> 
>  	ima_rules = &ima_default_rules;