Re: [RFC] EVM: Add support for portable signature format

[Matthew Garrett <mjg59@google.com>]

On Thu, Oct 26, 2017 at 8:22 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> On Thu, 2017-10-26 at 12:46 +0300, Mikhail Kurinnoi wrote:
>> ? Thu, 26 Oct 2017 02:08:25 -0700
>> Matthew Garrett <mjg59@google.com> ?????:
>> > That's fine - policy may not care. It's easier to sign all files and
>> > then leave enforcement up to the local policy than it is to determine
>> > in advance which files will need protection.
>
> You're both correct.  Signing the file data will prevent security.ima
> from changing, assuming the file is in policy and there is a
> FILE_CHECK rule.  We're requiring the signed file-metadata include
> security.ima, but it currently doesn't require it to contain a file
> signature.  Only having a single file signature, was one of Matthew's
> requirements.
>
> IMA accessing the EVM flags crosses the boundary between EVM/IMA. Just
> as the LSMs protect their own xattr label, EVM should protect
> security.evm, preventing it from changing.  There's no need for the
> test here in IMA.

Ok - so the preferred approach here would be to allow updating of
security.ima if it's a hash rather than a digsig, and then have EVM
validation fail later? That seems reasonable to me, but it'll mean
reworking the EVM side a little in order to ensure that the EVM
signature doesn't get rewritten into an HMAC in response.

>> Hmm...
>> http://www.spinics.net/lists/linux-integrity/msg00151.html
>>
>> probably, we should decide first, what exactly immutable EVM mean.
>> It's hard to propose something or test patch if we still have
>> misunderstanding in concept of immutable EVM.
>
> Agreed.  I think EVM should prevent any changes to the file metadata
> that would cause the portable/immutable EVM signature to be invalid.
>  For example, the change in evm_inode_setattr() permits the file
> metadata to change.  The same is true for removing files or writing
> security xattrs.

This seems to run counter to there being no linkage between EVM and
IMA. If IMA is unaware that there's an EVM digital signature then it
has no way of knowing that security.ima shouldn't be updated.

The scenario that I want is basically the following:

1) New files with portable signatures can be written to the filesystem
even if EVM is active
2) It should be possible to write a policy that allows these files to
be arbitrarily modified, including being deleted

I'd been interpreting "immutable" in this case to mean "the kernel
will never replace the signature with an hmac" rather than "the file
and protected information cannot be modified". If you think the latter
is necessary then I think we need two separate signature types and to
handle the two separately.