[Linux-ima-user] copying files with security.ima xattr

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

Hello!

I just noticed some unexpected behavior. Kernel is 4.4.11, with IMA
enabled in the build configuration.

After booting, copying files which have a hash in security.ima (like
0x0196d920f04ec85c33438117740d5dcae7bbdbfe3a) with rsync or bsdtar fails
in fsetxattr with permission denied. From bsdtar:

open("build", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE|O_CLOEXEC, 0644) = 3
fcntl64(3, F_GETFD)                     = 0x1 (flags FD_CLOEXEC)
write(3, "-----------------------\nBuild Co"..., 2022) = 2022
...
fchown32(3, 0, 0)                       = 0
utimensat(3, NULL, [{1467894919, 0}, {1467894885, 0}], 0) = 0
fsetxattr(3, "security.SMACK64", "System::Shared", 14, 0) = 0
fsetxattr(3, "security.ima", "\1\226\331 \360N\310\\3C\201\27t\r]\312\347\273\333\376:", 21, 0) = -1 EPERM (Operation not permitted)
close(3)                                = 0

It does not matter whether an IMA policy has been loaded or not.

fsetxattr() succeeds if the security.ima value is a signed hash.

We ran into this while working on an installer which runs from the
initramfs and copies the content of the rootfs from an USB stick to some
other media, like internal flash.

Ideally, that installer should get started before loading an IMA policy.
That way, writing files will be faster (no hashing). But that doesn't
work because the security.ima of hashed files cannot be set.

It works after loading an IMA policy which hashes the files on the
target partition: rsync or bsdtar try write security.ima, print an
error, continue, and the kernel sets the same hash that the tools
weren't allowed to set earlier.

Besides the slower copy operation, we also get errors that we need to
ignore because (most likely) they are harmless. Not nice, because at
some point there might be genuine errors which also get ignored.

Would it make sense to always allow setting security.ima when the caller
has the right priviliges? If someone sets a broken value, that's their
problem.

-- 
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.