LSM/IMA integration denying access to inode_init_security.

[Dr. Greg]

On Mon, Mar 18, 2024 at 11:39:38AM +0100, Roberto Sassu wrote:
> 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.

Thanks Roberto, I'm glad you tentatively read the situation as we did.

> > 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.

Paul, do you have any reflections on this?

If not, we will propose a patch to return the previous behavior.

> > Have a good week.
> 
> You too!
> 
> Roberto

Thanks for the comments, have a good weekend.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity
              https://github.com/Quixote-Project