LSM/IMA integration denying access to inode_init_security.

[Roberto Sassu]

On Mon, 2024-03-18 at 04:38 -0500, Dr. Greg wrote:
> Good morning Paul/Roberto, I hope this note finds your respective
> weeks starting well, greetings to the wider security list as well.
> 
> We ran into an issue, that seems to be secondary to the LSM/IMA
> integration, in our TSEM port to the 6.8 kernel that would seem to be
> relevant to other or future LSM's.
> 
> It appears that the IMA/LSM work added the following code to the
> security/security.c:security_inode_init_security() function:
> 
> if (!blob_sizes.lbs_xattr_count)
> 	return 0;
> 
> Which denies access to the hook by an LSM that has registered a
> handler for an event but that has not registered the use of extended
> attributes through the LSM blob mechanism.  This pre-supposes the
> notion that all LSM's that may want to be notified of an inode
> instantiation event will be using extended attributes.
> 
> For example, in TSEM we use this hook to propagate task identity
> ownership and inode instance information from the
> security_inode_create hook into the TSEM inode security state
> information.
> 
> We 'fixed' the problem by requesting a single extended attribute
> allocation for TSEM, but that seems inelegant in the larger picture,
> given that a handler that wishes to use the hook in the absence of
> extended attributes can use the hook and return EOPNOTSUPP with no ill
> effects.

Hi Greg

I agree, it should not be needed.

> We haven't had time to track down the involved code but a cursory
> examination would seem to suggest that this also effectively denies
> the ability to create an operational BPF hook for this handler.  Given
> that BPF is proposed as a mechanism to implement just any arbitrary
> security policy, this would seem problematic, if it doesn't already
> break current BPF LSM implementations that may have placed a handler
> on this event.
> 
> We could certainly roll a patch for consideration on how to address
> this issue if that would be of assistance.  At the very least the
> documentation for the function no longer matches its operational
> characteristics.

I think the check above was just an optimization, but I agree you might
do other tasks, other than just filling the xattrs slot.

For me, it would not be really a problem to modify the code to invoke
the inode_init_security hooks with xattrs set to NULL.

I haven't found any counterargument, but will think some more.

> Have a good week.

You too!

Roberto