On Wed, Oct 18, 2017 at 10:51 AM, Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> wrote: >> 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." This would require adding a new syscall (including glibc support), and I think that's probably a hard sell for a single usecase. Looking at the code a bit more, are you sure about this? I thought IMA_NEW_FILE would only be cleared once the last writer closes the fd, so it ought to be possible to do multiple fsetxattr()s with the same file descriptor until the last writer closes it?
