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

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

On Mon, 2016-07-18 at 14:21 +0200, Patrick Ohly wrote:
> On Mon, 2016-07-18 at 08:08 -0400, Mimi Zohar wrote:
> > 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
> 
> Correct.

I now ran into the very same problem also in another use case, i.e. not
just during system install time.

Ostro OS allows file-based updates on a running system. bsdtar is used
to extract the new revision of each modified or new file in a staging
directory. In our policy, some files are merely hashed and not signed,
because they might be modified on the device.

Extracting such files with bsdtar also fails with:
fsetxattr(4, "security.ima", "\1\217'\taw\210\3\245MrT\351n\336j\316\7z
\212j", 21, 0) = -1 EPERM (Operation not permitted)

Given that this particular kernel check is now causing problems in two
cases, can we revisit the question whether it can be reverted?

There are alternatives to dealing with the problem, but all of them are
considerably more work and more complex.

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