On Mon, 2017-10-30 at 11:51 +0000, Matthew Garrett wrote: > On Mon, Oct 30, 2017 at 11:36 AM, Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> wrote: > > On Mon, 2017-10-30 at 10:53 +0000, Matthew Garrett wrote: > >> 2) It should be possible to write a policy that allows these files to > >> be arbitrarily modified, including being deleted > > > > File deletion is not the problem, but if we allow the file metadata to > > change, then the file verification will fail. > > That seems reasonable? The policy may not be appraising all files, in > which case having verification fail isn't a problem. > > >> 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. > > > > EVM, up to now, is reactive to file data and meta-data changes, > > replacing the file signature with an HMAC. For the new file signature > > to be immutable it needs to prevent security.evm from changing, which > > this patch currently does not do. > > It prevents the kernel from modifying security.evm, but doesn't > prevent userspace from doing so. But if userspace does so, > verification will fail. No, the current code does not prevent the signature from being replaced with an HMAC. Subsequent EVM verification will succeed based on an HMAC.
