|
From: Patrick O. <pat...@in...> - 2016-11-15 09:51:47
|
On Tue, 2016-11-15 at 08:54 +0000, Kiviluoto, Jaakko J wrote: > I currently have IMA functioning on a Yocto based build (kernel 4.8.3) with overlayfs root filesystem as follows: So you managed to get key loading working? Good :-) > - lowerdir = loop-mounted read-only squashfs with IMA signatures set build time > - upperdir = directory on sync,noexec mounted ext4 partition for writing persistent configs etc. > - workdir on same partition as upperdir > > Observations (as root user): > - I cannot edit executables, e.g. /etc/init.d/networking - "Permission denied" as expected > - I can erase (whiteout) executables > - I can create my own (malicious) executable script, and copy it on top of an IMA-signed system binary, and execute it > - "noexec" mount option doesn't seem to have any effect > > I get the same results with both of these two policies: > https://github.com/01org/meta-intel-iot-security/blob/master/meta-integrity/data/ima_policy_appraise_all > https://github.com/01org/meta-intel-iot-security/blob/master/meta-integrity/data/ima_policy_hashed > > I realize there may be more overlayfs issues than IMA, but is this behavior what others would expect? > Can't I somehow tell IMA to strictly enforce the original signature instead of coming up with a new one for replaced files? We are getting the behavior that you describe (an unmodifiable, signed file can be replaced with a locally created, hashed file) on Ostro OS because we had to allow mixing writable files and read-only files in the same partition. It's a known loophole in that (incomplete) proof-of-concept setup. Ostro OS uses a slightly different policy (https://github.com/ostroproject/ostro-os/blob/master/meta-ostro/recipes-image/images/files/ima_policy_ostro) but the basic principle is the same. You could try with "appraise appraise_type=imasig" instead of just "appraise". I don't know how well that'll work with the overlayfs. > Or am I better off seeking alternative to overlayfs setup? I think it would indeed be better to separate writable and read-only parts of your file tree differently, for example by mounting a partition for read/write access (could be under /var) and then making sure that all modifiable data ends up there. -- 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. |