From: "Dr. Greg" <greg@enjellic.com>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: Paul Moore <paul@paul-moore.com>,
linux-security-module@vger.kernel.org,
roberto.sassu@huaweicloud.com
Subject: Re: [PATCH] Do not require attributes for security_inode_init_security.
Date: Sat, 30 Mar 2024 15:14:25 -0500 [thread overview]
Message-ID: <20240330201425.GA5453@wind.enjellic.com> (raw)
In-Reply-To: <86c7477e-260f-419a-8aea-ea527a344877@schaufler-ca.com>
On Thu, Mar 28, 2024 at 09:34:39AM -0700, Casey Schaufler wrote:
Good afternoon, I hope the weekend is going well for everyone.
> On 3/28/2024 8:38 AM, Dr. Greg wrote:
> > ...
> >> In Linux v6.8[1] only Smack and SELinux provide implementations for
> >> the security_inode_init_security() hook, and both also increment the
> >> associated lsm_blob_sizes::lbs_xattr_count field. While the
> >> behavior of the hook may have changed, I see no indications of any
> >> harm with respect to the standard upstream Linux kernel. We
> >> obviously want to ensure that we work to fix harmful behavior, but I
> >> simply don't see that here; convince me there is a problem, send me
> >> a patch as we've discussed, and I'll merge it.
> > BPF provides an implementation and would be affected.
> BPF has chosen to implement its LSM hooks their own way. As it is
> impossible for the infrastructure developers to predict what the
> behavior of those hooks may be, it is unreasonable to constrain them
> based on hypothetical or rumored use cases.
We were asked to identify a case where upstream could be possibly
broken by the change in behavior, we did that.
It is now perfectly clear that the LSM maintainers don't consider the
possibility of breaking upstream BPF to be an issue of concern, no
doubt an important clarification for everyone moving forward.
> The implementation of BPF precludes its use of LSM blobs that are
> infrastructure managed. That ought to be obvious. BPF could include
> a non-zero lbs_xattr_count just in case, and your problem would be
> solved, but at a cost.
FWIW, it would not seem unreasonable to assume that an LSM, BPF
included, may want to be notified of the the instantiation of the
security state of an inode, regardless of whether or not the LSM is
using extended attributes.
> > Bear poking trimmed ...
> >
> > [1] In Linux v6.9-rc1 this grows to include EVM, but EVM also provides
> > both a hook implementation and a lbs_xattr_count bump.
> > BPF initialization, as of 6.8 does not include an xattr request.
> Just so. If BPF wants to use the aforementioned interface, it needs to
> include an xattr request. Just like any other LSM.
Requirement so noted.
Have a good week.
As always,
Dr. Greg
The Quixote Project - Flailing at the Travails of Cybersecurity
https://github.com/Quixote-Project
next prev parent reply other threads:[~2024-03-30 20:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-24 22:32 [PATCH] Do not require attributes for security_inode_init_security Greg Wettstein
2024-03-25 21:08 ` Paul Moore
2024-03-26 10:30 ` Dr. Greg
2024-03-26 19:12 ` Paul Moore
2024-03-27 9:16 ` Dr. Greg
2024-03-27 15:18 ` Paul Moore
2024-03-28 15:38 ` Dr. Greg
2024-03-28 16:34 ` Casey Schaufler
2024-03-30 20:14 ` Dr. Greg [this message]
2024-03-31 15:02 ` Paul Moore
2024-03-29 0:26 ` Paul Moore
2024-03-30 14:46 ` Dr. Greg
2024-03-30 21:39 ` Paul Moore
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=20240330201425.GA5453@wind.enjellic.com \
--to=greg@enjellic.com \
--cc=casey@schaufler-ca.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 NNTP newsgroup(s).