|
From: Mimi Z. <zo...@li...> - 2016-12-28 20:18:35
|
On Wed, 2016-12-28 at 21:08 +0300, Mikhail Kurinnoi wrote: > В Wed, 28 Dec 2016 09:24:36 -0500 > Mimi Zohar <zo...@li...> пишет: > > > On Wed, 2016-12-28 at 15:51 +0300, Mikhail Kurinnoi wrote: > > > Removed from kernel boot command line "ima_appraise=fix evm=fix", I > > > faced with a little bit strange audit log output. For example: > > > ... > > > pid=3237 uid=0 auid=4294967295 ses=4294967295 op="appraise_metadata" > > > cause="fail" comm="cp" name="depconfig" fowner=0 dev="tmpfs" > > > ino=6839 res=0 > > > pid=4418 uid=0 auid=4294967295 ses=4294967295 op="appraise_metadata" > > > cause="fail" comm="chgrp" name="utmp" fowner=0 dev="tmpfs" ino=11295 > > > res=0 > > > pid=4419 uid=0 auid=4294967295 ses=4294967295 op="appraise_metadata" > > > cause="fail" comm="chmod" name="utmp" fowner=0 dev="tmpfs" ino=11295 > > > res=0 > > > pid=5040 uid=0 auid=4294967295 ses=4294967295 op="appraise_metadata" > > > cause="fail" comm="cupsd" name="0" fowner=0 dev="tmpfs" ino=10778 > > > res=0 > > > pid=5611 uid=1000 auid=1000 ses=3 op="appraise_metadata" > > > cause="fail" comm="X" name=".tX0-lock" fowner=0 dev="tmpfs" > > > ino=11650 res=0 ... > > > > > > This output were logged with default policy (ima_appraise_tcb > > > ima_tcb). As you can see (op="appraise_metadata"), this issue > > > connected to evm_inode_setattr(), evm_inode_removexattr() and > > > evm_inode_setxattr(). After some digging I found, that we don't > > > count on getxattr() support in inode. I mean, we don't count on > > > EOPNOTSUPP error code from evm_find_protected_xattrs(), as result, > > > evm_verify_hmac() will return only INTEGRITY_FAIL error and > > > legitimate attr/xattr(acls) changes will be not allowed by EVM. > > > > Before EVM allows a file to write file metadata it validates the > > existing security.evm xattr. Only if it is valid, does EVM permit the > > file metadata to change. Otherwise the updated security.evm xattr > > would be based on bogus file metadata. Is the issue really that > > getxattr() isn't supported or rather that these files were created > > under a different policy, which didn't label the files properly? > > As I mentioned, I also test with default policy this time from the beginning > to be sure this is not my policy issue again. For tmpfs in default > policy we have only 2 lines with "dont_appraise" + "dont_measure" connected > to magic number, and this is upper lines. My custom policy have same upper > lines with magic numbers. > > Tmpfs support xattrs for sure, I tested this. > Also, I add test ext4 FS partition with "dont_appraise" + "dont_measure" > rules as upper lines of policy file. Result was the same. > evm_find_protected_xattrs() return EOPNOTSUPP if I create > new file and use chmod on it. If I change test ext4 FS partition policy > to "appraise" I have no issues. So, this is not tmpfs or xattrs > support issue. It sounds like the file does not have the security.evm xattr before you do the chmod. Therefore it is failing. Please show the test steps with the security xattrs after each step. thanks, Mimi > I just can add, that in evm_find_protected_xattrs() error message > EOPNOTSUPP returned not by inode->i_op->getxattr test, but by > inode->i_op->getxattr() execution itself. > |