Re: [PATCH v4 3/5] security: Allow all LSMs to provide xattrs for inode_init_security hook

From: Roberto Sassu
Date: Fri Nov 18 2022 - 04:32:57 EST


On 11/17/2022 6:18 PM, Casey Schaufler wrote:
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.

Ok, that means that I have to change the number of xattrs reserved by Smack in patch 3.

Thanks

Roberto