From: "Dr. Greg" <greg@enjellic.com>
To: paul@paul-moore.com, roberto.sassu@huaweicloud.com
Cc: linux-security-module@vger.kernel.org
Subject: LSM/IMA integration denying access to inode_init_security.
Date: Mon, 18 Mar 2024 04:38:25 -0500 [thread overview]
Message-ID: <20240318093825.GA30817@wind.enjellic.com> (raw)
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
next reply other threads:[~2024-03-18 9:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-18 9:38 Dr. Greg [this message]
2024-03-18 10:39 ` LSM/IMA integration denying access to inode_init_security Roberto Sassu
2024-03-21 23:31 ` Dr. Greg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240318093825.GA30817@wind.enjellic.com \
--to=greg@enjellic.com \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=roberto.sassu@huaweicloud.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).