From: "Serge E. Hallyn" <serge@hallyn.com>
To: Paul Moore <paul@paul-moore.com>
Cc: "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>,
"Casey Schaufler" <casey@schaufler-ca.com>,
"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,
"Serge E. Hallyn" <serge@hallyn.com>
Subject: Re: TOMOYO's pull request for v6.12
Date: Wed, 2 Oct 2024 21:51:52 -0500 [thread overview]
Message-ID: <20241003025152.GA834221@mail.hallyn.com> (raw)
In-Reply-To: <20241003024307.GA833999@mail.hallyn.com>
On Wed, Oct 02, 2024 at 09:43:07PM -0500, Serge E. Hallyn wrote:
> On Wed, Oct 02, 2024 at 04:12:50PM -0400, 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.
> >
> > As I wrote in my original response to this pull request, this is not
> > something I would accept in a new LSM submission and thus I feel
> > compelled to speak out against this change and submit a revert to
> > Linus. However, as the LSM framework exists to satisfy the needs of
> > the individual LSMs, I've tried to ensure that significant changes
> > like these are done with support of the majority of LSMs. I
> > understand that in a case like this, reverting LSM-specific commits,
> > individual LSM maintainers may not want to speak up on the issue so
> > I'm going to let this message sit on-list until Friday morning, unless
> > I see the majority of the LSMs voicing support *against* reverting the
> > TOMOYO commit above (and the other related commit) I will proceed with
> > submitting the revert to Linus on Friday. I would prefer if all
> > responses are sent on-list, but you can also mail me privately with
> > your objection to the revert and I will include it in the count.
> >
> > Thanks.
>
> Huh! Honestly, when I read the thread, especially Jon's comments, I was
> worried. But getting a chance to look at the patch now, it actually
> seems good to me. No one is getting affected unless they enable
> CONFIG_TOMOYO_LKM. Even those distros which have been enabling TOMOYO
> won't be exporting new hooks without a config change, iiuc.
>
> -serge
OTOH I am worried about the threatening sentence:
> This backdoor symbol-export mechanism is a transitional hack needed for
> demonstrating that loadable LSM can work. This hack will be replaced with
> proper symbol-export via appropriate trees after this merge window closes.
(in 7dce903c-2f76-43b2-bb6f-808cb50d0696@I-love.SAKURA.ne.jp)
-serge
next prev parent reply other threads:[~2024-10-03 2:51 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 [this message]
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
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=20241003025152.GA834221@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