LSM/IMA integration denying access to inode_init_security.

Dr. Greg greg at enjellic.com
Mon Mar 18 09:38:25 UTC 2024


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.

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.

Have a good week.

As always,
Dr. Greg

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



More information about the Linux-security-module-archive mailing list