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

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

On Mo, 2016-07-18 at 09:22 +0200, Patrick Ohly wrote:
> 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.

Commit c68ed80 "ima: limit file hash setting by user to fix and log
modes" is a form of system hardening.  Before reverting it, let's see if
there is another option.

Could we summarize the problem as:
- the kernel prevents writing security.ima hashes.
- the kernel only writes security.ima hashes for files that are in
policy.
- the userspace tool doesn't know what is in/out of policy.
- the userspace tool doesn't differentiate between hashes and
signatures.
- the boot process doesn't permit changing the boot command line options
(eg. fix mode).
- the update tool compares file data and metadata with those on the
server

Currently, you said there is no IMA policy.  Would it make sense to
invert that to all files are in policy?  That way the kernel would write
the file hash as security.ima on all files (that are not signed).

The file metadata would match the update server.  Only the userspace
tool (bsdtar) would need to be modified to selectively write xattrs  -
either no security.ima xattrs or only security.ima file signatures.

Mimi