On Tue, Oct 17, 2017 at 7:53 PM, Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> wrote: > 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: >> 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. Yes, I've fixed up my implementation to make the calls while the file is still open. >> 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. Ok. I'm not sure this is easily fixable to handle my use-case without breaking assumptions made in yours, so I'm wondering if a different approach would be better here. For us, there's no problem with updating any of the EVM-protected xattrs at runtime as long as doing so invalidates the iint cache entry (hmm, does setting an xattr bump the iversion? If so, we already get this behaviour). How would you feel about a runtime controllable flag that enabled this, possibly tied into the /sys/kernel/security/evm write? We'd end up with: 1: Enable HMAC 2: Enable RSA 4: Permit extended attribute writes Existing behaviour would be preserved since 1 would lock down the interface, and we could reject cases where 1 and 4 are set simultaneously.
