On Tue, Oct 17, 2017 at 6:49 PM, Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> wrote: > On Tue, 2017-10-17 at 16:12 -0700, Matthew Garrett wrote: >> I'm interested in extending our use of IMA digital signatures to EVM >> in order to protect security.capability (and, in the near future, >> security.apparmor). > > security.capability is already included in the EVM HMAC/signature. > Your security.apparmor patch is now queued in my #next branch. Ah, sorry, by "our" I meant "my specific use case", not upstream :) >> But as far as I can tell, IMA_NEW_FILE will only >> be set if there's an IMA action that covers the file in question. This >> means it's possible to write out security.evm and friends on newly >> created files that would be appraised, but not on any other files. Am >> I missing something? > > Only files in the IMA policy that pass integrity verification can be > accessed. The IMA_NEW_FILE flag overides this restriction, allowing > IMA to access new files, even if the security.ima xattr does not yet > exist. Is this accurate? If there's no IMA policy that covers the file in question (eg, appraise is limited to a specific security context or owner), will IMA_NEW ever be set? It looks like that codepath will only be entered if there's a rule that matches. The EVM xattr protections appear to be called regardless, which means that there's then no way to write out attributes on them at runtime.
