On 11/17/2022 8:05 AM, Mimi Zohar wrote: > hOn Thu, 2022-11-10 at 10:46 +0100, Roberto Sassu wrote: >> From: Roberto Sassu <roberto.sassu@xxxxxxxxxx> >> >> Currently, security_inode_init_security() supports only one LSM providing >> an xattr and EVM calculating the HMAC on that xattr, plus other inode >> metadata. >> >> Allow all LSMs to provide one or multiple xattrs, by extending the security >> blob reservation mechanism. Introduce the new lbs_xattr field of the >> lsm_blob_sizes structure, so that each LSM can specify how many xattrs it >> needs, and the LSM infrastructure knows how many xattr slots it should >> allocate. > Perhaps supporting per LSM multiple xattrs is a nice idea, but EVM > doesn't currently support it. The LSM xattrs are hard coded in > evm_config_default_xattrnames[], based on whether the LSM is > configured. Additional security xattrs may be included in the > security.evm calculation, by extending the list via > security/integrity/evm/evm_xattrs. Smack uses multiple xattrs. All file system objects have a SMACK64 attribute, which is used for access control. A program file may have a SMACK64EXEC attribute, which is the label the program will run with. A library may have a SMACK64MMAP attribute to restrict loading. A directory may have a SMACK64TRANSMUTE attribute, which modifies the new object creation behavior. The point being that it may be more than a "nice idea" to support multiple xattrs. It's not a hypothetical situation.
