From: "Serge E. Hallyn" <serge@hallyn.com>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: "Paul Moore" <paul@paul-moore.com>,
"Tetsuo Handa" <penguin-kernel@i-love.sakura.ne.jp>,
"Fan Wu" <wufan@linux.microsoft.com>,
"Mickaël Salaün" <mic@digikod.net>,
"Mimi Zohar" <zohar@linux.ibm.com>,
"Micah Morton" <mortonm@chromium.org>,
"John Johansen" <john.johansen@canonical.com>,
"Roberto Sassu" <roberto.sassu@huawei.com>,
"KP Singh" <kpsingh@kernel.org>,
"Kees Cook" <keescook@chromium.org>,
"Jonathan Corbet" <corbet@lwn.net>,
linux-security-module@vger.kernel.org
Subject: Re: TOMOYO's pull request for v6.12
Date: Thu, 3 Oct 2024 11:42:11 -0500 [thread overview]
Message-ID: <20241003164211.GA849107@mail.hallyn.com> (raw)
In-Reply-To: <f0fc9923-c91a-48b2-ae61-30dd7287ecc2@schaufler-ca.com>
On Thu, Oct 03, 2024 at 09:36:00AM -0700, Casey Schaufler wrote:
> On 10/2/2024 1:12 PM, Paul Moore wrote:
> > Hi all,
> >
> > Hopefully by now you've at least seen the TOMOYO v6.12 pull request
> > thread; if you haven't read it yet, I suggest you do so before reading
> > the rest of this mail:
> >
> > https://lore.kernel.org/all/0c4b443a-9c72-4800-97e8-a3816b6a9ae2@I-love.SAKURA.ne.jp
> >
> > Of the three commits in the pull request, the commit which concerns me
> > the most is 8b985bbfabbe ("tomoyo: allow building as a loadable LSM
> > module"). The commit worries me as it brings management of the TOMOYO
> > LSM callbacks into TOMOYO itself, overriding the LSM framework.
> > Jonathan raises a similar point, although his issue is more focused on
> > the symbol export approach itself, rather than conceptual issues
> > relating to the LSM framework. I will admit there are some high level
> > similarities to this approach and the BPF LSM, but I believe we can
> > say that the BPF LSM exception is necessary due to the nature of BPF,
> > and not something we want to see duplicated outside of that one
> > special case.
>
> We wrangled with the BPF developers over a number of issues,
> and in the end gave them something that's a lot more dangerous
> than I'd like. With that in mind I can argue either of:
>
> Let's not do that again, revert.
Just checking - do you mean revert this, but not BPF LSM? :)
> We need to trust our LSM developers in their own code, keep it.
>
> What Tetsuo has implemented is a scheme that's been bouncing around for
> some time. It is neither especially novel nor elegant. It is intended to
> solve a particular issue, which is that Redhat distributions don't include
> TOMOYO. [I should be corrected if that statement is not true] When we
> talked about loadable modules in the past it was in the context of a
> general mechanism, which I have always said I don't want to preclude.
>
> I seriously doubt that this change would achieve the goal of getting
> TOMOYO included in Redhat distributions. It seriously increases the
Right, I think this is the biggest reason to request the revert, unless
Redhat or fedora tells us that they would actually enable it.
next prev parent reply other threads:[~2024-10-03 16:42 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-02 20:12 TOMOYO's pull request for v6.12 Paul Moore
2024-10-03 2:43 ` Serge E. Hallyn
2024-10-03 2:51 ` Serge E. Hallyn
2024-10-03 3:05 ` John Johansen
2024-10-03 15:32 ` Paul Moore
2024-10-03 16:29 ` Serge E. Hallyn
2024-10-04 10:50 ` Tetsuo Handa
2024-10-04 13:11 ` Mickaël Salaün
2024-10-04 14:34 ` Tetsuo Handa
2024-10-05 4:39 ` John Johansen
2024-10-03 16:36 ` Casey Schaufler
2024-10-03 16:42 ` Serge E. Hallyn [this message]
2024-10-03 16:49 ` Paul Moore
2024-10-03 16:58 ` Casey Schaufler
2024-10-04 20:54 ` Kees Cook
2024-10-04 21:03 ` Paul Moore
2024-10-04 23:41 ` Tetsuo Handa
2024-10-05 0:17 ` Kees Cook
2024-10-05 3:38 ` John Johansen
2024-10-23 10:52 ` Tetsuo Handa
2024-10-05 7:10 ` Tetsuo Handa
2024-10-05 16:10 ` Casey Schaufler
2024-10-05 17:02 ` Dr. Greg
2024-10-05 18:58 ` Casey Schaufler
2024-10-05 23:47 ` Paul Moore
2024-10-06 16:18 ` Dr. Greg
2024-10-06 16:47 ` Casey Schaufler
2024-10-06 20:20 ` Paul Moore
2024-10-06 21:50 ` John Johansen
2024-10-05 16:30 ` Paul Moore
2024-10-05 17:28 ` Simon Thoby
2024-10-06 0:02 ` Serge E. Hallyn
2024-10-06 10:02 ` Tetsuo Handa
2024-10-06 11:14 ` Simon Thoby
2024-10-07 11:00 ` Tetsuo Handa
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=20241003164211.GA849107@mail.hallyn.com \
--to=serge@hallyn.com \
--cc=casey@schaufler-ca.com \
--cc=corbet@lwn.net \
--cc=john.johansen@canonical.com \
--cc=keescook@chromium.org \
--cc=kpsingh@kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mic@digikod.net \
--cc=mortonm@chromium.org \
--cc=paul@paul-moore.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=roberto.sassu@huawei.com \
--cc=wufan@linux.microsoft.com \
--cc=zohar@linux.ibm.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