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

[Mimi Z. <zo...@li...>]

On Thu, 2016-07-07 at 15:02 +0200, Patrick Ohly wrote:
> 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.

Right, there's no good reason for explicitly writing the hash.  If the
file is in policy, on __fput() the file will automatically be hashed.
Only writing a file signature as security.ima xattr is permitted.
Refer to commit c68ed80 "ima: limit file hash setting by user to fix and
log modes".

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

(I assume you meant signatures can not be written on unhashed files.)   

Writing the file signature on new files, before __fput() is called,
would prevent the file hash from being calculated.  For example, GNU tar
writes the file signature before the file data.   (Refer to commit
05d1a71 "ima: add support for creating files using the mknodat syscall")

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

Exactly, no need for the userspace application to write the hash.

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

Other than writing file hashes or copying security.evm warnings are
there others?

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

The signature itself is currently not verified, before writing it as an
xattr, but the existing security.evm is checked, before allowing any
protected xattrs to be written.  Otherwise any change would  incorporate
any other intended/unintended changes in the security.evm xattr.

For those files included in the IMA policy, either a file hash or
signature needs to be written before the "new" file status is removed
(eg. __fput).   The only exceptions are for "fix" or "log" modes. 

Mimi