From: Patrick O. <pat...@in...> - 2015-05-26 15:18:37
|
On Fri, 2015-05-22 at 12:24 -0400, Mimi Zohar wrote: > On Fri, 2015-05-22 at 15:50 +0200, Patrick Ohly wrote: > > On Fri, 2015-05-22 at 09:22 -0400, Mimi Zohar wrote: > > > On Fri, 2015-05-22 at 13:47 +0200, Patrick Ohly wrote: > > > > systemd policy loading is broken and (IMHO) always has been. The commit > > > > mentioned in the SF Wiki is called "systemd commit c8161158" but the > > > > actual commit hash is 8161158 (no leading c). That made finding the > > > > commit [5] a bit harder. That commit seems broken to me because it > > > > submits the entire policy with a single write() call, whereas the kernel > > > > API is "one policy per write()". A later modification [6] just made the > > > > situation worse by switching to copy_bytes(), which uses more complex > > > > system calls and does not manage to write all data. > > > > > > The change was added in order to be able to 'cat' the policy. Either > > > method should work. > > > > With both methods, do you mean dracut and systemd, or do you mean > > writing a single rule and all at once? > > > > https://www.kernel.org/doc/Documentation/ABI/testing/ima_policy > > quite clearly says that updates are done by "writing the rules one at a > > time" and that matches the code. But that's not what the systemd code > > does (and never has, at least the way it was included in upstream > > systemd), so I just don't see how it can work. > > > > It's hard to believe that it was submitted and merged without testing > > and hasn't been used since, but that's really the only explanation that > > I have at the moment (ignoring technical misunderstandings on my side, > > which of course is possible). > > Both dracut and systemd versions load the policy properly, have been > tested and used for years. dracut cat's the file to the securityfs > file, while systemd call copy_bytes() to copy the file data to the > securityfs file. I need to come back to this. After checking the content of my policy and ensuring that cat'ing it into /sys/kernel/security/ima/policy works fine, I went back to getting it loaded via systemd. That still failed. My original observation from additional debug output in systemd was that writing the entire file fails in copy_bytes() after the first line (hence all my questions about how writing more than one rule can work). I've double-checked that observation, using a simple two-line policy file and a patched systemd 2.19 (both attached). The console output during booting: systemd[1]: sendfile(16384) wrote 29 systemd[1]: sendfile(16384) failed: Invalid argument systemd[1]: fallback loop_write(dont_appraise fsmagic=0x62656572 systemd[1]: , 33) systemd[1]: write(dont_appraise fsmagic=0x62656572 systemd[1]: , 33) systemd[1]: write() failed: Invalid argument systemd[1]: fallback loop_write() failed: Invalid argument systemd[1]: Failed to load the IMA custom policy file /etc/ima/ima-policy: Invalid argument IMA: policy update failed What that means is that copy_bytes() writes the first line (29 bytes), fails to write the second line, falls back to loop_write() with data of that second line, and that also fails. After reverting the following two commits in systemd, IMA policy loading works again for me: commit 7430ec6ac08f2c0416d9f806964c46b30f3862b2 Author: Lennart Poettering <le...@po...> Date: Fri Dec 12 16:24:33 2014 +0100 copy: use btrfs reflinking only whe we know we copy full files commit 4dfb18922d5d1efb13ee459cbf23832277f85ed7 Author: Zbigniew Jędrzejewski-Szmek <zb...@in...> Date: Mon Dec 1 20:47:37 2014 -0500 ima-setup: simplify So to me that looks like a regression in systemd, and your earlier comments about it having worked in systemd for years must have been about systemd older than 2.18. I do not fully understand why it fails (perhaps something related to the way how sendfile() is implemented in the kernel), but that's for wiser man than me to figure out ;-} -- 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. |