On Mon, 2020-03-30 at 15:56 +0000, Roberto Sassu wrote: > > -----Original Message----- > > From: Mimi Zohar [mailto:zohar@xxxxxxxxxxxxx] > > Sent: Monday, March 30, 2020 5:47 PM > > To: Roberto Sassu <roberto.sassu@xxxxxxxxxx>; > > matthewgarrett@xxxxxxxxxx > > Cc: linux-integrity@xxxxxxxxxxxxxxx; Silviu Vlasceanu > > <Silviu.Vlasceanu@xxxxxxxxxx> > > Subject: Re: Immutable metadata > > > > On Sun, 2020-03-29 at 22:10 -0400, Mimi Zohar wrote: > > > Hi Roberto, > > > > > > On Sat, 2020-03-28 at 11:18 +0000, Roberto Sassu wrote: > > > > Hi Matthew, Mimi > > > > > > > > I have a question about portable signatures. Is there any particular > > reason > > > > why a write to a file is not denied by IMA if metadata are immutable? > > > > > > As much as possible, IMA and EVM should be independent of each other. > > > EVM is responsible for the integrity of file metadata, so it needs to > > > read other security xattrs, but IMA shouldn't be looking at the EVM > > > xattr. > > > > > > Like any other security xattr, responsibility for maintaining the > > > xattr is left up to the particular LSM. In this case, EVM would need > > > to prevent the file from being opened rw. Should that be hard coded > > > or based on an EVM policy? > > > > Thinking about this a bit more, evm_verifyxattr() is already returning > > INTEGRITY_PASS_IMMUTABLE. I guess IMA could make decisions based on > > it. > > Yes, this was the idea. > > I would say also that files with portable signatures fulfill the appraise_type=imasig > requirement. I would set the IMA_DIGSIG bit in iint->atomic_flags. Is it ok? Ok, so locking doesn't seem to be an issue here. I'm not sure about re-using the existing bit. EVM_XATTR_PORTABLE_DIGSIG is dependent on the existence of a file hash. The existing bit prevents calculating and writing the file hash as an xattr. Would this affect installing new files? Mimi
