Menu
▾
▴
linux-ima-user — Q&A for users of IMA
This list is closed, nobody may subscribe to it.
| 2007 |
Jan
|
Feb
(10) |
Mar
(26) |
Apr
(8) |
May
(3) |
Jun
|
Jul
(26) |
Aug
(10) |
Sep
|
Oct
|
Nov
(2) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
(13) |
Mar
(4) |
Apr
(3) |
May
(5) |
Jun
|
Jul
(7) |
Aug
(8) |
Sep
(5) |
Oct
(16) |
Nov
|
Dec
(6) |
| 2009 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
(19) |
Jul
(4) |
Aug
|
Sep
(13) |
Oct
(10) |
Nov
(12) |
Dec
(2) |
| 2010 |
Jan
|
Feb
(2) |
Mar
(17) |
Apr
(28) |
May
|
Jun
(17) |
Jul
(11) |
Aug
(12) |
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
| 2011 |
Jan
|
Feb
|
Mar
(20) |
Apr
(10) |
May
(1) |
Jun
|
Jul
|
Aug
(15) |
Sep
(14) |
Oct
(2) |
Nov
|
Dec
|
| 2012 |
Jan
(1) |
Feb
(53) |
Mar
(15) |
Apr
(4) |
May
(2) |
Jun
(13) |
Jul
|
Aug
|
Sep
(12) |
Oct
|
Nov
|
Dec
(6) |
| 2013 |
Jan
(7) |
Feb
(8) |
Mar
(4) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
(6) |
Oct
|
Nov
(5) |
Dec
(8) |
| 2014 |
Jan
(17) |
Feb
(24) |
Mar
(8) |
Apr
(7) |
May
(18) |
Jun
(15) |
Jul
(5) |
Aug
(2) |
Sep
(49) |
Oct
(28) |
Nov
(7) |
Dec
(30) |
| 2015 |
Jan
(40) |
Feb
|
Mar
(9) |
Apr
(2) |
May
(9) |
Jun
(31) |
Jul
(33) |
Aug
(5) |
Sep
(20) |
Oct
|
Nov
(3) |
Dec
(12) |
| 2016 |
Jan
(14) |
Feb
(29) |
Mar
(10) |
Apr
(4) |
May
(4) |
Jun
|
Jul
(5) |
Aug
(19) |
Sep
(21) |
Oct
(2) |
Nov
(36) |
Dec
(30) |
| 2017 |
Jan
(101) |
Feb
(12) |
Mar
(7) |
Apr
(2) |
May
(29) |
Jun
(22) |
Jul
(7) |
Aug
(93) |
Sep
(27) |
Oct
(39) |
Nov
|
Dec
|
|
From: Patrick O. <pat...@in...> - 2015-07-10 20:41:26
|
On Fri, 2015-07-10 at 15:51 -0400, Mimi Zohar wrote: > On Fri, 2015-07-10 at 15:46 +0200, Patrick Ohly wrote: > > Hello! > > > > I have (at least) one file where verifying the signature created by > > evmctl ima_sign fails. ima-evm-utils is 0.9 (git rev 3d9bdc1de2, the > > current master). > > Was the file previously signed before this? In enforcing mode, > existing signatures are considered to be "immutable" and can not be > removed/replaced. I'm running these commands on a build host which does not have IMA enabled. So it's really a test of the code inside evmctl. It seems to produce a bad security.ima; both the kernel (on a different system) and evmctl's own signature check code agree on that. > > $ evmctl ima_sign privkey_ima.pem pam_securetty.so > > $ getfattr -d -m . pam_securetty.so > > getfattr: Removing leading '/' from absolute path names > > # file: tmp/pam_securetty.so > > security.ima=0sAwIC2C1O/QCAEQNetDHu9W+Zn5bpL+cC2BvdkJNs6GIkS5EmD75MXrk+K0e0GLZOmAqwLbe/jOnsnw00WbthqG5xo7Vop+yDGnNVlGU95YQ1KQEqC3OZILkF5gyY88AU/T3y6UGa5Vl1FEvUrp4aVOUmTwqO6Wm/bVtJnNilhxkvRItjVNcVgQ== > > $ evmctl ima_verify --key x509_ima.der pam_securetty.so > > RSA_public_decrypt() failed: -1 > > error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01 > > error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed > > When displaying security.ima, please use the "-e hex" option. Then I get: security.ima=0x030202d82d4efd008011035eb431eef56f999f96e92fe702d81bdd90936ce862244b91260fbe4c5eb93e2b47b418b64e980ab02db7bf8ce9ec9f0d3459bb61a86e71a3b568a7ec831a735594653de5843529012a0b739920b905e60c98f3c014fd3df2e9419ae55975144bd4ae9e1a54e5264f0a8ee969bf6d5b499cd8a587192f448b6354d71581 > > The signature check done by the Linux kernel 3.19.2 also fails. > > Compare the key embedded in the signature with the key on the IMA > keyring. For example, /bin/more on my system is signed with the pseudo > fedora signing key - 0x96042912. (The keyid are the last bytes of the > key.) In this case, I specify the keys explicitly (privkey_ima.pem and x509_ima.der). I know that they match, because signing some other file and verifying it works. -- Best Regards Patrick Ohly Senior Software Engineer Intel GmbH Open Source Technology Center Usenerstr. 5a Phone: +49-228-2493652 53129 Bonn Germany |
|
From: Patrick O. <pat...@in...> - 2015-07-10 20:19:40
|
On Fri, 2015-07-10 at 15:04 -0400, Mimi Zohar wrote:
> On Fri, 2015-07-10 at 15:02 +0200, Patrick Ohly wrote:
> > Hello!
> >
> > Last time I looked at the IMA policy loading, I was baffled that the
> > kernel ABI explicitly says that each write must be exactly one rule,
> > while systemd used one write() for the entire policy file. At that time
> > I concluded that the latter happens to work because the kernel reports
> > shorts writes after each rule and systemd retries with the rest. That's
> > also how it worked for cat.
>
> Originally writing only one line at a time was supported, but that
> changed with commit "6ccd045 ima: handle multiple rules per write" by
> Eric Paris. The kernel ABI documentation needs to be updated to
> reflect this change.
Yes, that's the behavior that I was seeing when cat worked (short writes
+ retries). However, in this case the very first write fails with
"Invalid argument" even though the policy is valid (writing it line by
line works).
> > However, now I ran into a situation where cat does not work for a policy
> > which seems to be correct (attached):
> >
> > strace -s 1000 cat /etc/ima/ima-policy-floor >/sys/kernel/security/ima/policy
> > ...
> > open("/etc/ima/ima-policy-floor", O_RDONLY|O_LARGEFILE) = 3
> > sendfile64(1, 3, NULL, 16777216) = 2
> > sendfile64(1, 3, NULL, 16777216) = -1 EINVAL (Invalid argument)
> > read(3, "# Integrity measure policy (http://sourceforge.net/p/linux-ima/wiki/Home/#measure-nothing-appraise-everything)\n# \n# Do not measure anything, but appraise everything\n#\n# PROC_SUPER_MAGIC\ndont_appraise fsmagic=0x9fa0\n# SYSFS_MAGIC\ndont_appraise fsmagic=0x62656572\n# DEBUGFS_MAGIC\ndont_appraise fsmagic=0x64626720\n# TMPFS_MAGIC\ndont_appraise fsmagic=0x01021994\n# RAMFS_MAGIC\ndont_appraise fsmagic=0x858458f6\n# DEVPTS_SUPER_MAGIC\ndont_appraise fsmagic=0x1cd1\n# BIFMT\ndont_appraise fsmagic=0x42494e4d\n# SECURITYFS_MAGIC\ndont_appraise fsmagic=0x73636673\n# SELINUXFS_MAGIC\ndont_appraise fsmagic=0xf97cff8c\n\n# Appraise all operations on files with floor label.\nappraise obj_user=_\n", 4096) = 673
> > write(1, "# Integrity measure policy (http://sourceforge.net/p/linux-ima/wiki/Home/#measure-nothing-appraise-everything)\n# \n# Do not measure anything, but appraise everything\n#\n# PROC_SUPER_MAGIC\ndont_appraise fsmagic=0x9fa0\n# SYSFS_MAGIC\ndont_appraise fsmagic=0x62656572\n# DEBUGFS_MAGIC\ndont_appraise fsmagic=0x64626720\n# TMPFS_MAGIC\ndont_appraise fsmagic=0x01021994\n# RAMFS_MAGIC\ndont_appraise fsmagic=0x858458f6\n# DEVPTS_SUPER_MAGIC\ndont_appraise fsmagic=0x1cd1\n# BIFMT\ndont_appraise fsmagic=0x42494e4d\n# SECURITYFS_MAGIC\ndont_appraise fsmagic=0x73636673\n# SELINUXFS_MAGIC\ndont_appraise fsmagic=0xf97cff8c\n\n# Appraise all operations on files with floor label.\nappraise obj_user=_\n", 673) = -1 EINVAL (Invalid argument)
> > brk(0) = 0xb77cd000
> > brk(0xb77ee000) = 0xb77ee000
> > write(2, "cat: write error: Invalid argument\n", 35cat: write error: Invalid argument
> >
> > This is on a 3.19.2 kernel.
> >
> > Writing each line one-by-one works:
> >
> > (set -e; while read i; do echo $i >&2; echo $i; done) </etc/ima/ima-policy-floor >/sys/kernel/security/ima/policy
> >
> > The shell loop writes to stderr and stdout on purpose. That way a broken
> > policy rule can be identified, which is not the case when using cat.
> >
> > That works for me at the moment, but I am wondering how that'll effect
> > policy loading via systemd. Is there anything in the policy that breaks
> > the short write mechanism?
>
> Commit 4dfb18922d5d "ima-setup: simplify" broke systemd IMA. Zbigniew
> Jędrzejewski-Szmek partially reverted the change. For an explanation of
> the bug, please refer to
> https://bugzilla.redhat.com/show_bug.cgi?id=1226948 .
I know :-) I was the one who found and investigated that bug.
--
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.
|
|
From: Patrick O. <pat...@in...> - 2015-07-10 20:14:47
|
On Fri, 2015-07-10 at 15:51 -0400, Mimi Zohar wrote: > On Fri, 2015-07-10 at 15:46 +0200, Patrick Ohly wrote: > > Hello! > > > > I have (at least) one file where verifying the signature created by > > evmctl ima_sign fails. ima-evm-utils is 0.9 (git rev 3d9bdc1de2, the > > current master). > > Was the file previously signed before this? In enforcing mode, > existing signatures are considered to be "immutable" and can not be > removed/replaced. I'm running these commands on a build host which does not have IMA enabled. So it's really a test of the code inside evmctl. It seems to produce a bad security.ima; both the kernel (on a different system) and evmctl's own signature check code agree on that. > > $ evmctl ima_sign privkey_ima.pem pam_securetty.so > > $ getfattr -d -m . pam_securetty.so > > getfattr: Removing leading '/' from absolute path names > > # file: tmp/pam_securetty.so > > security.ima=0sAwIC2C1O/QCAEQNetDHu9W+Zn5bpL+cC2BvdkJNs6GIkS5EmD75MXrk+K0e0GLZOmAqwLbe/jOnsnw00WbthqG5xo7Vop+yDGnNVlGU95YQ1KQEqC3OZILkF5gyY88AU/T3y6UGa5Vl1FEvUrp4aVOUmTwqO6Wm/bVtJnNilhxkvRItjVNcVgQ== > > $ evmctl ima_verify --key x509_ima.der pam_securetty.so > > RSA_public_decrypt() failed: -1 > > error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01 > > error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed > > When displaying security.ima, please use the "-e hex" option. Then I get: security.ima=0x030202d82d4efd008011035eb431eef56f999f96e92fe702d81bdd90936ce862244b91260fbe4c5eb93e2b47b418b64e980ab02db7bf8ce9ec9f0d3459bb61a86e71a3b568a7ec831a735594653de5843529012a0b739920b905e60c98f3c014fd3df2e9419ae55975144bd4ae9e1a54e5264f0a8ee969bf6d5b499cd8a587192f448b6354d71581 > > The signature check done by the Linux kernel 3.19.2 also fails. > > Compare the key embedded in the signature with the key on the IMA > keyring. For example, /bin/more on my system is signed with the pseudo > fedora signing key - 0x96042912. (The keyid are the last bytes of the > key.) In this case, I specify the keys explicitly (privkey_ima.pem and x509_ima.der). I know that they match, because signing some other file and verifying it works. -- 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. |
|
From: Mimi Z. <zo...@li...> - 2015-07-10 19:52:44
|
On Fri, 2015-07-10 at 15:46 +0200, Patrick Ohly wrote: > Hello! > > I have (at least) one file where verifying the signature created by > evmctl ima_sign fails. ima-evm-utils is 0.9 (git rev 3d9bdc1de2, the > current master). Was the file previously signed before this? In enforcing mode, existing signatures are considered to be "immutable" and can not be removed/replaced. > > $ evmctl ima_sign privkey_ima.pem pam_securetty.so > $ getfattr -d -m . pam_securetty.so > getfattr: Removing leading '/' from absolute path names > # file: tmp/pam_securetty.so > security.ima=0sAwIC2C1O/QCAEQNetDHu9W+Zn5bpL+cC2BvdkJNs6GIkS5EmD75MXrk+K0e0GLZOmAqwLbe/jOnsnw00WbthqG5xo7Vop+yDGnNVlGU95YQ1KQEqC3OZILkF5gyY88AU/T3y6UGa5Vl1FEvUrp4aVOUmTwqO6Wm/bVtJnNilhxkvRItjVNcVgQ== > $ evmctl ima_verify --key x509_ima.der pam_securetty.so > RSA_public_decrypt() failed: -1 > error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01 > error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed When displaying security.ima, please use the "-e hex" option. > The signature check done by the Linux kernel 3.19.2 also fails. Compare the key embedded in the signature with the key on the IMA keyring. For example, /bin/more on my system is signed with the pseudo fedora signing key - 0x96042912. (The keyid are the last bytes of the key.) # getfattr -m ^security -e hex --dump /bin/more getfattr: Removing leading '/' from absolute path names # file: bin/more security.evm=0x02e996f12568606b6178fa9c58799cc0cc3620e1b7 security.ima=0x030204960429120100034051af2a433369270a3fee0b1594a8ad8a50a722312c032f3abf9beeb163f4784671cea453e54bad35ce1f780316aec80026c04243541755ea42c2a381b33e6f596c55975c7590926b7f9df6b1096332934fb1e363c35ef2f8d1c1b4ea74dfe75e6ec01325ff15ebeaa9f1f23ef46bff8669ec514e2cd93c69d6329139a5081110785f46e4c522821bc1dcfe292d2125a946e0c29556be122bc0066170da8fb5a9eb25387ecf2a71c56924b11211865fef7f570cba08aaa2f0577a8fcfda35feff34fcb8ea847e0326a30b184b9d3fa1c48b5e61fe9928ce60f4076a82758bb67e734d3ea748944bf12d5b14dbfbc8ff40bfecda785e74d2c1842b7b91471a security.selinux=0x73797374656d5f753a6f626a6563745f723a62696e5f743a733000 # keyctl show %keyring:.ima Keyring 481174173 ---lswrv 0 0 keyring: .ima 872061722 --als--v 0 0 \_ asymmetric: fedora: pseudo signing key: 19536be0c0f540de1debfa6265469c3696042912 409033268 --als--v 0 0 \_ asymmetric: local: pseudo signing key: 52b49042bdf4e0e005568b0afde870c2b3960f7f Mimi |
|
From: Mimi Z. <zo...@li...> - 2015-07-10 19:05:20
|
On Fri, 2015-07-10 at 15:02 +0200, Patrick Ohly wrote:
> Hello!
>
> Last time I looked at the IMA policy loading, I was baffled that the
> kernel ABI explicitly says that each write must be exactly one rule,
> while systemd used one write() for the entire policy file. At that time
> I concluded that the latter happens to work because the kernel reports
> shorts writes after each rule and systemd retries with the rest. That's
> also how it worked for cat.
Originally writing only one line at a time was supported, but that
changed with commit "6ccd045 ima: handle multiple rules per write" by
Eric Paris. The kernel ABI documentation needs to be updated to
reflect this change.
> However, now I ran into a situation where cat does not work for a policy
> which seems to be correct (attached):
>
> strace -s 1000 cat /etc/ima/ima-policy-floor >/sys/kernel/security/ima/policy
> ...
> open("/etc/ima/ima-policy-floor", O_RDONLY|O_LARGEFILE) = 3
> sendfile64(1, 3, NULL, 16777216) = 2
> sendfile64(1, 3, NULL, 16777216) = -1 EINVAL (Invalid argument)
> read(3, "# Integrity measure policy (http://sourceforge.net/p/linux-ima/wiki/Home/#measure-nothing-appraise-everything)\n# \n# Do not measure anything, but appraise everything\n#\n# PROC_SUPER_MAGIC\ndont_appraise fsmagic=0x9fa0\n# SYSFS_MAGIC\ndont_appraise fsmagic=0x62656572\n# DEBUGFS_MAGIC\ndont_appraise fsmagic=0x64626720\n# TMPFS_MAGIC\ndont_appraise fsmagic=0x01021994\n# RAMFS_MAGIC\ndont_appraise fsmagic=0x858458f6\n# DEVPTS_SUPER_MAGIC\ndont_appraise fsmagic=0x1cd1\n# BIFMT\ndont_appraise fsmagic=0x42494e4d\n# SECURITYFS_MAGIC\ndont_appraise fsmagic=0x73636673\n# SELINUXFS_MAGIC\ndont_appraise fsmagic=0xf97cff8c\n\n# Appraise all operations on files with floor label.\nappraise obj_user=_\n", 4096) = 673
> write(1, "# Integrity measure policy (http://sourceforge.net/p/linux-ima/wiki/Home/#measure-nothing-appraise-everything)\n# \n# Do not measure anything, but appraise everything\n#\n# PROC_SUPER_MAGIC\ndont_appraise fsmagic=0x9fa0\n# SYSFS_MAGIC\ndont_appraise fsmagic=0x62656572\n# DEBUGFS_MAGIC\ndont_appraise fsmagic=0x64626720\n# TMPFS_MAGIC\ndont_appraise fsmagic=0x01021994\n# RAMFS_MAGIC\ndont_appraise fsmagic=0x858458f6\n# DEVPTS_SUPER_MAGIC\ndont_appraise fsmagic=0x1cd1\n# BIFMT\ndont_appraise fsmagic=0x42494e4d\n# SECURITYFS_MAGIC\ndont_appraise fsmagic=0x73636673\n# SELINUXFS_MAGIC\ndont_appraise fsmagic=0xf97cff8c\n\n# Appraise all operations on files with floor label.\nappraise obj_user=_\n", 673) = -1 EINVAL (Invalid argument)
> brk(0) = 0xb77cd000
> brk(0xb77ee000) = 0xb77ee000
> write(2, "cat: write error: Invalid argument\n", 35cat: write error: Invalid argument
>
> This is on a 3.19.2 kernel.
>
> Writing each line one-by-one works:
>
> (set -e; while read i; do echo $i >&2; echo $i; done) </etc/ima/ima-policy-floor >/sys/kernel/security/ima/policy
>
> The shell loop writes to stderr and stdout on purpose. That way a broken
> policy rule can be identified, which is not the case when using cat.
>
> That works for me at the moment, but I am wondering how that'll effect
> policy loading via systemd. Is there anything in the policy that breaks
> the short write mechanism?
Commit 4dfb18922d5d "ima-setup: simplify" broke systemd IMA. Zbigniew
Jędrzejewski-Szmek partially reverted the change. For an explanation of
the bug, please refer to
https://bugzilla.redhat.com/show_bug.cgi?id=1226948 .
Mimi
> I tried with all comment and blank lines removed, but it still failed
> when using cat. Kernel messages in that case where:
>
> audit: type=1805 audit(1436532900.884:2): action="dont_appraise" fsmagic="0x9fa0" res=1
> IMA: policy update failed
> audit: type=1802 audit(1436532900.892:3): pid=187 uid=0 auid=4294967295 ses=4294967295 subj=System op="policy_update" cause="failed" comm="cat" res=0
>
> With the shell loop, I get:
>
> audit: type=1805 audit(1436532981.698:4): action="dont_appraise" fsmagic="0x9fa0" res=1
> audit: type=1805 audit(1436532981.701:5): action="dont_appraise" fsmagic="0x62656572" res=1
> audit: type=1805 audit(1436532981.709:6): action="dont_appraise" fsmagic="0x64626720" res=1
> audit: type=1805 audit(1436532981.711:7): action="dont_appraise" fsmagic="0x01021994" res=1
> audit: type=1805 audit(1436532981.716:8): action="dont_appraise" fsmagic="0x858458f6" res=1
> audit: type=1805 audit(1436532981.720:9): action="dont_appraise" fsmagic="0x1cd1" res=1
> audit: type=1805 audit(1436532981.725:10): action="dont_appraise" fsmagic="0x42494e4d" res=1
> audit: type=1805 audit(1436532981.729:11): action="dont_appraise" fsmagic="0x73636673" res=1
> audit: type=1805 audit(1436532981.734:12): action="dont_appraise" fsmagic="0xf97cff8c" res=1
> audit: type=1805 audit(1436532981.738:13): action="appraise" obj_user="_" res=1
> IMA: policy update completed
>
> ------------------------------------------------------------------------------
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> _______________________________________________
> Linux-ima-user mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-ima-user
|
|
From: Patrick O. <pat...@in...> - 2015-07-10 13:46:22
|
Hello! I have (at least) one file where verifying the signature created by evmctl ima_sign fails. ima-evm-utils is 0.9 (git rev 3d9bdc1de2, the current master). $ evmctl ima_sign privkey_ima.pem pam_securetty.so $ getfattr -d -m . pam_securetty.so getfattr: Removing leading '/' from absolute path names # file: tmp/pam_securetty.so security.ima=0sAwIC2C1O/QCAEQNetDHu9W+Zn5bpL+cC2BvdkJNs6GIkS5EmD75MXrk+K0e0GLZOmAqwLbe/jOnsnw00WbthqG5xo7Vop+yDGnNVlGU95YQ1KQEqC3OZILkF5gyY88AU/T3y6UGa5Vl1FEvUrp4aVOUmTwqO6Wm/bVtJnNilhxkvRItjVNcVgQ== $ evmctl ima_verify --key x509_ima.der pam_securetty.so RSA_public_decrypt() failed: -1 error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01 error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed The signature check done by the Linux kernel 3.19.2 also fails. The same operation works for other files; I have not done a full check to see which files work and which don't. The keys were generated using the scripts from https://wiki.tizen.org/wiki/Security:IntegrityMeasurement/Preparing_Tizen_image_protected_by_IMA/EVM and can also be found here: https://github.com/01org/meta-intel-iot-security/tree/master/meta-integrity/scripts The resulting keys are also in that repo: https://github.com/01org/meta-intel-iot-security/tree/master/meta-integrity/data/debug-keys The pam_securetty.so is not available online, so I am attaching it together with the keys, in case that someone has the time for trying to reproduce this. In the meantime, does anyone have a tip what I should look at to find and fix the problem? -- 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. |
|
From: Patrick O. <pat...@in...> - 2015-07-10 13:02:15
|
Hello!
Last time I looked at the IMA policy loading, I was baffled that the
kernel ABI explicitly says that each write must be exactly one rule,
while systemd used one write() for the entire policy file. At that time
I concluded that the latter happens to work because the kernel reports
shorts writes after each rule and systemd retries with the rest. That's
also how it worked for cat.
However, now I ran into a situation where cat does not work for a policy
which seems to be correct (attached):
strace -s 1000 cat /etc/ima/ima-policy-floor >/sys/kernel/security/ima/policy
...
open("/etc/ima/ima-policy-floor", O_RDONLY|O_LARGEFILE) = 3
sendfile64(1, 3, NULL, 16777216) = 2
sendfile64(1, 3, NULL, 16777216) = -1 EINVAL (Invalid argument)
read(3, "# Integrity measure policy (http://sourceforge.net/p/linux-ima/wiki/Home/#measure-nothing-appraise-everything)\n# \n# Do not measure anything, but appraise everything\n#\n# PROC_SUPER_MAGIC\ndont_appraise fsmagic=0x9fa0\n# SYSFS_MAGIC\ndont_appraise fsmagic=0x62656572\n# DEBUGFS_MAGIC\ndont_appraise fsmagic=0x64626720\n# TMPFS_MAGIC\ndont_appraise fsmagic=0x01021994\n# RAMFS_MAGIC\ndont_appraise fsmagic=0x858458f6\n# DEVPTS_SUPER_MAGIC\ndont_appraise fsmagic=0x1cd1\n# BIFMT\ndont_appraise fsmagic=0x42494e4d\n# SECURITYFS_MAGIC\ndont_appraise fsmagic=0x73636673\n# SELINUXFS_MAGIC\ndont_appraise fsmagic=0xf97cff8c\n\n# Appraise all operations on files with floor label.\nappraise obj_user=_\n", 4096) = 673
write(1, "# Integrity measure policy (http://sourceforge.net/p/linux-ima/wiki/Home/#measure-nothing-appraise-everything)\n# \n# Do not measure anything, but appraise everything\n#\n# PROC_SUPER_MAGIC\ndont_appraise fsmagic=0x9fa0\n# SYSFS_MAGIC\ndont_appraise fsmagic=0x62656572\n# DEBUGFS_MAGIC\ndont_appraise fsmagic=0x64626720\n# TMPFS_MAGIC\ndont_appraise fsmagic=0x01021994\n# RAMFS_MAGIC\ndont_appraise fsmagic=0x858458f6\n# DEVPTS_SUPER_MAGIC\ndont_appraise fsmagic=0x1cd1\n# BIFMT\ndont_appraise fsmagic=0x42494e4d\n# SECURITYFS_MAGIC\ndont_appraise fsmagic=0x73636673\n# SELINUXFS_MAGIC\ndont_appraise fsmagic=0xf97cff8c\n\n# Appraise all operations on files with floor label.\nappraise obj_user=_\n", 673) = -1 EINVAL (Invalid argument)
brk(0) = 0xb77cd000
brk(0xb77ee000) = 0xb77ee000
write(2, "cat: write error: Invalid argument\n", 35cat: write error: Invalid argument
This is on a 3.19.2 kernel.
Writing each line one-by-one works:
(set -e; while read i; do echo $i >&2; echo $i; done) </etc/ima/ima-policy-floor >/sys/kernel/security/ima/policy
The shell loop writes to stderr and stdout on purpose. That way a broken
policy rule can be identified, which is not the case when using cat.
That works for me at the moment, but I am wondering how that'll effect
policy loading via systemd. Is there anything in the policy that breaks
the short write mechanism?
I tried with all comment and blank lines removed, but it still failed
when using cat. Kernel messages in that case where:
audit: type=1805 audit(1436532900.884:2): action="dont_appraise" fsmagic="0x9fa0" res=1
IMA: policy update failed
audit: type=1802 audit(1436532900.892:3): pid=187 uid=0 auid=4294967295 ses=4294967295 subj=System op="policy_update" cause="failed" comm="cat" res=0
With the shell loop, I get:
audit: type=1805 audit(1436532981.698:4): action="dont_appraise" fsmagic="0x9fa0" res=1
audit: type=1805 audit(1436532981.701:5): action="dont_appraise" fsmagic="0x62656572" res=1
audit: type=1805 audit(1436532981.709:6): action="dont_appraise" fsmagic="0x64626720" res=1
audit: type=1805 audit(1436532981.711:7): action="dont_appraise" fsmagic="0x01021994" res=1
audit: type=1805 audit(1436532981.716:8): action="dont_appraise" fsmagic="0x858458f6" res=1
audit: type=1805 audit(1436532981.720:9): action="dont_appraise" fsmagic="0x1cd1" res=1
audit: type=1805 audit(1436532981.725:10): action="dont_appraise" fsmagic="0x42494e4d" res=1
audit: type=1805 audit(1436532981.729:11): action="dont_appraise" fsmagic="0x73636673" res=1
audit: type=1805 audit(1436532981.734:12): action="dont_appraise" fsmagic="0xf97cff8c" res=1
audit: type=1805 audit(1436532981.738:13): action="appraise" obj_user="_" res=1
IMA: policy update completed
--
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.
|
|
From: Mimi Z. <zo...@li...> - 2015-07-10 12:46:28
|
On Wed, 2015-07-08 at 17:46 +0000, Curtis Veit wrote: > Hi, > > I'm looking for help understanding an error (shown below). > > The "tasks" files created by systemd-logind that give the error are > shown by "file" to be "empty" and by "mimetype -b -M" to be "text/plain" > and ownership and perms are root:root 644. > > These seems to work most of the time but are occasionally created or > updated without hashes. If it fails it continues to fail afterward > even though it is creating new directories and files. > > Does anyone have suggestions for a proper fix? > > I wondered if this is a bug in systemd-logind (running ubuntu 14.04), > or if I missed a fsmagic number I should have included in the list of > "dont_measure" "dont_appraise" > or if I should somehow have the system ignore /proc and /sys if I > cannot find a solution? The builtin ima_tcb policy doesn't measure either procfs or sysfs. Mimi > Here are the errors in kern.log > > Jul 7 20:57:48 irms-25276 kernel: [ 56.330439] audit: type=1800 audit(1436302668.756:51): pid=981 uid=0 auid=4294967295 ses=4294967295 op="appraise_data" cause="missing-hash" comm="systemd-logind" name="/sys/fs/cgroup/systemd/user/1000.user/1.session/tasks" dev="cgroup" ino=21 res=0 > Jul 7 20:57:51 irms-25276 kernel: [ 59.313945] audit: type=1800 audit(1436302671.736:52): pid=981 uid=0 auid=4294967295 ses=4294967295 op="appraise_data" cause="missing-hash" comm="systemd-logind" name="/sys/fs/cgroup/systemd/user/1000.user/c1.session/tasks" dev="cgroup" ino=26 res=0 > Jul 7 21:02:23 irms-25276 kernel: [ 331.666603] audit: type=1800 audit(1436302943.733:53): pid=981 uid=0 auid=4294967295 ses=4294967295 op="appraise_data" cause="missing-hash" comm="systemd-logind" name="/sys/fs/cgroup/systemd/user/1000.user/tasks" dev="cgroup" ino=16 res=0 > > > Currently my "dont" list in policy is as follows: > > # Default Rules > dont_measure fsmagic=0x9fa0 > dont_appraise fsmagic=0x9fa0 > dont_measure fsmagic=0x62656572 > dont_appraise fsmagic=0x62656572 > dont_measure fsmagic=0x64626720 > dont_appraise fsmagic=0x64626720 > dont_measure fsmagic=0x01021994 > dont_appraise fsmagic=0x01021994 > dont_measure fsmagic=0x858458f6 > dont_appraise fsmagic=0x858458f6 > dont_measure fsmagic=0x73636673 > dont_appraise fsmagic=0x73636673 > > > Comments and suggestions are always appreciated. > > Best regards, > Curtis > > ------------------------------------------------------------------------------ > Don't Limit Your Business. Reach for the Cloud. > GigeNET's Cloud Solutions provide you with the tools and support that > you need to offload your IT needs and focus on growing your business. > Configured For All Businesses. Start Your Cloud Today. > https://www.gigenetcloud.com/ > _______________________________________________ Linux-ima-user mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linux-ima-user |
|
From: Curtis V. <cu...@vp...> - 2015-07-08 17:46:45
|
Hi, I'm looking for help understanding an error (shown below). The "tasks" files created by systemd-logind that give the error are shown by "file" to be "empty" and by "mimetype -b -M" to be "text/plain" and ownership and perms are root:root 644. These seems to work most of the time but are occasionally created or updated without hashes. If it fails it continues to fail afterward even though it is creating new directories and files. Does anyone have suggestions for a proper fix? I wondered if this is a bug in systemd-logind (running ubuntu 14.04), or if I missed a fsmagic number I should have included in the list of "dont_measure" "dont_appraise" or if I should somehow have the system ignore /proc and /sys if I cannot find a solution? Here are the errors in kern.log Jul 7 20:57:48 irms-25276 kernel: [ 56.330439] audit: type=1800 audit(1436302668.756:51): pid=981 uid=0 auid=4294967295 ses=4294967295 op="appraise_data" cause="missing-hash" comm="systemd-logind" name="/sys/fs/cgroup/systemd/user/1000.user/1.session/tasks" dev="cgroup" ino=21 res=0 Jul 7 20:57:51 irms-25276 kernel: [ 59.313945] audit: type=1800 audit(1436302671.736:52): pid=981 uid=0 auid=4294967295 ses=4294967295 op="appraise_data" cause="missing-hash" comm="systemd-logind" name="/sys/fs/cgroup/systemd/user/1000.user/c1.session/tasks" dev="cgroup" ino=26 res=0 Jul 7 21:02:23 irms-25276 kernel: [ 331.666603] audit: type=1800 audit(1436302943.733:53): pid=981 uid=0 auid=4294967295 ses=4294967295 op="appraise_data" cause="missing-hash" comm="systemd-logind" name="/sys/fs/cgroup/systemd/user/1000.user/tasks" dev="cgroup" ino=16 res=0 Currently my "dont" list in policy is as follows: # Default Rules dont_measure fsmagic=0x9fa0 dont_appraise fsmagic=0x9fa0 dont_measure fsmagic=0x62656572 dont_appraise fsmagic=0x62656572 dont_measure fsmagic=0x64626720 dont_appraise fsmagic=0x64626720 dont_measure fsmagic=0x01021994 dont_appraise fsmagic=0x01021994 dont_measure fsmagic=0x858458f6 dont_appraise fsmagic=0x858458f6 dont_measure fsmagic=0x73636673 dont_appraise fsmagic=0x73636673 Comments and suggestions are always appreciated. Best regards, Curtis |
|
From: Curtis V. <cu...@vp...> - 2015-06-22 21:26:17
|
I wondered (last week) if I had a problem with write policy. I actually had tried adding a number of more Specific write rules. But ripped them out when I still had some issues. Probably should have made Those rules more generic. In any case I'm adding lines for all groups that I have appraise policies for. ... Just tested it works perfectly. Thanks very much for your help. Regards, Curtis -----Original Message----- From: Mimi Zohar [mailto:zo...@li...] Sent: Monday, June 22, 2015 1:05 PM To: Curtis Veit Cc: lin...@li... Subject: Re: [Linux-ima-user] IMA (latest patches) do not allow creation of in policy files. On Mon, 2015-06-22 at 11:03 -0600, Curtis Veit wrote: > # Using groups instead of uid mainly for testing # gid functionality # > group root = 0 may want to go by owner or group? > # group shadow = 42 needed if above not by owner measure > func=FILE_CHECK mask=MAY_READ fgroup=0 appraise func=FILE_CHECK > mask=MAY_READ fgroup=0 The security.ima hash value is updated only if the file is in policy. You're policy doesn't inlcude files opened for write. appraise func=FILE_CHECK fgroup=0 Mimi |
|
From: Mimi Z. <zo...@li...> - 2015-06-22 19:05:32
|
On Mon, 2015-06-22 at 11:03 -0600, Curtis Veit wrote: > # Using groups instead of uid mainly for testing > # gid functionality > # group root = 0 may want to go by owner or group? > # group shadow = 42 needed if above not by owner > measure func=FILE_CHECK mask=MAY_READ fgroup=0 > appraise func=FILE_CHECK mask=MAY_READ fgroup=0 The security.ima hash value is updated only if the file is in policy. You're policy doesn't inlcude files opened for write. appraise func=FILE_CHECK fgroup=0 Mimi |
|
From: Curtis V. <cu...@vp...> - 2015-06-22 18:46:08
|
The kernel command line is set in both an efi bootloader and in the kernel itself so when using the bootloader I Get many arguments doubled... "ima_tcb ima_appraise_tcb biosdevname=0 net.ifnames=0 console=ttyS1,115200n8 usbcore.autosuspend=-1 rootflags-i_version \vmlinuz-4.0.3-040003-ima ro root=/dev/sda3 ima_tcb ima_appraise_tcb biosdevname=0 net.ifnames=0 console=ttyS1,115200n8 usbcore.autosuspend=-1 rootflags-i_version" Looks like I could have skipped adding the command line args that were built in. Should I try setting i_version at the beginning of the command line? Hopefully the sequence of commands and the resulting behavior from the email a few minutes ago is informative. Regards, Curtis > -----Original Message----- > From: Mimi Zohar [mailto:zo...@li...] ... > What is the boot command line (/proc/cmdline)? Remove "ima_appraise=fix" from the boot command line if present. > > Mimi |
|
From: Curtis V. <cu...@vp...> - 2015-06-22 18:28:52
|
>-----Original Message----- >From: Curtis Veit [mailto:ve...@vp...] >Sent: Monday, June 22, 2015 11:05 AM >To: Mimi Zohar >Cc: lin...@li... >Subject: Re: [Linux-ima-user] IMA (latest patches) do not allow creation of in policy files. > >Hi Mimi, > >We are seeing interesting behavior here. I have two things to share. >first a repeatable test case. (on our box - we are using IMA only (no evm) and second a slightly simplified version of >the policy we are using. > > A test case. Session log from a co-worker, note that touch does not cause the hash update until after a failed attempt at reading the file. (I am looking again at i_version as this looks related. but I am sure that it is enabled in /etc/fstab and on the kernel commant line for the root-fs. I'll try changing the kernel command line to set i_version first and see if that helps.) ... So - I've noticed that I can't 'touch' the shadow file and get the hash applied until something else tries to access the shadow-file & fail. Here's a log: root@17208:/etc/old# getfattr -d -e hex -m security ../shadow # file: ../shadow security.ima=0x0404d4c1f8ab533a9f082e72c0d139e2a8e6f456d8874c5db040fad6e77aa55b9998 <-----------------change password here in web application--------------> root@17208:/etc/old# getfattr -d -e hex -m security ../shadow root@17208:/etc/old# sync root@17208:/etc/old# getfattr -d -e hex -m security ../shadow root@17208:/etc/old# touch ../shadow root@17208:/etc/old# getfattr -d -e hex -m security ../shadow root@17208:/etc/old# cat ../shadow cat: ../shadow: Permission denied root@17208:/etc/old# getfattr -d -e hex -m security ../shadow root@17208:/etc/old# touch ../shadow root@17208:/etc/old# getfattr -d -e hex -m security ../shadow # file: ../shadow security.ima=0x04049cd46d47210254d1c7c6e03c0e9233cd37c43987a918463a9b7c0a2b12af2907 |
|
From: Mimi Z. <zo...@li...> - 2015-06-22 18:26:53
|
On Mon, 2015-06-22 at 11:03 -0600, Curtis Veit wrote: > Hi Mimi, > > We are seeing interesting behavior here. I have two things to share. > first a repeatable test case. (on our box - we are using IMA only (no evm) > and second a slightly simplified version of the policy we are using. > > A test case. > As root run either chpasswd or passwd to change a user password on the > ima machine. > view /etc/shadow > (we get permission denied.) > then > touch /etc/shadow > view /etc/shadow > now we can see the contents of shadow What is the boot command line (/proc/cmdline)? Remove "ima_appraise=fix" from the boot command line if present. Mimi |
|
From: Curtis V. <ve...@vp...> - 2015-06-22 17:04:19
|
Hi Mimi, We are seeing interesting behavior here. I have two things to share. first a repeatable test case. (on our box - we are using IMA only (no evm) and second a slightly simplified version of the policy we are using. A test case. As root run either chpasswd or passwd to change a user password on the ima machine. view /etc/shadow (we get permission denied.) then touch /etc/shadow view /etc/shadow now we can see the contents of shadow My policy follows: perhaps I am misusing IMA in some way. best regards, Curtis ------------------------------------------------------------------------- # Default Rules dont_measure fsmagic=0x9fa0 dont_appraise fsmagic=0x9fa0 dont_measure fsmagic=0x62656572 dont_appraise fsmagic=0x62656572 dont_measure fsmagic=0x64626720 dont_appraise fsmagic=0x64626720 dont_measure fsmagic=0x01021994 dont_appraise fsmagic=0x01021994 dont_measure fsmagic=0x858458f6 dont_appraise fsmagic=0x858458f6 dont_measure fsmagic=0x73636673 dont_appraise fsmagic=0x73636673 # # Special partition dont_measure fsuuid=a11234... dont_appraise fsuuid=a11243... # Special immutable group appraise appraise_type=imasig func=FILE_CHECK mask=MAY_READ fgroup=200 # this area allows hashed executables appraise func=FILE_MMAP mask=MAY_EXEC fsuuid=0761e0f1... appraise func=BPRM_CHECK mask=MAY_EXEC fsuuid=0761e0f1... # # All executables must be signed appraise appraise_type=imasig func=FILE_MMAP mask=MAY_EXEC appraise appraise_type=imasig func=BPRM_CHECK mask=MAY_EXEC # # Attempt to avoid log and cache file (etc) # This may belong above the previous appraise group # sda7=/tmp sda8=/var dont_measure fsuuid=ac010c7... this is /tmp dont_appraise fsuuid=ac010c7... dont_measure fsuuid=... this is /var dont_appraise fsuuid=... # Is there a better way to handle the text based log files # that linux creates? # Using groups instead of uid mainly for testing # gid functionality # group root = 0 may want to go by owner or group? # group shadow = 42 needed if above not by owner measure func=FILE_CHECK mask=MAY_READ fgroup=0 appraise func=FILE_CHECK mask=MAY_READ fgroup=0 measure func=FILE_CHECK mask=MAY_READ fgroup=42 appraise func=FILE_CHECK mask=MAY_READ fgroup=42 # # non-root group to protect with hashes = 201 # also protect www-data group = 33 measure func=FILE_CHECK mask=MAY_READ fgroup=33 appraise func=FILE_CHECK mask=MAY_READ fgroup=33 measure func=FILE_CHECK mask=MAY_READ fgroup=201 appraise func=FILE_CHECK mask=MAY_READ fgroup=201 # # remaining default rules measure func=BPRM_CHECK measure func=MODULE_CHECK measure func=FIRMWARE_CHECK On Mon, Jun 22, 2015 at 11:03:19AM -0400, Mimi Zohar wrote: > On Mon, 2015-06-22 at 13:59 +0000, Curtis Veit wrote: > > So what method may be used to create a new file with a valid hash? > > Seems like there are valid use cases for this. > > New files are always hashed as long as they're in policy. Try creating > a test file and getting the security xattr values and the sha256sum of > the file. > > $ sudo sh -c "echo 'Hello World' > /etc/hello" > > $ getfattr -m ^security --dump -e hex /etc/hello > getfattr: Removing leading '/' from absolute path names > # file: etc/hello > security.evm=0x02736807ac58a250f017de2d3fdd45e63db4270c73 > security.ima=0x0404d2a84f4b8b650937ec8f73cd8be2c74add5a911ba64df27458ed8229da804a26 > security.selinux=0x756e636f6e66696e65645f753a6f626a6563745f723a6574635f743a733000 > > $ sha256sum /etc/hello > d2a84f4b8b650937ec8f73cd8be2c74add5a911ba64df27458ed8229da804a26 /etc/hello > > If you're still having problems, then post the results here with your > appraisal policy. > > Mimi > > > ------------------------------------------------------------------------------ > Monitor 25 network devices or servers for free with OpManager! > OpManager is web-based network management software that monitors > network devices and physical & virtual servers, alerts via email & sms > for fault. Monitor 25 devices for free with no restriction. Download now > http://ad.doubleclick.net/ddm/clk/292181274;119417398;o > _______________________________________________ > Linux-ima-user mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-ima-user |
|
From: Mimi Z. <zo...@li...> - 2015-06-22 15:04:14
|
On Mon, 2015-06-22 at 13:59 +0000, Curtis Veit wrote: > So what method may be used to create a new file with a valid hash? > Seems like there are valid use cases for this. New files are always hashed as long as they're in policy. Try creating a test file and getting the security xattr values and the sha256sum of the file. $ sudo sh -c "echo 'Hello World' > /etc/hello" $ getfattr -m ^security --dump -e hex /etc/hello getfattr: Removing leading '/' from absolute path names # file: etc/hello security.evm=0x02736807ac58a250f017de2d3fdd45e63db4270c73 security.ima=0x0404d2a84f4b8b650937ec8f73cd8be2c74add5a911ba64df27458ed8229da804a26 security.selinux=0x756e636f6e66696e65645f753a6f626a6563745f723a6574635f743a733000 $ sha256sum /etc/hello d2a84f4b8b650937ec8f73cd8be2c74add5a911ba64df27458ed8229da804a26 /etc/hello If you're still having problems, then post the results here with your appraisal policy. Mimi |
|
From: Curtis V. <cu...@vp...> - 2015-06-22 13:59:09
|
So what method may be used to create a new file with a valid hash? Seems like there are valid use cases for this. -----Original Message----- From: Mimi Zohar [mailto:zo...@li...] Sent: Monday, June 22, 2015 7:47 AM To: Curtis Veit Cc: lin...@li... Subject: Re: [Linux-ima-user] IMA (latest patches) do not allow creation of in policy files. On Fri, 2015-06-19 at 17:10 -0600, Curtis Veit wrote: > Background: > I have taken the latest IMA patches from linux integrity and applied > them to a 4.0.3 kernel source and built. ( also includes mu gid patch) > Things seem to work pretty much as expected: > - cannot write the ima hash from user space > - more methods of writing files (that are already "in policy") do > seem to update hashes on file close. (Some of the previous strange > behavior I noticed is gone - probably related to the rw patch This change affects the ima measurement policy, not the appraisal policy. > Mimi mentioned. > works: vim, emacs, cat >> foo > So this is good progress... > > > The Problem: > But I cannot seem to figure out how to create a usable file that is > owned by root. This may or may not be related to some specific > examples of failure: Lets take this one step at a time. > cannot change passwords ( only tested as root) > shadow hash does not get updated and becomes unreadable. > df does not work. It cannot read the table that it tries > to access. > emacs newfile.txt # creates an unreadable file > vim newfile2.txt # ditto > cat "Hello World" > newfile3.txt # ditto Instead of 'cat' try 'echo'. If the file is in policy, then the file should have a security.ima xattr. Once it is labeled with a valid hash, any modifications to the file should result in the hash being updated. In each of the cases above, after creating the file, check to see if the security.ima xattr was created. Compare the xattr against the result of shaXXXsum <fn>. reminder: If the xattr was not created, then it was not in policy. > I suspect that the failure with passwd and df are related to the new > file creation issue. But I'm not sure if their implementations are > essentially making a new file. Only files in policy that already have valid security.ima xattrs can be modified. Mimi |
|
From: Mimi Z. <zo...@li...> - 2015-06-22 13:47:12
|
On Fri, 2015-06-19 at 17:10 -0600, Curtis Veit wrote: > Background: > I have taken the latest IMA patches from linux integrity and applied > them to a 4.0.3 kernel source and built. ( also includes mu gid patch) > Things seem to work pretty much as expected: > - cannot write the ima hash from user space > - more methods of writing files (that are already "in policy") do > seem to update hashes on file close. (Some of the previous strange > behavior I noticed is gone - probably related to the rw patch This change affects the ima measurement policy, not the appraisal policy. > Mimi mentioned. > works: vim, emacs, cat >> foo > So this is good progress... > > > The Problem: > But I cannot seem to figure out how to create a usable file that > is owned by root. This may or may not be related to some specific > examples of failure: Lets take this one step at a time. > cannot change passwords ( only tested as root) > shadow hash does not get updated and becomes unreadable. > df does not work. It cannot read the table that it tries > to access. > emacs newfile.txt # creates an unreadable file > vim newfile2.txt # ditto > cat "Hello World" > newfile3.txt # ditto Instead of 'cat' try 'echo'. If the file is in policy, then the file should have a security.ima xattr. Once it is labeled with a valid hash, any modifications to the file should result in the hash being updated. In each of the cases above, after creating the file, check to see if the security.ima xattr was created. Compare the xattr against the result of shaXXXsum <fn>. reminder: If the xattr was not created, then it was not in policy. > I suspect that the failure with passwd and df are related > to the new file creation issue. But I'm not sure if their > implementations are essentially making a new file. Only files in policy that already have valid security.ima xattrs can be modified. Mimi |
|
From: Curtis V. <ve...@vp...> - 2015-06-19 23:10:49
|
Background:
I have taken the latest IMA patches from linux integrity and applied
them to a 4.0.3 kernel source and built. ( also includes mu gid patch)
Things seem to work pretty much as expected:
- cannot write the ima hash from user space
- more methods of writing files (that are already "in policy") do
seem to update hashes on file close. (Some of the previous strange
behavior I noticed is gone - probably related to the rw patch
Mimi mentioned.
works: vim, emacs, cat >> foo
So this is good progress...
The Problem:
But I cannot seem to figure out how to create a usable file that
is owned by root. This may or may not be related to some specific
examples of failure:
cannot change passwords ( only tested as root)
shadow hash does not get updated and becomes unreadable.
df does not work. It cannot read the table that it tries
to access.
emacs newfile.txt # creates an unreadable file
vim newfile2.txt # ditto
cat "Hello World" > newfile3.txt # ditto
I suspect that the failure with passwd and df are related
to the new file creation issue. But I'm not sure if their
implementations are essentially making a new file.
Looking for help:
I've looked some at the IMA code to see if I can spot a
fix but thought that it would be wise to get input from
all of you...
I am not familiar enough with the IMA kernel code to
find and fix without some guidance. (Also I would not mind
if someone else fixed it ;-)
Also it is very possible that I have made other mistakes in
the use of IMA. (will post an example policy for comments)
Best regards,
Curtis
|
|
From: Curtis V. <cu...@vp...> - 2015-06-16 17:13:31
|
That is a great help. The odd behavior I've been seeing seems to be associated with using tar. Tar with --xattrs will correctly collect all the security xattrs but restoring the xattrs Is almost always broken. Sometime depending on the policy and ima defaults I get different hashes or no hashes. It will not ever restore a signature. I'll focus on using other tools and let you know if I see anything else that is unexpected. Regards, Curtis -----Original Message----- From: Mimi Zohar [mailto:zo...@li...] Sent: Tuesday, June 16, 2015 10:34 AM To: Curtis Veit Cc: lin...@li... Subject: Re: [Linux-ima-user] Looking for definition of ima behavior "importing" signatures and hashes. On Tue, 2015-06-16 at 13:57 +0000, Curtis Veit wrote: > I've mentioned seeing odd behavior copying hashes and signatures using rsync and tar. > Is there documentation anywhere describing the expected behavior? > > A couple examples. I just switched kernels from my own with ima-sig and hashes=sha256 built in to a standard > Ubuntu kernel and now all hashes and signatures get changes automatically to sha1. I guess this should be expected but was a surprise in a way. (Apparently Ubuntu is shipping a kernel that defaults to sha1) > > Things that seem to affect the behavior creating the hash or signature. > > IMA kernel Mode: ima ima-ng or ima-sig IMA hash default: sha1 sha256, > sha512 (Can anyone tell me what the kernel command line arguments are > for these two items?) The "ima_hash=" specifies the default hash algorithm used in the IMA measurement list. In order to prevent hashing the file once for the measurement list and again for appraisal, the same hash algorithm is used for both. The hash algorithm in the xattr will also appear in the measurement list. > IMA can also be in a state where the xattrs are simply dropped when the copy is done. > (Can anyone point me to an explanation of conditions that must be met > for the xattr to be retained?) When using 'cp', specify "--preserve=xattrs" to copy the security xattrs. > This may be related to the policy that is currently in force. And > seems to work when in either fix or Enforcing mode. True, but "fix" mode should only be used for initial labeling of the filesystem. After that, on file close, if the file has been modified and is in policy, the file hash will be updated. To detect file modification, the file system needs to be mounted with iversion. > There are times I think I should be in enforcing mode but hashes are > dropped. I am not certain if it is because I am not actually in enforcing mode or because the policy I loaded is bad. > Is there a definition for how policy settings affect the restoration > of IMA xattrs when copying with tar or rsync? I haven't looked at rsync. As for tar, I opened a bug March 2014, but never heard back - http://lists.gnu.org/archive/html/bug-tar/2014-03/msg00029.html. I haven't tried this patch recently. Mimi > Any help on this would be profoundly appreciated! (pointer to docs > and/or the place the code implements the behavior or specific explanations would be very helpful.) |
|
From: Mimi Z. <zo...@li...> - 2015-06-16 16:34:28
|
On Tue, 2015-06-16 at 13:57 +0000, Curtis Veit wrote: > I've mentioned seeing odd behavior copying hashes and signatures using rsync and tar. > Is there documentation anywhere describing the expected behavior? > > A couple examples. I just switched kernels from my own with ima-sig and hashes=sha256 built in to a standard > Ubuntu kernel and now all hashes and signatures get changes automatically to sha1. I guess this should be expected but was a surprise in a way. (Apparently Ubuntu is shipping a kernel that defaults to sha1) > > Things that seem to affect the behavior creating the hash or signature. > > IMA kernel Mode: ima ima-ng or ima-sig > IMA hash default: sha1 sha256, sha512 > (Can anyone tell me what the kernel command line arguments are for these two items?) The "ima_hash=" specifies the default hash algorithm used in the IMA measurement list. In order to prevent hashing the file once for the measurement list and again for appraisal, the same hash algorithm is used for both. The hash algorithm in the xattr will also appear in the measurement list. > IMA can also be in a state where the xattrs are simply dropped when the copy is done. > (Can anyone point me to an explanation of conditions that must be met for the xattr to be retained?) When using 'cp', specify "--preserve=xattrs" to copy the security xattrs. > This may be related to the policy that is currently in force. And seems to work when in either fix or > Enforcing mode. True, but "fix" mode should only be used for initial labeling of the filesystem. After that, on file close, if the file has been modified and is in policy, the file hash will be updated. To detect file modification, the file system needs to be mounted with iversion. > There are times I think I should be in enforcing mode but hashes are dropped. I am not certain > if it is because I am not actually in enforcing mode or because the policy I loaded is bad. > Is there a definition for how policy settings affect the restoration > of IMA xattrs when copying with tar or rsync? I haven't looked at rsync. As for tar, I opened a bug March 2014, but never heard back - http://lists.gnu.org/archive/html/bug-tar/2014-03/msg00029.html. I haven't tried this patch recently. Mimi > Any help on this would be profoundly appreciated! (pointer to docs and/or the place the code implements the behavior or specific explanations would be very helpful.) |
|
From: Curtis V. <cu...@vp...> - 2015-06-16 14:14:20
|
Somehow I skipped past the answer to one question last night when I looked at the wiki...
>From: Curtis Veit
>Sent: Tuesday, June 16, 2015 7:58 AM
>To: 'lin...@li...'
>Subject: Looking for definition of ima behavior "importing" signatures and hashes.
>
> I've mentioned seeing odd behavior copying hashes and signatures using rsync and tar.
>Is there documentation anywhere describing the expected behavior?
>
>A couple examples. I just switched kernels from my own with ima-sig and hashes=sha256 built in to a standard
>Ubuntu kernel and now all hashes and signatures get changes automatically to sha1. I guess this should be expected >but was a surprise in a way. (Apparently Ubuntu is shipping a kernel that defaults to sha1)
>
>Things that seem to affect the behavior creating the hash or signature.
>
>IMA kernel Mode: ima ima-ng or ima-sig
>IMA hash default: sha1 sha256, sha512
>(Can anyone tell me what the kernel command line arguments are for these two items?)
>From the wiki: Controlling IMA
ima_template= template used
Format: { "ima" | "ima-ng" | "ima-sig" }
NEW Linux 3.13 default: "ima-ng"
ima_hash= hash used
Format: { "sha1" | "md5" | "sha256" | "sha512" | "wp512" | ... }
'ima' template default: "sha1"
NEW Linux 3.13 default: "sha256"
Note that Ubuntu kernels seem to be using sha1 as the default on kernels after 3.13
>
>IMA can also be in a state where the xattrs are simply dropped when the copy is done.
>(Can anyone point me to an explanation of conditions that must be met for the xattr to be retained?)
>This may be related to the policy that is currently in force. And seems to work when in either fix or
>Enforcing mode.
>There are times I think I should be in enforcing mode but hashes are dropped. I am not certain
>if it is because I am not actually in enforcing mode or because the policy I loaded is bad.
>Is there a definition for how policy settings affect the restoration of IMA xattrs when copying
>with tar or rsync?
>
>Any help on this would be profoundly appreciated! (pointer to docs and/or the place the code implements the >behavior or specific explanations would be very helpful.)
>
>Best regards,
>Curtis
|
|
From: Curtis V. <cu...@vp...> - 2015-06-16 13:58:05
|
I've mentioned seeing odd behavior copying hashes and signatures using rsync and tar. Is there documentation anywhere describing the expected behavior? A couple examples. I just switched kernels from my own with ima-sig and hashes=sha256 built in to a standard Ubuntu kernel and now all hashes and signatures get changes automatically to sha1. I guess this should be expected but was a surprise in a way. (Apparently Ubuntu is shipping a kernel that defaults to sha1) Things that seem to affect the behavior creating the hash or signature. IMA kernel Mode: ima ima-ng or ima-sig IMA hash default: sha1 sha256, sha512 (Can anyone tell me what the kernel command line arguments are for these two items?) IMA can also be in a state where the xattrs are simply dropped when the copy is done. (Can anyone point me to an explanation of conditions that must be met for the xattr to be retained?) This may be related to the policy that is currently in force. And seems to work when in either fix or Enforcing mode. There are times I think I should be in enforcing mode but hashes are dropped. I am not certain if it is because I am not actually in enforcing mode or because the policy I loaded is bad. Is there a definition for how policy settings affect the restoration of IMA xattrs when copying with tar or rsync? Any help on this would be profoundly appreciated! (pointer to docs and/or the place the code implements the behavior or specific explanations would be very helpful.) Best regards, Curtis |
|
From: Curtis V. <cr...@so...> - 2015-06-12 01:09:17
|
On Thu, Jun 11, 2015 at 09:34:29PM +0300, Petko Manolov wrote: > On 15-06-11 20:46:48, Petko Manolov wrote: > > 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. > > > > > 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. > > appraise func=FILE_CHECK mask=MAY_READ uid=1001 > > Unless i've done something stupid the above rule (signed 'busybox', unsigned > 'foo.sh') did the trick: > > # ./busybox-signed sh foo.sh > > ends up with: > > sh: can't open 'foo.sh' > > and the audit message: > > [ 807.094071] audit: type=1800 audit(1434047224.585:23): pid=1498 uid=1001 auid=4294967295 ses=4294967295 op="appraise_data" cause="missing-hash" comm="busybox-signed" name="/home/user/foo.sh" dev="sda1" ino=42 res=0 Hi Petko, That could be exactly what I did. Unfortunatly it was in January so the memory has faded. I was pretty much only testing for ways to avoid executing anything but signed files. Unfortunately this is not quite the final solution I'm looking for but does get me back on the right path. Thanks very much for taking time to share your experience. I'm finding that I still have much to learn to use IMA. Seems like there might be a linux capability that could be used to allow/reject executing a script in that way. I need to learn more about using LSM features with IMA and see if that would tie in to capabilities as well. THis might mean that a little new code is needed... Best regards, Curtis |
|
From: Petko M. <pe...@mi...> - 2015-06-11 18:34:40
|
On 15-06-11 20:46:48, Petko Manolov wrote: > 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. appraise func=FILE_CHECK mask=MAY_READ uid=1001 Unless i've done something stupid the above rule (signed 'busybox', unsigned 'foo.sh') did the trick: # ./busybox-signed sh foo.sh ends up with: sh: can't open 'foo.sh' and the audit message: [ 807.094071] audit: type=1800 audit(1434047224.585:23): pid=1498 uid=1001 auid=4294967295 ses=4294967295 op="appraise_data" cause="missing-hash" comm="busybox-signed" name="/home/user/foo.sh" dev="sda1" ino=42 res=0 |
32 messages has been excluded from this view by a project administrator.
