Hi, (previous email was sent by mistake incompleted) I have not read thread in detail so sorry if I will repeat something. EVM support signatures. https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git/tree/security/integrity/evm/evm_main.c?h=next#n166 They can be mutable or immutable if I not is marked immutables Mutable signature will be replaced on the first verification. And ima-evm-utils has support to generate evm signatures https://sourceforge.net/p/linux-ima/ima-evm-utils/ci/master/tree/src/evmctl.c#l1549 Also there is concept of EVM signatures not bound to inode unique data like ino and generation.. Also there are patches I made 2 years ago 2015-10-22 ima: limit capabilities for unsigned executable 2015-10-22 evm: load EVM key from the kernel 2015-10-22 evm: require EVM signature based appraisal 2015-10-22 ima: provide appraise_type=evmsig 2015-10-22 evm: provide immutable EVM signature They are on the top here https://git.kernel.org/pub/scm/linux/kernel/git/kasatkin/linux-digsig.git/log/?h=evm-next Have you seen it? Dmitry On Wed, Oct 18, 2017 at 9:16 PM, Dmitry Kasatkin <dmitry.kasatkin@xxxxxxxxx> wrote: > Hi, > > I have not read thread in detail so sorry if I will repeat something. > > EVM support signatures. > https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git/tree/security/integrity/evm/evm_main.c?h=next#n166 > > They can be mutable or immutable if I not is marked immutables > Mutable signature will be replaced on the first verification. > > And ima-evm-utils has support to generate evm signatures > > https://sourceforge.net/p/linux-ima/ima-evm-utils/ci/master/tree/src/evmctl.c#l1549 > > Also there is concept of EVM signatures not bound to inode unique data like > ino and generation > > > On Wed, Oct 18, 2017 at 8:51 PM, Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> > wrote: >> >> > >> 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 >> > > > > -- > Thanks, > Dmitry -- Thanks, Dmitry
