Linux Security Modules development
 help / color / mirror / Atom feed
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.

  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