On Tue, 2017-10-17 at 19:13 -0700, Matthew Garrett wrote: > On Tue, Oct 17, 2017 at 7:08 PM, Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> wrote: > > On Tue, 2017-10-17 at 19:02 -0700, Matthew Garrett wrote: > > > >> 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. > > > > Updating/writing security.evm is triggered by writing or updating ANY > > file metadata included in the HMAC calculation. There is no > > requirement for security.ima to exist. > > In this case there's no symmetric key loaded, so security.evm won't be > updated. Here's what's happening: > > 1) Configure an IMA policy that only appraises a subset of files > 2) Create a new file that does not match the appraisal rule. > IMA_NEW_FILE isn't set because no rule matched. > 3) Attempt to write security.ima, security.capability and security.evm > on the new file. EVM blocks this because IMA_NEW_FILE isn't set. Are you writing these xattrs before or after you closed the file? Once the file is closed, even if the IMA_NEW_FILE flag had been set, it would be removed. This normally works because the file would have been hashed and written out as security.ima, causing security.evm to be written out as well. > I may be misdiagnosing this, but as far as I can tell IMA_NEW_FILE is > only set in ima_appraise_measurement() if action is set to something, > and if ima_match_rules() doesn't match then this will never be the > case? True, but having IMA_NEW_FILE set would only help with writing the first xattr, not subsequent ones.
