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