Re: [Linux-ima-user] File measurements not always stored or security.ima disappearing

[Sven V. <sve...@si...>]

On Sun, Dec 30, 2012 at 06:58:02PM -0500, Mimi Zohar wrote:
> To summarize, basically evmctl labels the filesystem properly, but
> opening existing files or creating new ones, in fix mode, doesn't result
> in proper labeling of files.  Try experimenting with root owned files.

Aha, thanks, you put me in the good direction here.

I have another example here, namely the SELinux binary policy file and other
SELinux related files. For some strange reason, it doesn't get measured at
run-time, but it does get appraised at boot time. So when I rebuild my
SELinux policy, I cannot use it anymore after a reboot.

#v+
test policy # getfattr -m . -d policy.27 
# file: policy.27
security.evm=0sAud8wjn2az5ZxEvssgVggxc7YXTR
security.ima=0sAXgvCp+B5kwkMiKCyhq/nH5v8RmM
security.selinux="root:object_r:policy_config_t"

test policy # stat policy.27 
  File: 'policy.27'
  Size: 396067          Blocks: 784        IO Block: 4096   regular file
Device: fb02h/64258d    Inode: 394414      Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Context: root:object_r:policy_config_t
Access: 2012-12-31 21:05:48.421000000 +0100
Modify: 2012-12-31 21:05:48.426000000 +0100
Change: 2012-12-31 21:05:48.427000000 +0100
 Birth: -
#v-

All is good here, so let's update the policy by setting a boolean

#v+
test policy # setsebool -P allow_ptrace on
test policy # stat policy.27 
  File: 'policy.27'
  Size: 396067          Blocks: 784        IO Block: 4096   regular file
Device: fb02h/64258d    Inode: 394411      Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Context: root:object_r:policy_config_t
Access: 2012-12-31 21:06:46.095000000 +0100
Modify: 2012-12-31 21:06:46.099000000 +0100
Change: 2012-12-31 21:06:46.099000000 +0100
 Birth: -
test policy # getfattr -m . -d policy.27 
# file: policy.27
security.evm=0sAsDOnzpOajlpHXmTwtnJ+TRW3GEd
security.selinux="root:object_r:policy_config_t"
#v-

So the policy file has changed, and I lost my IMA hash.

I looked at the IMA policy, and it has the following:

#v+
# SELINUX_MAGIC = 0xf97cff8c
dont_measure fsmagic=0xf97cff8c
dont_appraise fsmagic=0xf97cff8c
#v-

Sure enough, the magic of the policy file tells that it is a SELinux file.

#v+
test policy # hexdump -C -n 4 policy.27 
00000000  8c ff 7c f9                                       |..|.|
00000004
#v-

But when I reboot in enforcing mode:

#v+
[    1.451568] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input2
[    1.507756] Key type trusted registered
[    1.558805] Key type encrypted registered
[    1.601568] IMA: No TPM chip found, activating TPM-bypass!
[    1.605922] ALSA device list:
[    1.608111]   No soundcards found.
[    1.612545] Freeing unused kernel memory: 744k freed
[    4.864195] type=1800 audit(1356985118.864:2): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel op="appraise_data" cause="missing-hash" comm="init" name="/etc/selinux/strict/policy/policy.27" dev="dm-2" ino=394411 res=0
#v-

I first thought that my own policy was different from the default one (since
I load my IMA policy after the SELinux policy is loaded), but in the Linux
kernel's security/integrity/ima/ima_policy.c I notice the following two
entries:

#v+
static struct ima_rule_entry default_rules[] = {
...
        {.action = DONT_MEASURE,.fsmagic = SELINUX_MAGIC,.flags = IMA_FSMAGIC},

static struct ima_rule_entry default_appraise_rules[] = {
...
        {.action = DONT_APPRAISE,.fsmagic = SELINUX_MAGIC,.flags = IMA_FSMAGIC},
#v-

And now that I'm testing more, I notice that even my default context files
have this weird non-measured problem:

#v+
test files # getfattr -m . -d file_contexts
# file: file_contexts
security.evm=0sAvuVjeRJJGraNaldIrBmOdQ8SSgN
security.ima=0sAQcbZOYamvOUVurJWQC/V/ll8T3j
security.selinux="system_u:object_r:file_context_t"

test files # setsebool -P allow_ptrace off
test files # getfattr -m . -d file_contexts
# file: file_contexts
security.evm=0sAjzJy9PAYHuE/tnA8joO2DuI0vI4
security.selinux="root:object_r:file_context_t"
#v-

And these definitely don't have a magic for SELinux, and they are
root-owned.

Note that I also have another problem with SELinux and IMA combined [1]
which I first thought was less related to this, but it is too much of a
coincidence: the moment I rebuild/reload my policy, I get
"selinux_audit_rule_match: stale rule" and no further information on SELinux
AVCs.

[1] http://marc.info/?l=selinux&m=135686169925172&w=2

Wkr,
	Sven Vermeulen