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

Re: [Linux-ima-user] How to load a key to trusted IMA keyring?

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

On Thu, 2016-11-10 at 08:33 +0000, Kiviluoto, Jaakko J wrote:
> Hi all,
> 
> What is the correct way to get a key loaded into the trusted ".ima"
> keyring?
> 
> If I try the CONFIG_IMA_LOAD_X509 way, this change removes the
> "KEY_ALLOC_TRUSTED" attribute required by a trusted keyring:
> https://sourceforge.net/p/linux-ima/mailman/message/34449223/
> 
> Similar roadblock when trying to insert the key with 'keyctl padd
> asymmetric "" 0x12345678 < /etc/keys/x509_ima.der' but that is
> expected.
> 
> Built-in keys from CONFIG_SYSTEM_TRUSTED_KEYS only go to system
> keyring, but I'd need to put one to ".ima"
> 
> Loading the key to untrusted "_ima" keyring seems to work fine, but
> then you can't use CONFIG_IMA_APPRAISE_SIGNED_INIT.
> 
> I'm using Linux kernel 4.4 with Yocto Krogoth branch.

The key being loaded onto the .ima keyring needs to be signed by a key
on the .buitlin_trusted_keys keyring.  On older kernels, the key needed
to be signed by a key on the system keyring.

The README in the ima-evm-util package has a good explanation, with
examples.

Mimi

[Linux-ima-user] How to load a key to trusted IMA keyring?

[Kiviluoto, J. J <jaa...@in...>]

Hi all,

What is the correct way to get a key loaded into the trusted ".ima" keyring?

If I try the CONFIG_IMA_LOAD_X509 way, this change removes the "KEY_ALLOC_TRUSTED" attribute required by a trusted keyring:
https://sourceforge.net/p/linux-ima/mailman/message/34449223/

Similar roadblock when trying to insert the key with 'keyctl padd asymmetric "" 0x12345678 < /etc/keys/x509_ima.der' but that is expected.

Built-in keys from CONFIG_SYSTEM_TRUSTED_KEYS only go to system keyring, but I'd need to put one to ".ima"

Loading the key to untrusted "_ima" keyring seems to work fine, but then you can't use CONFIG_IMA_APPRAISE_SIGNED_INIT.

I'm using Linux kernel 4.4 with Yocto Krogoth branch.

Many thanks,
Jaakko
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [Linux-ima-user] copying files with security.ima xattr

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

On Wed, 2016-11-02 at 09:47 -0400, Mimi Zohar wrote:
> In order to revert the patch, we need to explain the reason for doing
> so.   Could you expand/update the two reasons given below?
> 
> - Applications have been modified to write security xattrs, but they are
> not necessarily context aware.  In the case of security.ima, the
> security xattr can be either a file hash or a file signature.
> Permitting writing one, but not the other requires the application to be
> context aware.
> 
> - Applications write files to a staging area, which might not be in
> policy, and then change some file metadata (eg owner) making it in
> policy.  As a result, these files are not labeled properly.

That describes it well.

-- 
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] copying files with security.ima xattr

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

Hi Patrick, Dmitry,

Sorry for the long delay in getting back to you ...

On Tue, 2016-10-11 at 16:15 +0300, Dmitry Kasatkin wrote:
> Hi,

> On Tue, Oct 11, 2016 at 3:24 PM, Patrick Ohly <pat...@in...> wrote:
> > On Mon, 2016-07-18 at 14:21 +0200, Patrick Ohly wrote:
> >> On Mon, 2016-07-18 at 08:08 -0400, Mimi Zohar wrote:
> >> > Commit c68ed80 "ima: limit file hash setting by user to fix and log
> >> > modes" is a form of system hardening.  Before reverting it, let's see if
> >> > there is another option.
> >> >
> >> > Could we summarize the problem as:
> >> > - the kernel prevents writing security.ima hashes.
> >> > - the kernel only writes security.ima hashes for files that are in
> >> > policy.
> >> > - the userspace tool doesn't know what is in/out of policy.
> >> > - the userspace tool doesn't differentiate between hashes and
> >> > signatures.
> >> > - the boot process doesn't permit changing the boot command line options
> >> > (eg. fix mode).
> >> > - the update tool compares file data and metadata with those on the
> >> > server
> >>
> >> Correct.
> >
> > I now ran into the very same problem also in another use case, i.e. not
> > just during system install time.
> >
> > Ostro OS allows file-based updates on a running system. bsdtar is used
> > to extract the new revision of each modified or new file in a staging
> > directory. In our policy, some files are merely hashed and not signed,
> > because they might be modified on the device.
> >
> > Extracting such files with bsdtar also fails with:
> > fsetxattr(4, "security.ima", "\1\217'\taw\210\3\245MrT\351n\336j\316\7z
> > \212j", 21, 0) = -1 EPERM (Operation not permitted)
> >
> > Given that this particular kernel check is now causing problems in two
> > cases, can we revisit the question whether it can be reverted?

In order to revert the patch, we need to explain the reason for doing
so.   Could you expand/update the two reasons given below?

- Applications have been modified to write security xattrs, but they are
not necessarily context aware.  In the case of security.ima, the
security xattr can be either a file hash or a file signature.
Permitting writing one, but not the other requires the application to be
context aware.

- Applications write files to a staging area, which might not be in
policy, and then change some file metadata (eg owner) making it in
policy.  As a result, these files are not labeled properly.

Thanks,

Mimi

> > There are alternatives to dealing with the problem, but all of them are
> > considerably more work and more complex.
> >
> 
> Yeah. It was security hardening.
> It would be great to have CAP_INTEGRITY_ADMIN or something like that.
> But if it seriously harm then just revert it.

Re: [Linux-ima-user] copying files with security.ima xattr

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

Hi,


On Tue, Oct 11, 2016 at 3:24 PM, Patrick Ohly <pat...@in...> wrote:
> On Mon, 2016-07-18 at 14:21 +0200, Patrick Ohly wrote:
>> On Mon, 2016-07-18 at 08:08 -0400, Mimi Zohar wrote:
>> > Commit c68ed80 "ima: limit file hash setting by user to fix and log
>> > modes" is a form of system hardening.  Before reverting it, let's see if
>> > there is another option.
>> >
>> > Could we summarize the problem as:
>> > - the kernel prevents writing security.ima hashes.
>> > - the kernel only writes security.ima hashes for files that are in
>> > policy.
>> > - the userspace tool doesn't know what is in/out of policy.
>> > - the userspace tool doesn't differentiate between hashes and
>> > signatures.
>> > - the boot process doesn't permit changing the boot command line options
>> > (eg. fix mode).
>> > - the update tool compares file data and metadata with those on the
>> > server
>>
>> Correct.
>
> I now ran into the very same problem also in another use case, i.e. not
> just during system install time.
>
> Ostro OS allows file-based updates on a running system. bsdtar is used
> to extract the new revision of each modified or new file in a staging
> directory. In our policy, some files are merely hashed and not signed,
> because they might be modified on the device.
>
> Extracting such files with bsdtar also fails with:
> fsetxattr(4, "security.ima", "\1\217'\taw\210\3\245MrT\351n\336j\316\7z
> \212j", 21, 0) = -1 EPERM (Operation not permitted)
>
> Given that this particular kernel check is now causing problems in two
> cases, can we revisit the question whether it can be reverted?
>
> There are alternatives to dealing with the problem, but all of them are
> considerably more work and more complex.
>

Yeah. It was security hardening.
It would be great to have CAP_INTEGRITY_ADMIN or something like that.
But if it seriously harm then just revert it.

Dmitry

> --
> 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.
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Linux-ima-user mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-ima-user



-- 
Thanks,
Dmitry

Re: [Linux-ima-user] copying files with security.ima xattr

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

On Mon, 2016-07-18 at 14:21 +0200, Patrick Ohly wrote:
> On Mon, 2016-07-18 at 08:08 -0400, Mimi Zohar wrote:
> > Commit c68ed80 "ima: limit file hash setting by user to fix and log
> > modes" is a form of system hardening.  Before reverting it, let's see if
> > there is another option.
> > 
> > Could we summarize the problem as:
> > - the kernel prevents writing security.ima hashes.
> > - the kernel only writes security.ima hashes for files that are in
> > policy.
> > - the userspace tool doesn't know what is in/out of policy.
> > - the userspace tool doesn't differentiate between hashes and
> > signatures.
> > - the boot process doesn't permit changing the boot command line options
> > (eg. fix mode).
> > - the update tool compares file data and metadata with those on the
> > server
> 
> Correct.

I now ran into the very same problem also in another use case, i.e. not
just during system install time.

Ostro OS allows file-based updates on a running system. bsdtar is used
to extract the new revision of each modified or new file in a staging
directory. In our policy, some files are merely hashed and not signed,
because they might be modified on the device.

Extracting such files with bsdtar also fails with:
fsetxattr(4, "security.ima", "\1\217'\taw\210\3\245MrT\351n\336j\316\7z
\212j", 21, 0) = -1 EPERM (Operation not permitted)

Given that this particular kernel check is now causing problems in two
cases, can we revisit the question whether it can be reverted?

There are alternatives to dealing with the problem, but all of them are
considerably more work and more complex.

-- 
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] [PATCH -next] ima: fix non static symbol warnings

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

On Sun, 2016-09-25 at 15:36 +0000, Wei Yongjun wrote:
> From: Wei Yongjun <wei...@hu...>
> 
> Fixes the following sparse warnings:
> 
> security/integrity/ima/ima_kexec.c:122:23: warning:
>  symbol 'update_buffer_nb' was not declared. Should it be static?
> security/integrity/ima/ima_kexec.c:130:6: warning:
>  symbol 'ima_add_kexec_buffer' was not declared. Should it be static?

Thank you for reporting this sparse error.   With the latest patch set
that I just posted, the ability to carry additional measurements after
the kexec load has been, for at least for the time being, removed.

Mimi

[Linux-ima-user] [PATCH -next] ima: fix non static symbol warnings

[Wei Y. <wei...@gm...>]

From: Wei Yongjun <wei...@hu...>

Fixes the following sparse warnings:

security/integrity/ima/ima_kexec.c:122:23: warning:
 symbol 'update_buffer_nb' was not declared. Should it be static?
security/integrity/ima/ima_kexec.c:130:6: warning:
 symbol 'ima_add_kexec_buffer' was not declared. Should it be static?

Signed-off-by: Wei Yongjun <wei...@hu...>
---
 security/integrity/ima/ima_kexec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/security/integrity/ima/ima_kexec.c b/security/integrity/ima/ima_kexec.c
index 878c062..0a7ab39 100644
--- a/security/integrity/ima/ima_kexec.c
+++ b/security/integrity/ima/ima_kexec.c
@@ -119,7 +119,7 @@ static int ima_update_kexec_buffer(struct notifier_block *self,
 	return NOTIFY_OK;
 }
 
-struct notifier_block update_buffer_nb = {
+static struct notifier_block update_buffer_nb = {
 	.notifier_call = ima_update_kexec_buffer,
 };
 
@@ -127,7 +127,7 @@ struct notifier_block update_buffer_nb = {
  * Called during kexec_file_load so that IMA can add a segment to the kexec
  * image for the measurement list for the next kernel.
  */
-void ima_add_kexec_buffer(struct kimage *image)
+static void ima_add_kexec_buffer(struct kimage *image)
 {
 	static int registered;
 	struct kexec_buf kbuf = { .image = image, .buf_align = PAGE_SIZE,

Re: [Linux-ima-user] [PATCH] ima: fix off-by-one comparison on template name length

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

Hi Colin,

On Tue, 2016-09-20 at 18:25 +0100, Colin King wrote:
> From: Colin Ian King <col...@ca...>
> 
> The comparison of dr_v1->template_name_len is off-by-one, so
> currently if the length is MAX_TEMPLATE_NAME_LEN we end up
> with an out-of-bounds write on template_name when the terminating
> zero character is written. Fix the comparison.
> 
> Signed-off-by: Colin Ian King <col...@ca...>

Thank you for the bug report.  The patch that introduces this bug is in
the -mm tree.  The next posting will include this bug fix.

Thanks!

Mimi

> ---
>  security/integrity/ima/ima_template.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/security/integrity/ima/ima_template.c b/security/integrity/ima/ima_template.c
> index 24775f3..004723c 100644
> --- a/security/integrity/ima/ima_template.c
> +++ b/security/integrity/ima/ima_template.c
> @@ -395,7 +395,7 @@ int ima_restore_measurement_list(loff_t size, void *buf)
>  			hdr_v1->template_name_len =
>  			    le32_to_cpu(hdr_v1->template_name_len);
> 
> -		if ((hdr_v1->template_name_len > MAX_TEMPLATE_NAME_LEN) ||
> +		if ((hdr_v1->template_name_len >= MAX_TEMPLATE_NAME_LEN) ||
>  		    ((bufp + hdr_v1->template_name_len) > bufendp)) {
>  			pr_err("attempting to restore a template name \
>  				that is too long\n");

[Linux-ima-user] [PATCH] ima: fix off-by-one comparison on template name length

[Colin K. <col...@ca...>]

From: Colin Ian King <col...@ca...>

The comparison of dr_v1->template_name_len is off-by-one, so
currently if the length is MAX_TEMPLATE_NAME_LEN we end up
with an out-of-bounds write on template_name when the terminating
zero character is written. Fix the comparison.

Signed-off-by: Colin Ian King <col...@ca...>
---
 security/integrity/ima/ima_template.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security/integrity/ima/ima_template.c b/security/integrity/ima/ima_template.c
index 24775f3..004723c 100644
--- a/security/integrity/ima/ima_template.c
+++ b/security/integrity/ima/ima_template.c
@@ -395,7 +395,7 @@ int ima_restore_measurement_list(loff_t size, void *buf)
 			hdr_v1->template_name_len =
 			    le32_to_cpu(hdr_v1->template_name_len);
 
-		if ((hdr_v1->template_name_len > MAX_TEMPLATE_NAME_LEN) ||
+		if ((hdr_v1->template_name_len >= MAX_TEMPLATE_NAME_LEN) ||
 		    ((bufp + hdr_v1->template_name_len) > bufendp)) {
 			pr_err("attempting to restore a template name \
 				that is too long\n");
-- 
2.9.3

Re: [Linux-ima-user] ima: BUG: spinlock bad magic

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

Hi Dmitry,

On Fri, 2016-09-09 at 21:19 +0200, Dmitry Vyukov wrote:
> Hello,
> 
> While booting linux-next on 4affa544adb8077403893e62b9e327fcf87de6f7
> (Sep 8), I've got the following BUG:
> 
> BUG: spinlock bad magic on CPU#3, swapper/0/1
>  lock: template_list+0x0/0x60, .magic: 00000000, .owner: <none>/-1,
> .owner_cpu: 0
> CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.8.0-rc5-next-20160905+ #14
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>  ffffffff886b6fe0 ffff88003ebf7d48 ffffffff82db81a9 ffffffff870b20c0
>  fffffbfff10d6dfc ffffffff8a6ac660 ffff88003ebee040 dffffc0000000000
>  ffffffff88ad2ca0 dffffc0000000000 ffff88003ebf7d80 ffffffff814a71fd
> Call Trace:
>  [<     inline     >] __dump_stack lib/dump_stack.c:15
>  [<ffffffff82db81a9>] dump_stack+0x12e/0x185 lib/dump_stack.c:51
>  [<ffffffff814a71fd>] spin_dump+0x14d/0x280 kernel/locking/spinlock_debug.c:67
>  [<     inline     >] spin_bug kernel/locking/spinlock_debug.c:75
>  [<     inline     >] debug_spin_lock_before kernel/locking/spinlock_debug.c:83
>  [<ffffffff814a75e4>] do_raw_spin_lock+0x224/0x2b0
> kernel/locking/spinlock_debug.c:135
>  [<     inline     >] __raw_spin_lock ./include/linux/spinlock_api_smp.h:145
>  [<ffffffff86e19a4b>] _raw_spin_lock+0x3b/0x50 kernel/locking/spinlock.c:151
>  [<     inline     >] spin_lock ./include/linux/spinlock.h:302
>  [<ffffffff896de48a>] ima_init_template_list+0x4c/0x10c
> security/integrity/ima/ima_template.c:218
>  [<ffffffff896ddb26>] init_ima+0xf/0x44 security/integrity/ima/ima_main.c:421
>  [<ffffffff81002310>] do_one_initcall+0xa0/0x2b0 init/main.c:782
>  [<     inline     >] do_initcall_level init/main.c:848
>  [<     inline     >] do_initcalls init/main.c:856
>  [<     inline     >] do_basic_setup init/main.c:874
>  [<ffffffff8963fd43>] kernel_init_freeable+0x476/0x52f init/main.c:1021
>  [<ffffffff86dff183>] kernel_init+0x13/0x160 init/main.c:947
>  [<ffffffff86e1ab4a>] ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
> 
> Seems to be caused by:
> 
> commit 5d74ec48cc8fd2109001c36bada5bf69c046b487
> Author: Mimi Zohar <zo...@li...>
> Date:   Sat Sep 3 15:20:40 2016 +1000
>     ima: store the builtin/custom template definitions in a list

Thank you for reporting this bug.  The fix will be included in the v4
post.

Mimi

[Linux-ima-user] ima: BUG: spinlock bad magic

[Dmitry V. <dv...@go...>]

Hello,

While booting linux-next on 4affa544adb8077403893e62b9e327fcf87de6f7
(Sep 8), I've got the following BUG:

BUG: spinlock bad magic on CPU#3, swapper/0/1
 lock: template_list+0x0/0x60, .magic: 00000000, .owner: <none>/-1,
.owner_cpu: 0
CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.8.0-rc5-next-20160905+ #14
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 ffffffff886b6fe0 ffff88003ebf7d48 ffffffff82db81a9 ffffffff870b20c0
 fffffbfff10d6dfc ffffffff8a6ac660 ffff88003ebee040 dffffc0000000000
 ffffffff88ad2ca0 dffffc0000000000 ffff88003ebf7d80 ffffffff814a71fd
Call Trace:
 [<     inline     >] __dump_stack lib/dump_stack.c:15
 [<ffffffff82db81a9>] dump_stack+0x12e/0x185 lib/dump_stack.c:51
 [<ffffffff814a71fd>] spin_dump+0x14d/0x280 kernel/locking/spinlock_debug.c:67
 [<     inline     >] spin_bug kernel/locking/spinlock_debug.c:75
 [<     inline     >] debug_spin_lock_before kernel/locking/spinlock_debug.c:83
 [<ffffffff814a75e4>] do_raw_spin_lock+0x224/0x2b0
kernel/locking/spinlock_debug.c:135
 [<     inline     >] __raw_spin_lock ./include/linux/spinlock_api_smp.h:145
 [<ffffffff86e19a4b>] _raw_spin_lock+0x3b/0x50 kernel/locking/spinlock.c:151
 [<     inline     >] spin_lock ./include/linux/spinlock.h:302
 [<ffffffff896de48a>] ima_init_template_list+0x4c/0x10c
security/integrity/ima/ima_template.c:218
 [<ffffffff896ddb26>] init_ima+0xf/0x44 security/integrity/ima/ima_main.c:421
 [<ffffffff81002310>] do_one_initcall+0xa0/0x2b0 init/main.c:782
 [<     inline     >] do_initcall_level init/main.c:848
 [<     inline     >] do_initcalls init/main.c:856
 [<     inline     >] do_basic_setup init/main.c:874
 [<ffffffff8963fd43>] kernel_init_freeable+0x476/0x52f init/main.c:1021
 [<ffffffff86dff183>] kernel_init+0x13/0x160 init/main.c:947
 [<ffffffff86e1ab4a>] ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Seems to be caused by:

commit 5d74ec48cc8fd2109001c36bada5bf69c046b487
Author: Mimi Zohar <zo...@li...>
Date:   Sat Sep 3 15:20:40 2016 +1000
    ima: store the builtin/custom template definitions in a list

[Linux-ima-user] [RFC 2/2] ima: Allow CAP_SYS_ADMIN in s_user_ns to write IMA xattrs

[Seth F. <set...@ca...>]

Signed-off-by: Seth Forshee <set...@ca...>
---
 security/integrity/ima/ima_appraise.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c
index a13fc6809554..007cea65b5ef 100644
--- a/security/integrity/ima/ima_appraise.c
+++ b/security/integrity/ima/ima_appraise.c
@@ -353,8 +353,9 @@ void ima_inode_post_setattr(struct dentry *dentry)
 static int ima_protect_xattr(struct dentry *dentry, const char *xattr_name,
 			     const void *xattr_value, size_t xattr_value_len)
 {
+	struct inode *inode = d_backing_inode(dentry);
 	if (strcmp(xattr_name, XATTR_NAME_IMA) == 0) {
-		if (!capable(CAP_SYS_ADMIN))
+		if (!ns_capable(inode->i_sb->s_user_ns, CAP_SYS_ADMIN))
 			return -EPERM;
 		return 1;
 	}
-- 
2.7.4

[Linux-ima-user] [RFC 1/2] evm: Ignore EVM xattrs from user namespace mounts

[Seth F. <set...@ca...>]

Ignore these xattrs in filesystems mounted in non-init user
namespaces to avoid preventing access to files, and refuse to
calculate new hmacs for files in these mounts. Writing EVM xattrs
from userspace already requires global CAP_SYS_ADMIN, so no
changes are required to prevent this.

Signed-off-by: Seth Forshee <set...@ca...>
---
 security/integrity/evm/evm_crypto.c | 2 +-
 security/integrity/evm/evm_main.c   | 3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c
index 11c1d30bd705..5a1738524fbb 100644
--- a/security/integrity/evm/evm_crypto.c
+++ b/security/integrity/evm/evm_crypto.c
@@ -182,7 +182,7 @@ static int evm_calc_hmac_or_hash(struct dentry *dentry,
 	int error;
 	int size;
 
-	if (!inode->i_op->getxattr)
+	if (inode->i_sb->s_user_ns != &init_user_ns || !inode->i_op->getxattr)
 		return -EOPNOTSUPP;
 	desc = init_desc(type);
 	if (IS_ERR(desc))
diff --git a/security/integrity/evm/evm_main.c b/security/integrity/evm/evm_main.c
index 35ab453ce861..7590f010d639 100644
--- a/security/integrity/evm/evm_main.c
+++ b/security/integrity/evm/evm_main.c
@@ -118,6 +118,9 @@ static enum integrity_status evm_verify_hmac(struct dentry *dentry,
 	enum integrity_status evm_status = INTEGRITY_PASS;
 	int rc, xattr_len;
 
+	if (d_backing_inode(dentry)->i_sb->s_user_ns != &init_user_ns)
+		return INTEGRITY_UNKNOWN;
+
 	if (iint && iint->evm_status == INTEGRITY_PASS)
 		return iint->evm_status;
 
-- 
2.7.4

[Linux-ima-user] [RFC 0/2] security/integrity: Updates for user namespace mounts

[Seth F. <set...@ca...>]

Hi Mimi,

Here's what I came up with based on our discussion about handling EVM
and IMA xattrs in mounts from non-init user namespaces. The updates are
fairly simple.

For EVM, refuse to verify or calculate a new hmac for filesystems
mounted from non-init user namespaces. Writing EVM xattrs from userspace
is already restricted to global CAP_SYS_ADMIN, and reading the xattrs
from userspace will still be allowed.

For IMA, allow CAP_SYS_ADMIN in s_user_ns to write xattrs.

Please let me know whether or not this lines up with what we discussed.

Thanks,
Seth


Seth Forshee (2):
  evm: Ignore EVM xattrs from user namespace mounts
  ima: Allow CAP_SYS_ADMIN in s_user_ns to write IMA xattrs

 security/integrity/evm/evm_crypto.c   | 2 +-
 security/integrity/evm/evm_main.c     | 3 +++
 security/integrity/ima/ima_appraise.c | 3 ++-
 3 files changed, 6 insertions(+), 2 deletions(-)

Re: [Linux-ima-user] [PATCH 0/1] EVM/IMA xattr hardening and unprivileged user ns mounts

[Seth F. <set...@ca...>]

On Wed, Sep 07, 2016 at 01:06:10PM -0400, Mimi Zohar wrote:
> On Wed, 2016-09-07 at 11:01 -0500, Seth Forshee wrote:
> > On Wed, Sep 07, 2016 at 11:20:19AM -0400, Mimi Zohar wrote:
> > > On Wed, 2016-09-07 at 07:27 -0500, Seth Forshee wrote:
> > > > On Tue, Sep 06, 2016 at 05:28:49PM -0400, Mimi Zohar wrote:
> > > > > On Tue, 2016-09-06 at 15:52 -0500, Seth Forshee wrote:
> > > > > > On Tue, Sep 06, 2016 at 04:00:32PM -0400, Mimi Zohar wrote:
> > > > > > > On Thu, 2016-09-01 at 08:22 -0500, Seth Forshee wrote:
> > > > > > > 
> > > > > > > > I've been reading back through all of this, and I'm not sure any
> > > > > > > > conclusion was reached.
> > > > > > > 
> > > > > > > > For my part, I'm uneasy about writing out hmacs to mounts from a
> > > > > > > > non-root user. So I'll make a proposal - let's not read or write EVM or
> > > > > > > > IMA xattrs for filesystems from non-init user namespace, essentially
> > > > > > > > behaving as though they don't support xattrs. Something like the
> > > > > > > > (untested) patch below.
> > > > > > > 
> > > > > > > This really doesn't sound like the right long term solution.
> > > > > > 
> > > > > > I'm not proposing this for a long term solution. I just haven't seen
> > > > > > that anyone has a real use case in mind yet for using the integrity
> > > > > > subsystem with these mounts and that it might be better to wait and
> > > > > > decide exactly how it should behave until someone does. In the mean time
> > > > > > I'm just trying to ensure there won't be vulnerabilities to exploit.
> > > > > 
> > > > > The main use case will be installing/updating packages within a
> > > > > container and writing the corresponding file signatures.  Unfortunately,
> > > > > we're not there yet.
> > > > 
> > > > Okay. If the distro is providing those signatures then I don't see a
> > > > problem with allowing them to be written. What concerns me is if there's
> > > > a scenario where the kernel would calculate and write out a signature or
> > > > hmac that would make the kernel trust the file in other contexts.
> > > 
> > > There's really no way of differentiating the source of the file
> > > signatures.  We either allow root in the namespace to write them or not.
> > 
> > I must be misunderstanding something then.
> 
> By file signature, I meant file data signature, which refers to IMA (not
> EVM).  

Okay. It does get a little confusing.

> > My impression was that for EVM we'd be dealing with some kind of keyed
> > signatures, not just hashes. In that case a user without the correct key
> > could write the EVM xattrs, then if the signature was correct the kernel
> > would permit access to the file, otherwise it would not.
> 
> Right, except the EVM signature is not portable, as it includes the
> inode in the signature.  Our work for including file signatures in
> packages is limited to the IMA file data signatures.  A new portable EVM
> format will be need for including EVM signatures in packages.
> 
> >  I.e. if the
> > user was installing distro packages which shipped with correct
> > signatures, the user could write those and the kernel would validate
> > them as correct. But if the user tried to write out their own files with
> > security xattrs they could not generate valid signatures, and the kernel
> > would deny access to those files.
> 
> > Is something about that incorrect?
> 
> That sounds right.  Userspace can write EVM signatures, using the
> ima-evm-utils package.  The asymmetric public key used for verifying the
> signature, would need to be loaded onto the EVM keyring.

Got it. Sounds like there currently wouldn't be any benefit to letting
ns-root write out EVM xattrs in that case. Of course we can't prevent
mounting a filesystem which already contains the xattrs, but we don't
have to make use of them.

> > > > So when s_user_ns != &init_user_ns it sounds like we could allow the
> > > > kernel to read and verify signatures and write out signatures provided
> > > > by userspace, but not calculate new/updated signatures for files. Does
> > > > that sound reasonable?
> > > 
> > > Not really.  At least initially, perhaps we should be differentiating
> > > between EVM and IMA xattrs, allowing only IMA xattrs to be read/written
> > > and returning EOPNOTSUPP, as you suggested, for EVM.  Having just IMA
> > > xattrs, without EVM xattrs, would then work in the namespace, but not
> > > outside of it (assuming EVM is enabled).
> > 
> > That's okay with me assuming it doesn't weaken security for systems with
> > EVM enabled. We're already effectively ignoring LSM security xattrs and
> > scoping capability xattrs to s_user_ns, so I think we should be okay.
> 
> The worst, which would be bad, is preventing access to a file, but it
> wouldn't make an invalid EVM signature/hmac valid.

Yeah, I've been taking another look at the code today and saw that was
the case. The only time I see the kernel writing out a new signature is
for IMA xattrs which are only digests and not signatures. So that seems
okay, and some of my concerns were unfounded.

I'll work up a patch then to deny reading and writing of EVM xattrs when
s_user_ns != &init_user_ns.

Thanks,
Seth

Re: [Linux-ima-user] [PATCH 0/1] EVM/IMA xattr hardening and unprivileged user ns mounts

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

On Wed, 2016-09-07 at 11:01 -0500, Seth Forshee wrote:
> On Wed, Sep 07, 2016 at 11:20:19AM -0400, Mimi Zohar wrote:
> > On Wed, 2016-09-07 at 07:27 -0500, Seth Forshee wrote:
> > > On Tue, Sep 06, 2016 at 05:28:49PM -0400, Mimi Zohar wrote:
> > > > On Tue, 2016-09-06 at 15:52 -0500, Seth Forshee wrote:
> > > > > On Tue, Sep 06, 2016 at 04:00:32PM -0400, Mimi Zohar wrote:
> > > > > > On Thu, 2016-09-01 at 08:22 -0500, Seth Forshee wrote:
> > > > > > 
> > > > > > > I've been reading back through all of this, and I'm not sure any
> > > > > > > conclusion was reached.
> > > > > > 
> > > > > > > For my part, I'm uneasy about writing out hmacs to mounts from a
> > > > > > > non-root user. So I'll make a proposal - let's not read or write EVM or
> > > > > > > IMA xattrs for filesystems from non-init user namespace, essentially
> > > > > > > behaving as though they don't support xattrs. Something like the
> > > > > > > (untested) patch below.
> > > > > > 
> > > > > > This really doesn't sound like the right long term solution.
> > > > > 
> > > > > I'm not proposing this for a long term solution. I just haven't seen
> > > > > that anyone has a real use case in mind yet for using the integrity
> > > > > subsystem with these mounts and that it might be better to wait and
> > > > > decide exactly how it should behave until someone does. In the mean time
> > > > > I'm just trying to ensure there won't be vulnerabilities to exploit.
> > > > 
> > > > The main use case will be installing/updating packages within a
> > > > container and writing the corresponding file signatures.  Unfortunately,
> > > > we're not there yet.
> > > 
> > > Okay. If the distro is providing those signatures then I don't see a
> > > problem with allowing them to be written. What concerns me is if there's
> > > a scenario where the kernel would calculate and write out a signature or
> > > hmac that would make the kernel trust the file in other contexts.
> > 
> > There's really no way of differentiating the source of the file
> > signatures.  We either allow root in the namespace to write them or not.
> 
> I must be misunderstanding something then.

By file signature, I meant file data signature, which refers to IMA (not
EVM).  

> My impression was that for EVM we'd be dealing with some kind of keyed
> signatures, not just hashes. In that case a user without the correct key
> could write the EVM xattrs, then if the signature was correct the kernel
> would permit access to the file, otherwise it would not.

Right, except the EVM signature is not portable, as it includes the
inode in the signature.  Our work for including file signatures in
packages is limited to the IMA file data signatures.  A new portable EVM
format will be need for including EVM signatures in packages.

>  I.e. if the
> user was installing distro packages which shipped with correct
> signatures, the user could write those and the kernel would validate
> them as correct. But if the user tried to write out their own files with
> security xattrs they could not generate valid signatures, and the kernel
> would deny access to those files.

> Is something about that incorrect?

That sounds right.  Userspace can write EVM signatures, using the
ima-evm-utils package.  The asymmetric public key used for verifying the
signature, would need to be loaded onto the EVM keyring.

> > > So when s_user_ns != &init_user_ns it sounds like we could allow the
> > > kernel to read and verify signatures and write out signatures provided
> > > by userspace, but not calculate new/updated signatures for files. Does
> > > that sound reasonable?
> > 
> > Not really.  At least initially, perhaps we should be differentiating
> > between EVM and IMA xattrs, allowing only IMA xattrs to be read/written
> > and returning EOPNOTSUPP, as you suggested, for EVM.  Having just IMA
> > xattrs, without EVM xattrs, would then work in the namespace, but not
> > outside of it (assuming EVM is enabled).
> 
> That's okay with me assuming it doesn't weaken security for systems with
> EVM enabled. We're already effectively ignoring LSM security xattrs and
> scoping capability xattrs to s_user_ns, so I think we should be okay.

The worst, which would be bad, is preventing access to a file, but it
wouldn't make an invalid EVM signature/hmac valid.

Mimi

Re: [Linux-ima-user] [PATCH 0/1] EVM/IMA xattr hardening and unprivileged user ns mounts

[Seth F. <set...@ca...>]

On Wed, Sep 07, 2016 at 11:20:19AM -0400, Mimi Zohar wrote:
> On Wed, 2016-09-07 at 07:27 -0500, Seth Forshee wrote:
> > On Tue, Sep 06, 2016 at 05:28:49PM -0400, Mimi Zohar wrote:
> > > On Tue, 2016-09-06 at 15:52 -0500, Seth Forshee wrote:
> > > > On Tue, Sep 06, 2016 at 04:00:32PM -0400, Mimi Zohar wrote:
> > > > > On Thu, 2016-09-01 at 08:22 -0500, Seth Forshee wrote:
> > > > > 
> > > > > > I've been reading back through all of this, and I'm not sure any
> > > > > > conclusion was reached.
> > > > > 
> > > > > > For my part, I'm uneasy about writing out hmacs to mounts from a
> > > > > > non-root user. So I'll make a proposal - let's not read or write EVM or
> > > > > > IMA xattrs for filesystems from non-init user namespace, essentially
> > > > > > behaving as though they don't support xattrs. Something like the
> > > > > > (untested) patch below.
> > > > > 
> > > > > This really doesn't sound like the right long term solution.
> > > > 
> > > > I'm not proposing this for a long term solution. I just haven't seen
> > > > that anyone has a real use case in mind yet for using the integrity
> > > > subsystem with these mounts and that it might be better to wait and
> > > > decide exactly how it should behave until someone does. In the mean time
> > > > I'm just trying to ensure there won't be vulnerabilities to exploit.
> > > 
> > > The main use case will be installing/updating packages within a
> > > container and writing the corresponding file signatures.  Unfortunately,
> > > we're not there yet.
> > 
> > Okay. If the distro is providing those signatures then I don't see a
> > problem with allowing them to be written. What concerns me is if there's
> > a scenario where the kernel would calculate and write out a signature or
> > hmac that would make the kernel trust the file in other contexts.
> 
> There's really no way of differentiating the source of the file
> signatures.  We either allow root in the namespace to write them or not.

I must be misunderstanding something then.

My impression was that for EVM we'd be dealing with some kind of keyed
signatures, not just hashes. In that case a user without the correct key
could write the EVM xattrs, then if the signature was correct the kernel
would permit access to the file, otherwise it would not. I.e. if the
user was installing distro packages which shipped with correct
signatures, the user could write those and the kernel would validate
them as correct. But if the user tried to write out their own files with
security xattrs they could not generate valid signatures, and the kernel
would deny access to those files.

Is something about that incorrect?

> > So when s_user_ns != &init_user_ns it sounds like we could allow the
> > kernel to read and verify signatures and write out signatures provided
> > by userspace, but not calculate new/updated signatures for files. Does
> > that sound reasonable?
> 
> Not really.  At least initially, perhaps we should be differentiating
> between EVM and IMA xattrs, allowing only IMA xattrs to be read/written
> and returning EOPNOTSUPP, as you suggested, for EVM.  Having just IMA
> xattrs, without EVM xattrs, would then work in the namespace, but not
> outside of it (assuming EVM is enabled).

That's okay with me assuming it doesn't weaken security for systems with
EVM enabled. We're already effectively ignoring LSM security xattrs and
scoping capability xattrs to s_user_ns, so I think we should be okay.

Thanks,
Seth

Re: [Linux-ima-user] [PATCH 0/1] EVM/IMA xattr hardening and unprivileged user ns mounts

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

On Wed, 2016-09-07 at 07:27 -0500, Seth Forshee wrote:
> On Tue, Sep 06, 2016 at 05:28:49PM -0400, Mimi Zohar wrote:
> > On Tue, 2016-09-06 at 15:52 -0500, Seth Forshee wrote:
> > > On Tue, Sep 06, 2016 at 04:00:32PM -0400, Mimi Zohar wrote:
> > > > On Thu, 2016-09-01 at 08:22 -0500, Seth Forshee wrote:
> > > > 
> > > > > I've been reading back through all of this, and I'm not sure any
> > > > > conclusion was reached.
> > > > 
> > > > > For my part, I'm uneasy about writing out hmacs to mounts from a
> > > > > non-root user. So I'll make a proposal - let's not read or write EVM or
> > > > > IMA xattrs for filesystems from non-init user namespace, essentially
> > > > > behaving as though they don't support xattrs. Something like the
> > > > > (untested) patch below.
> > > > 
> > > > This really doesn't sound like the right long term solution.
> > > 
> > > I'm not proposing this for a long term solution. I just haven't seen
> > > that anyone has a real use case in mind yet for using the integrity
> > > subsystem with these mounts and that it might be better to wait and
> > > decide exactly how it should behave until someone does. In the mean time
> > > I'm just trying to ensure there won't be vulnerabilities to exploit.
> > 
> > The main use case will be installing/updating packages within a
> > container and writing the corresponding file signatures.  Unfortunately,
> > we're not there yet.
> 
> Okay. If the distro is providing those signatures then I don't see a
> problem with allowing them to be written. What concerns me is if there's
> a scenario where the kernel would calculate and write out a signature or
> hmac that would make the kernel trust the file in other contexts.

There's really no way of differentiating the source of the file
signatures.  We either allow root in the namespace to write them or not.

> So when s_user_ns != &init_user_ns it sounds like we could allow the
> kernel to read and verify signatures and write out signatures provided
> by userspace, but not calculate new/updated signatures for files. Does
> that sound reasonable?

Not really.  At least initially, perhaps we should be differentiating
between EVM and IMA xattrs, allowing only IMA xattrs to be read/written
and returning EOPNOTSUPP, as you suggested, for EVM.  Having just IMA
xattrs, without EVM xattrs, would then work in the namespace, but not
outside of it (assuming EVM is enabled).

Mimi

Re: [Linux-ima-user] [PATCH 0/1] EVM/IMA xattr hardening and unprivileged user ns mounts

[Seth F. <set...@ca...>]

On Tue, Sep 06, 2016 at 05:28:49PM -0400, Mimi Zohar wrote:
> On Tue, 2016-09-06 at 15:52 -0500, Seth Forshee wrote:
> > On Tue, Sep 06, 2016 at 04:00:32PM -0400, Mimi Zohar wrote:
> > > On Thu, 2016-09-01 at 08:22 -0500, Seth Forshee wrote:
> > > 
> > > > I've been reading back through all of this, and I'm not sure any
> > > > conclusion was reached.
> > > 
> > > > For my part, I'm uneasy about writing out hmacs to mounts from a
> > > > non-root user. So I'll make a proposal - let's not read or write EVM or
> > > > IMA xattrs for filesystems from non-init user namespace, essentially
> > > > behaving as though they don't support xattrs. Something like the
> > > > (untested) patch below.
> > > 
> > > This really doesn't sound like the right long term solution.
> > 
> > I'm not proposing this for a long term solution. I just haven't seen
> > that anyone has a real use case in mind yet for using the integrity
> > subsystem with these mounts and that it might be better to wait and
> > decide exactly how it should behave until someone does. In the mean time
> > I'm just trying to ensure there won't be vulnerabilities to exploit.
> 
> The main use case will be installing/updating packages within a
> container and writing the corresponding file signatures.  Unfortunately,
> we're not there yet.

Okay. If the distro is providing those signatures then I don't see a
problem with allowing them to be written. What concerns me is if there's
a scenario where the kernel would calculate and write out a signature or
hmac that would make the kernel trust the file in other contexts.

So when s_user_ns != &init_user_ns it sounds like we could allow the
kernel to read and verify signatures and write out signatures provided
by userspace, but not calculate new/updated signatures for files. Does
that sound reasonable?

Thanks,
Seth

Re: [Linux-ima-user] [PATCH 0/1] EVM/IMA xattr hardening and unprivileged user ns mounts

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

On Tue, 2016-09-06 at 15:52 -0500, Seth Forshee wrote:
> On Tue, Sep 06, 2016 at 04:00:32PM -0400, Mimi Zohar wrote:
> > On Thu, 2016-09-01 at 08:22 -0500, Seth Forshee wrote:
> > 
> > > I've been reading back through all of this, and I'm not sure any
> > > conclusion was reached.
> > 
> > > For my part, I'm uneasy about writing out hmacs to mounts from a
> > > non-root user. So I'll make a proposal - let's not read or write EVM or
> > > IMA xattrs for filesystems from non-init user namespace, essentially
> > > behaving as though they don't support xattrs. Something like the
> > > (untested) patch below.
> > 
> > This really doesn't sound like the right long term solution.
> 
> I'm not proposing this for a long term solution. I just haven't seen
> that anyone has a real use case in mind yet for using the integrity
> subsystem with these mounts and that it might be better to wait and
> decide exactly how it should behave until someone does. In the mean time
> I'm just trying to ensure there won't be vulnerabilities to exploit.

The main use case will be installing/updating packages within a
container and writing the corresponding file signatures.  Unfortunately,
we're not there yet.

> > The kernel, as well as root in the namespace, should write the EVM and
> > IMA security xattrs, as long as their usage is limited to the uid/gid
> > associated with that user_ns namespace.
> 
> But keep in mind that the uid mapping doesn't get written out to disk.
> If I create a file owned by uid 0 in my namespace (let's say that maps
> to uid 1000 in init_user_ns) then uid 0 is what will be written to the
> inode on disk.

oh!

> Based on my understanding of what you said previously, this means that I
> could create a file in my filesystem as root in my user ns and write out
> a security.capability xattr, and the kernel would then write out an EVM
> xattr with a valid signature. If I can then manage to get that file
> mounted in init_user_ns the kernel will be owned by real root and the
> kernel will see a valid signature for the capability xattr.

I see.

> Granted, this scenario is problematic even without EVM, but it seems
> like specifically the kind of thing someone might use EVM to protect
> against.

Agreed.

Mimi

Re: [Linux-ima-user] [PATCH 0/1] EVM/IMA xattr hardening and unprivileged user ns mounts

[Seth F. <set...@ca...>]

On Tue, Sep 06, 2016 at 04:00:32PM -0400, Mimi Zohar wrote:
> On Thu, 2016-09-01 at 08:22 -0500, Seth Forshee wrote:
> 
> > I've been reading back through all of this, and I'm not sure any
> > conclusion was reached.
> 
> > For my part, I'm uneasy about writing out hmacs to mounts from a
> > non-root user. So I'll make a proposal - let's not read or write EVM or
> > IMA xattrs for filesystems from non-init user namespace, essentially
> > behaving as though they don't support xattrs. Something like the
> > (untested) patch below.
> 
> This really doesn't sound like the right long term solution.

I'm not proposing this for a long term solution. I just haven't seen
that anyone has a real use case in mind yet for using the integrity
subsystem with these mounts and that it might be better to wait and
decide exactly how it should behave until someone does. In the mean time
I'm just trying to ensure there won't be vulnerabilities to exploit.

> The kernel, as well as root in the namespace, should write the EVM and
> IMA security xattrs, as long as their usage is limited to the uid/gid
> associated with that user_ns namespace.

But keep in mind that the uid mapping doesn't get written out to disk.
If I create a file owned by uid 0 in my namespace (let's say that maps
to uid 1000 in init_user_ns) then uid 0 is what will be written to the
inode on disk.

Based on my understanding of what you said previously, this means that I
could create a file in my filesystem as root in my user ns and write out
a security.capability xattr, and the kernel would then write out an EVM
xattr with a valid signature. If I can then manage to get that file
mounted in init_user_ns the kernel will be owned by real root and the
kernel will see a valid signature for the capability xattr.

Granted, this scenario is problematic even without EVM, but it seems
like specifically the kind of thing someone might use EVM to protect
against.

Thanks,
Seth

> In terms of the USB stick scenario, instead of security.evm containing
> HMACs, they would need to be replaced with signatures, before using it
> on another system.  Refer to the ima-evm-utils package for writing out
> security.evm signatures.
> 
> Mimi
> 

Re: [Linux-ima-user] [PATCH 0/1] EVM/IMA xattr hardening and unprivileged user ns mounts

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

On Thu, 2016-09-01 at 08:22 -0500, Seth Forshee wrote:

> I've been reading back through all of this, and I'm not sure any
> conclusion was reached.

> For my part, I'm uneasy about writing out hmacs to mounts from a
> non-root user. So I'll make a proposal - let's not read or write EVM or
> IMA xattrs for filesystems from non-init user namespace, essentially
> behaving as though they don't support xattrs. Something like the
> (untested) patch below.

This really doesn't sound like the right long term solution.  The
kernel, as well as root in the namespace, should write the EVM and IMA
security xattrs, as long as their usage is limited to the uid/gid
associated with that user_ns namespace.

In terms of the USB stick scenario, instead of security.evm containing
HMACs, they would need to be replaced with signatures, before using it
on another system.  Refer to the ima-evm-utils package for writing out
security.evm signatures.

Mimi

Re: [Linux-ima-user] IMA Configuration

[Mark D. B. <md...@ju...>]

Marlon Chalegre <mc...@ce...> writes:

> I have some questions about how to configure the IMA and I'm wondering if
> you could help me understand some things.
> 
> 1 - Could I configure the IMA to measure/appraise only specific folder
> and/or file?

Yes, but this will require labeling the file or directory using LSM
labels (with either SMACK or SE Linux extensions) and then writing an
IMA Policy that uses the label to control the measure/dont_measure and
appraise rules.

The LSM system must be enabled before IMA if you are going to use it in
this manner.

> 2 - Is there any example or documentation about how to use different rules
> like uid, fowner, uuid, LSM labels, etc to limit which files and folders
> must be measured?

There is some text on the subject on the linux-ima wiki:

https://sourceforge.net/p/linux-ima/wiki/Home/#defining-an-lsm-specific-policy

which mentions adding LSM specific rules.

> In a previous contact with Zohar, she said to me that the question number
> one is not implemented. Is this a good improvement to be developed?

I do not know when that was, but it is implemented now. The use of SMACK
vs SE Linux with IMA is largely going to depend on the security
considerations for your particular installation.

You do have the flexibility to do what you want now.

	-- Mark

Re: [Linux-ima-user] IMA Configuration

[Marlon C. <mc...@ce...>]

Thank you, I'll take a look.

On Tue, Sep 6, 2016 at 11:37 AM, Mark D. Baushke <md...@ju...> wrote:

> Marlon Chalegre <mc...@ce...> writes:
>
> > I have some questions about how to configure the IMA and I'm wondering if
> > you could help me understand some things.
> >
> > 1 - Could I configure the IMA to measure/appraise only specific folder
> > and/or file?
>
> Yes, but this will require labeling the file or directory using LSM
> labels (with either SMACK or SE Linux extensions) and then writing an
> IMA Policy that uses the label to control the measure/dont_measure and
> appraise rules.
>
> The LSM system must be enabled before IMA if you are going to use it in
> this manner.
>
> > 2 - Is there any example or documentation about how to use different
> rules
> > like uid, fowner, uuid, LSM labels, etc to limit which files and folders
> > must be measured?
>
> There is some text on the subject on the linux-ima wiki:
>
> https://sourceforge.net/p/linux-ima/wiki/Home/#defining-
> an-lsm-specific-policy
>
> which mentions adding LSM specific rules.
>
> > In a previous contact with Zohar, she said to me that the question number
> > one is not implemented. Is this a good improvement to be developed?
>
> I do not know when that was, but it is implemented now. The use of SMACK
> vs SE Linux with IMA is largely going to depend on the security
> considerations for your particular installation.
>
> You do have the flexibility to do what you want now.
>
>         -- Mark
>



-- 
*Marlon Chalegre*
*Software Engineer*