> >> 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. Here's an alternative, though admittedly one that is more difficult to implement and dependent on having a portable EVM signature type. Define the equivalent of listxattr that allows writing multiple xattrs. Change option 4 above to "Permit writing a group of extended attributes, including an EVM signature, when none currently exist." Then option 1 and 4 won't need to be mutually exclusive. Mimi
