Re: [Linux-ima-user] Overriding executables with overlayfs

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

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.