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

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

On Tue, 2016-07-12 at 09:00 -0400, Mimi Zohar wrote:
> 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.

Yes, if the file is under the current policy, then it is redundant. But
that implies that the user space tool knows exactly whether that
operation is redundant. That's far from trivial, isn't it?

And that assumes that the tool in question knows about IMA. bsdtar
doesn't support IMA, only xattrs. Therefore it will always write
security.ima, regardless what the value is in the archive that it
extracts and what the current policy on the target filesystem might be.

One could argue that the input archive shouldn't have the security.ima
set when it is not needed, but that (in our case) breaks another use
case, which is a feature of our update tool which compares files on disk
(including their meta data, which includes xattrs) against files stored
on the server. So the server side also needs to have the security.ima.

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

That explains the mechanism, but the commit comes with no further
explanations. Why the "should not be manually set", i.e. what's the
downside of allowing it?

There's also the problem that the patch prevents writing the hash in
situations where there is not active IMA policy. Your argument was that
letting the user write the hash is redundant because the kernel will do
it. But that's not true when the file isn't under the current policy (in
our case, because no policy has been loaded at all), and still the
kernel prevents writing the 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.
> 
> (I assume you meant signatures can not be written on unhashed files.)   

No, I meant writing a hash, like 0x0196..e3a in my initial example.

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

There is a need: OS gets installed, all hashes are set as required, then
OS boots immediately, without going into "fix" mode. Without writing the
hashes, files would be unusable.

We could boot into fix mode before installing, but that implies booting
with different command line parameters, which isn't possible in our
current setup: we have no boot loader, the firmware directly loads an
EFI blob which contains kernel, command line parameters and initramfs.

Our current image then either installs to internal storage or boots from
USB, depending on some files in the VFAT partition or user interaction.
But that check happens after the kernel started and thus switching modes
between fix and enforcement isn't possible anymore.

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

We are not using security.evm yet (yes, I know, it's a gap that we need
to close). So right now, all errors are about writing security.ima.

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