From: Paul Moore <paul@paul-moore.com>
To: "Dr. Greg" <greg@enjellic.com>
Cc: Casey Schaufler <casey@schaufler-ca.com>,
linux-security-module@vger.kernel.org,
roberto.sassu@huaweicloud.com
Subject: Re: [PATCH] Do not require attributes for security_inode_init_security.
Date: Sun, 31 Mar 2024 11:02:59 -0400 [thread overview]
Message-ID: <CAHC9VhSwpJHZunGuP_C0YsK_DNLW=UtHSvD74-m+Qow0LiwaeA@mail.gmail.com> (raw)
In-Reply-To: <20240330201425.GA5453@wind.enjellic.com>
On Sat, Mar 30, 2024 at 4:14 PM Dr. Greg <greg@enjellic.com> wrote:
>
> 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.
I've said this before on-list, but I'll repeat it here for those who
might not follow every thread or email. The BPF LSM is a bit of an
odd case as while there is a very simple structure (framework?)
present in-tree, the actual implementation of the LSM is out-of-tree.
While one could draw some parallels between BPF LSM implementations
and other LSMs with loadable security policies, there is an important
difference in that the conventional LSMs with loadable security
policies separate the security policy from the enforcement engine code
and maintain the enforcement engine code in the upstream Linux kernel.
The BPF LSM maintains the enforcement engine code outside the upstream
Linux kernel and because of that it is impossible for us, the upstream
Linux devs, to do any meaningful analysis of BPF LSM behaviors.
The result of this is that I currently give individual BPF LSMs
largely the same consideration I would give out-of-tree kernel code: I
am not going to go out of my way to block, or otherwise negatively
impact the implementations, but I'm not going to sacrifice the
development of any of the in-tree LSMs, or the LSM layer itself,
solely for the advantage of an out-of-tree implementation. If you're
really craving an official policy, that's the policy-of-the-moment.
--
paul-moore.com
next prev parent reply other threads:[~2024-03-31 15:03 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
2024-03-31 15:02 ` Paul Moore [this message]
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='CAHC9VhSwpJHZunGuP_C0YsK_DNLW=UtHSvD74-m+Qow0LiwaeA@mail.gmail.com' \
--to=paul@paul-moore.com \
--cc=casey@schaufler-ca.com \
--cc=greg@enjellic.com \
--cc=linux-security-module@vger.kernel.org \
--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).