LSM/IMA integration denying access to inode_init_security.

LSM/IMA integration denying access to inode_init_security.

[Dr. Greg]

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

Re: 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

Re: 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