Re: [PATCH v7 6/6] evm: Support multiple LSMs providing an xattr
Mimi Zohar <[email protected]>
| Newsgroups | gmane.comp.file-systems.reiserfs.general,gmane.comp.file-systems.ocfs2.devel,gmane.linux.kernel.lsm,gmane.linux.kernel |
|---|---|
| Message-ID | <[email protected]> |
On Mon, 2023-02-20 at 10:49 +0100, Roberto Sassu wrote: > On Sun, 2023-02-19 at 14:42 -0500, Mimi Zohar wrote: > > On Thu, 2022-12-01 at 11:41 +0100, Roberto Sassu wrote: > > > From: Roberto Sassu <[email protected]> > > > > > > Currently, evm_inode_init_security() processes a single LSM xattr from > > > the array passed by security_inode_init_security(), and calculates the > > > HMAC on it and other inode metadata. > > > > > > Given that initxattrs() callbacks, called by > > > security_inode_init_security(), expect that this array is terminated when > > > the xattr name is set to NULL, reuse the same assumption to scan all xattrs > > > and to calculate the HMAC on all of them. > > > > > > Signed-off-by: Roberto Sassu <[email protected]> > > > Reviewed-by: Casey Schaufler <[email protected]> > > > > Normally changing the contents of the EVM HMAC calculation would break > > existing systems. Assuming for the time being this is safe, at what > > point will it affect backwards compatability? Should it be documented > > now or then? > > Actually, the current patch set continues to fullfill user space > expectation on the EVM behavior. If the LSM infrastructure created more > xattrs and EVM calculated the HMAC on just one, there would be a > problem on subsequent xattr operations and on IMA verification. > > By updating both the LSM infrastructure and EVM to support multiple > xattrs, everything will continue to work. Agreed. Thank you for the reminder of the bug report being addressed by this patch set. Reviewed-by: Mimi Zohar <[email protected]> -- thanks, Mimi