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

[Dmitry K. <dmi...@gm...>]

Hi,


On Tue, Oct 11, 2016 at 3:24 PM, Patrick Ohly <pat...@in...> wrote:
> 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.
>

Yeah. It was security hardening.
It would be great to have CAP_INTEGRITY_ADMIN or something like that.
But if it seriously harm then just revert it.

Dmitry

> --
> 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.
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Linux-ima-user mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-ima-user



-- 
Thanks,
Dmitry