From: "Mickaël Salaün" <mic@digikod.net>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: "Serge E. Hallyn" <serge@hallyn.com>,
Paul Moore <paul@paul-moore.com>,
Fan Wu <wufan@linux.microsoft.com>,
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
Subject: Re: TOMOYO's pull request for v6.12
Date: Fri, 4 Oct 2024 15:11:01 +0200 [thread overview]
Message-ID: <20241004.ohpie8Ing5bu@digikod.net> (raw)
In-Reply-To: <bc8bd0d5-ce58-4146-8bfa-1042c6575290@I-love.SAKURA.ne.jp>
On Fri, Oct 04, 2024 at 07:50:05PM +0900, Tetsuo Handa wrote:
> On 2024/10/04 1:29, Serge E. Hallyn wrote:
> > Well, this didn't occur to me last night, but what I'd be curious to
> > hear is whether Tetsuo has discussed this with RedHat. Because unless
> > this makes them say "ok we'll enable that", it still doesn't help him.
> > And I don't imagine them agreeing to enable the CONFIG_TOMOYO_LKM.
>
> Majority of Linux users I work for are using Red Hat. But I have absolutely
My understanding is that Red Hat's customers must ask for a feature for
it to be available (in a future version), so you should ask your users
to support the request.
I wish Landlock would be available everywhere too, but this requires
some effort. Even when an LSM is built-in, it may not be enabled by
default and then not available to most users because of the "lsm="
cmdline or CONFIG_LSM... To protect as much users as possible
(potentially without their knowledge), we have the burden of convincing
distros and other parts of the Linux ecosystems that a security feature
is worth it.
> too little relationship with Red Hat people to involve somebody else into
> this problem. Too little attention/interest to make progress.
> https://bugzilla.redhat.com/show_bug.cgi?id=2303689
>
> Chicken-and-egg problem here; since TOMOYO is not available in Red Hat
> kernels, I have no room/chance to help/involve with Red Hat community.
>
> If I implement a subset of TOMOYO that does not refuse requests (something
> like SELinux without the "enforcing mode"), can such LSM module be accepted
> by the upstream kernel? (The "patent examination" is a barrier for doing it.)
>
> You might think that such LSM module is not a security. But TOMOYO is
> also used as a sort of system-wide strace-like profiler. Understanding
> what the users' systems are doing is useful/helpful for users.
I think an LSM is not the right tool for tracing because it only sees a
subset of the access requests: other security mechanisms may deny
requests before they reach an LSM. Linux provides great tracing
mechanisms though.
>
> If one of Red Hat's worries that refusing requests due to broken policy is
> gone, the barrier for enabling such LSM module in Red Hat's kernels will be
> lowered. If such LSM module becomes available in Red Hat kernels, I might be
> able to find room/chance to help/involve with Red Hat community.
The question is about potential maintenance cost vs. ROI, not only
security policy issues. I guess Red Hat would not care about bugs in
non-default service configurations, eBPF programs, nor LSM policies, but
they will if additional code potentially impacts other parts of the
system and may increase the number of potential bugs, and then the
maintenance cost. Open source is not free for everyone.
next prev parent reply other threads:[~2024-10-04 13:11 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 [this message]
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=20241004.ohpie8Ing5bu@digikod.net \
--to=mic@digikod.net \
--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=mortonm@chromium.org \
--cc=paul@paul-moore.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=roberto.sassu@huawei.com \
--cc=serge@hallyn.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.