On Wed, 2017-10-18 at 11:08 -0700, Matthew Garrett wrote: > 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? The IMA_NEW_FILE check is applicable only when there are no security xattrs (INTEGRITY_NOXATTRS), which would not be the case after writing the first security xattr. The return result in that case is INTEGRITY_NOLABEL, meaning no security.evm. Mimi
