From: Kees Cook <keescook@chromium.org>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: John Johansen <john.johansen@canonical.com>,
SElinux list <selinux@vger.kernel.org>,
James Morris <jmorris@namei.org>,
Mimi Zohar <zohar@linux.ibm.com>,
LSM List <linux-security-module@vger.kernel.org>,
linux-audit@redhat.com
Subject: Re: LSM stacking in next for 6.1?
Date: Fri, 28 Oct 2022 10:40:36 -0700 [thread overview]
Message-ID: <202210280944.AF75E37DC@keescook> (raw)
In-Reply-To: <56add81d-0ea7-9d3e-0e30-e0b02e62a8d0@I-love.SAKURA.ne.jp>
On Fri, Oct 28, 2022 at 10:58:30PM +0900, Tetsuo Handa wrote:
> Do you remember that 10 modules were proposed
>
> SimpleFlow ( 2016/04/21 https://lwn.net/Articles/684825/ )
> HardChroot ( 2016/07/29 https://lwn.net/Articles/695984/ )
> Checmate ( 2016/08/04 https://lwn.net/Articles/696344/ )
> LandLock ( 2016/08/25 https://lwn.net/Articles/698226/ )
> PTAGS ( 2016/09/29 https://lwn.net/Articles/702639/ )
> CaitSith ( 2016/10/21 https://lwn.net/Articles/704262/ )
> SafeName ( 2016/05/03 https://lwn.net/Articles/686021/ )
> WhiteEgret ( 2017/05/30 https://lwn.net/Articles/724192/ )
> shebang ( 2017/06/09 https://lwn.net/Articles/725285/ )
> S.A.R.A. ( 2017/06/13 https://lwn.net/Articles/725230/ )
There was also:
LoadPin ( 2016/04/20 https://lore.kernel.org/lkml/1461192388-13900-1-git-send-email-keescook@chromium.org/ )
SafeSetID ( 2018/10/31 https://lore.kernel.org/linux-security-module/20181031152846.234791-1-mortonm@chromium.org/ )
BPF ( 2019/09/10 https://lore.kernel.org/linux-security-module/20190910115527.5235-1-kpsingh@chromium.org/ )
So, 13 LSM proposed, 4 landed: roughly 30%, which is on par[1] with regular
kernel development.
> I consider /sbin/insmod-able LSM modules as a compromise/remedy for LSM modules
> which could not get merged upstream or supported by distributors, for patching and
> rebuilding the whole kernel in order to use not-yet-upstreamed and/or not-builtin
> LSMs is already a lot of barrier for users. But requiring a permanent integer in
> order to use a LSM module is a denial of even patching and rebuilding the whole
> kernel. That's why I hate this change.
But the upstream kernel _does not support APIs for out-of-tree code_. To
that point, security_add_hooks() is _not exported_, so it is already not
possible to create a modular LSM without patching the kernel source.
> I can't understand why assigning a permanent integer identifier is mandatory.
Plenty of other APIs use numeric identifiers: syscalls, prctl, etc. This
doesn't block them from being upstreamed.
-Kees
[1] https://ieeexplore.ieee.org/abstract/document/6624016
--
Kees Cook
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Paul Moore <paul@paul-moore.com>,
John Johansen <john.johansen@canonical.com>,
Casey Schaufler <casey@schaufler-ca.com>,
LSM List <linux-security-module@vger.kernel.org>,
James Morris <jmorris@namei.org>,
linux-audit@redhat.com, Mimi Zohar <zohar@linux.ibm.com>,
SElinux list <selinux@vger.kernel.org>
Subject: Re: LSM stacking in next for 6.1?
Date: Fri, 28 Oct 2022 10:40:36 -0700 [thread overview]
Message-ID: <202210280944.AF75E37DC@keescook> (raw)
In-Reply-To: <56add81d-0ea7-9d3e-0e30-e0b02e62a8d0@I-love.SAKURA.ne.jp>
On Fri, Oct 28, 2022 at 10:58:30PM +0900, Tetsuo Handa wrote:
> Do you remember that 10 modules were proposed
>
> SimpleFlow ( 2016/04/21 https://lwn.net/Articles/684825/ )
> HardChroot ( 2016/07/29 https://lwn.net/Articles/695984/ )
> Checmate ( 2016/08/04 https://lwn.net/Articles/696344/ )
> LandLock ( 2016/08/25 https://lwn.net/Articles/698226/ )
> PTAGS ( 2016/09/29 https://lwn.net/Articles/702639/ )
> CaitSith ( 2016/10/21 https://lwn.net/Articles/704262/ )
> SafeName ( 2016/05/03 https://lwn.net/Articles/686021/ )
> WhiteEgret ( 2017/05/30 https://lwn.net/Articles/724192/ )
> shebang ( 2017/06/09 https://lwn.net/Articles/725285/ )
> S.A.R.A. ( 2017/06/13 https://lwn.net/Articles/725230/ )
There was also:
LoadPin ( 2016/04/20 https://lore.kernel.org/lkml/1461192388-13900-1-git-send-email-keescook@chromium.org/ )
SafeSetID ( 2018/10/31 https://lore.kernel.org/linux-security-module/20181031152846.234791-1-mortonm@chromium.org/ )
BPF ( 2019/09/10 https://lore.kernel.org/linux-security-module/20190910115527.5235-1-kpsingh@chromium.org/ )
So, 13 LSM proposed, 4 landed: roughly 30%, which is on par[1] with regular
kernel development.
> I consider /sbin/insmod-able LSM modules as a compromise/remedy for LSM modules
> which could not get merged upstream or supported by distributors, for patching and
> rebuilding the whole kernel in order to use not-yet-upstreamed and/or not-builtin
> LSMs is already a lot of barrier for users. But requiring a permanent integer in
> order to use a LSM module is a denial of even patching and rebuilding the whole
> kernel. That's why I hate this change.
But the upstream kernel _does not support APIs for out-of-tree code_. To
that point, security_add_hooks() is _not exported_, so it is already not
possible to create a modular LSM without patching the kernel source.
> I can't understand why assigning a permanent integer identifier is mandatory.
Plenty of other APIs use numeric identifiers: syscalls, prctl, etc. This
doesn't block them from being upstreamed.
-Kees
[1] https://ieeexplore.ieee.org/abstract/document/6624016
--
Kees Cook
next prev parent reply other threads:[~2022-10-28 17:41 UTC|newest]
Thread overview: 148+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <791e13b5-bebd-12fc-53de-e9a86df23836.ref@schaufler-ca.com>
2022-08-03 0:01 ` LSM stacking in next for 6.1? Casey Schaufler
2022-08-03 0:01 ` Casey Schaufler
2022-08-03 0:56 ` Paul Moore
2022-08-03 0:56 ` Paul Moore
2022-08-03 1:56 ` John Johansen
2022-08-03 1:56 ` John Johansen
2022-08-03 2:15 ` Casey Schaufler
2022-08-03 2:15 ` Casey Schaufler
2022-08-03 2:33 ` Paul Moore
2022-08-03 2:33 ` Paul Moore
2022-08-03 2:34 ` Steve Grubb
2022-08-03 2:34 ` Steve Grubb
2022-08-03 2:40 ` Paul Moore
2022-08-03 2:40 ` Paul Moore
2022-09-02 21:30 ` Paul Moore
2022-09-02 21:30 ` Paul Moore
2022-09-02 23:14 ` Casey Schaufler
2022-09-02 23:14 ` Casey Schaufler
2022-09-02 23:57 ` Casey Schaufler
2022-09-02 23:57 ` Casey Schaufler
2022-09-06 23:24 ` Paul Moore
2022-09-06 23:24 ` Paul Moore
2022-09-07 0:10 ` John Johansen
2022-09-07 0:10 ` John Johansen
2022-09-07 0:39 ` Casey Schaufler
2022-09-07 0:39 ` Casey Schaufler
2022-09-07 0:50 ` John Johansen
2022-09-07 0:50 ` John Johansen
2022-09-07 14:41 ` Paul Moore
2022-09-07 14:41 ` Paul Moore
2022-09-07 16:41 ` Casey Schaufler
2022-09-07 16:41 ` Casey Schaufler
2022-09-07 17:23 ` John Johansen
2022-09-07 17:23 ` John Johansen
2022-09-07 22:57 ` Paul Moore
2022-09-07 22:57 ` Paul Moore
2022-09-07 23:27 ` Paul Moore
2022-09-07 23:27 ` Paul Moore
2022-09-07 23:53 ` Casey Schaufler
2022-09-07 23:53 ` Casey Schaufler
2022-09-08 0:19 ` John Johansen
2022-09-08 0:19 ` John Johansen
2022-09-08 3:57 ` Paul Moore
2022-09-08 3:57 ` Paul Moore
2022-09-08 18:05 ` Casey Schaufler
2022-09-08 18:05 ` Casey Schaufler
2022-09-08 18:35 ` John Johansen
2022-09-08 18:35 ` John Johansen
2022-09-08 19:32 ` Paul Moore
2022-09-08 19:32 ` Paul Moore
2022-09-08 22:56 ` Casey Schaufler
2022-09-08 22:56 ` Casey Schaufler
2022-09-10 4:17 ` Tetsuo Handa
2022-09-10 4:17 ` Tetsuo Handa
2022-09-12 17:37 ` Casey Schaufler
2022-09-12 17:37 ` Casey Schaufler
2022-09-13 10:47 ` Tetsuo Handa
2022-09-13 10:47 ` Tetsuo Handa
2022-09-13 14:45 ` Casey Schaufler
2022-09-13 14:45 ` Casey Schaufler
2022-09-14 13:57 ` Tetsuo Handa
2022-09-14 13:57 ` Tetsuo Handa
2022-09-14 15:50 ` Casey Schaufler
2022-09-14 15:50 ` Casey Schaufler
2022-09-15 14:27 ` Tetsuo Handa
2022-09-15 14:27 ` Tetsuo Handa
2022-09-15 14:54 ` John Johansen
2022-09-15 14:54 ` John Johansen
2022-09-15 7:45 ` John Johansen
2022-09-15 7:45 ` John Johansen
2022-09-15 14:27 ` Tetsuo Handa
2022-09-15 14:27 ` Tetsuo Handa
2022-10-25 9:48 ` Tetsuo Handa
2022-10-25 9:48 ` Tetsuo Handa
2022-10-25 10:26 ` John Johansen
2022-10-25 10:26 ` John Johansen
2022-10-25 11:20 ` Tetsuo Handa
2022-10-25 11:20 ` Tetsuo Handa
2022-10-25 14:12 ` Casey Schaufler
2022-10-25 14:12 ` Casey Schaufler
2022-10-25 22:12 ` Tetsuo Handa
2022-10-25 22:12 ` Tetsuo Handa
2022-10-25 22:41 ` Casey Schaufler
2022-10-25 22:41 ` Casey Schaufler
2022-10-26 10:19 ` Tetsuo Handa
2022-10-26 10:19 ` Tetsuo Handa
2022-10-26 15:30 ` Casey Schaufler
2022-10-26 15:30 ` Casey Schaufler
2022-10-28 10:14 ` John Johansen
2022-10-28 10:14 ` John Johansen
2022-10-30 4:03 ` Tetsuo Handa
2022-10-30 4:03 ` Tetsuo Handa
2022-10-30 7:23 ` John Johansen
2022-10-30 7:23 ` John Johansen
2022-10-30 14:02 ` Tetsuo Handa
2022-10-30 14:02 ` Tetsuo Handa
2022-10-30 16:37 ` Kees Cook
2022-10-30 16:37 ` Kees Cook
2022-10-30 20:56 ` Casey Schaufler
2022-10-30 20:56 ` Casey Schaufler
2022-10-31 10:26 ` Tetsuo Handa
2022-10-31 10:26 ` Tetsuo Handa
2022-10-31 15:47 ` Casey Schaufler
2022-10-31 15:47 ` Casey Schaufler
2022-10-26 20:11 ` Paul Moore
2022-10-26 20:11 ` Paul Moore
2022-10-27 0:02 ` Tetsuo Handa
2022-10-27 0:02 ` Tetsuo Handa
2022-10-28 9:50 ` Paul Moore
2022-10-28 9:50 ` Paul Moore
2022-10-28 13:58 ` Tetsuo Handa
2022-10-28 13:58 ` Tetsuo Handa
2022-10-28 17:40 ` Kees Cook [this message]
2022-10-28 17:40 ` Kees Cook
2022-10-29 9:33 ` Tetsuo Handa
2022-10-29 9:33 ` Tetsuo Handa
2022-09-14 13:42 ` Paul Moore
2022-09-14 13:42 ` Paul Moore
2022-09-27 20:54 ` Casey Schaufler
2022-09-27 20:54 ` Casey Schaufler
2022-09-27 22:37 ` Paul Moore
2022-09-27 22:37 ` Paul Moore
2022-09-07 0:31 ` Casey Schaufler
2022-09-07 0:31 ` Casey Schaufler
2022-09-07 15:13 ` Paul Moore
2022-09-07 15:13 ` Paul Moore
2022-09-07 17:08 ` Casey Schaufler
2022-09-07 17:08 ` Casey Schaufler
2022-09-07 23:04 ` Paul Moore
2022-09-07 23:04 ` Paul Moore
2022-09-07 23:26 ` Casey Schaufler
2022-09-07 23:26 ` Casey Schaufler
2022-09-08 15:18 ` Tetsuo Handa
2022-09-08 15:18 ` Tetsuo Handa
2022-09-08 16:00 ` Casey Schaufler
2022-09-08 16:00 ` Casey Schaufler
2022-09-08 18:52 ` Paul Moore
2022-09-08 18:52 ` Paul Moore
2022-09-09 11:32 ` Tetsuo Handa
2022-09-09 11:32 ` Tetsuo Handa
2022-09-14 13:56 ` Paul Moore
2022-09-14 13:56 ` Paul Moore
2022-09-15 14:27 ` Tetsuo Handa
2022-09-15 14:27 ` Tetsuo Handa
2022-09-15 15:50 ` Casey Schaufler
2022-09-15 15:50 ` Casey Schaufler
2022-09-16 13:34 ` Tetsuo Handa
2022-09-16 13:34 ` 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=202210280944.AF75E37DC@keescook \
--to=keescook@chromium.org \
--cc=jmorris@namei.org \
--cc=john.johansen@canonical.com \
--cc=linux-audit@redhat.com \
--cc=linux-security-module@vger.kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=selinux@vger.kernel.org \
--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.