Re: [Linux-ima-user] IMA policy loading via cat

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

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.