selinux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	Paul Moore <paul@paul-moore.com>
Cc: LSM List <linux-security-module@vger.kernel.org>,
	James Morris <jmorris@namei.org>,
	linux-audit@redhat.com,
	John Johansen <john.johansen@canonical.com>,
	Mimi Zohar <zohar@linux.ibm.com>,
	keescook@chromium.org, SElinux list <selinux@vger.kernel.org>,
	casey@schaufler-ca.com
Subject: Re: LSM stacking in next for 6.1?
Date: Thu, 15 Sep 2022 08:50:35 -0700	[thread overview]
Message-ID: <c2a2ca9b-3fc1-c034-6cc2-4400838c3354@schaufler-ca.com> (raw)
In-Reply-To: <b6ccb6a2-b6b0-b6ad-9f19-8ff3180d04ba@I-love.SAKURA.ne.jp>

On 9/15/2022 7:27 AM, Tetsuo Handa wrote:
> On 2022/09/14 22:56, Paul Moore wrote:
>> On Fri, Sep 9, 2022 at 7:33 AM Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote:
>>> Inclusion into upstream is far from the goal.
>> For better or worse, there is a long history of the upstream Linux
>> Kernel focusing only on in-tree kernel code, I see no reason why we
>> should change that now for LSMs.
> Because we can't afford accepting/maintaining whatever LSMs that are proposed.

We've done a reasonable job so far. Part of the process of getting a security
module upstream is demonstrating that it will (1) add value, (2) get used and
(3) continue to be maintained.  Several modules have been proposed that looked
like they would add value and get used, but that the author(s) had no means to
maintain.

> Do you think that we are going to accept/maintain whatever LSMs that are proposed
> if we get to the point to "The commitment I made to Paul some years ago now was
> that the stacking would eventually include making all combinations possible" ?
> I don't think so.

Neither do I. What I want to do is break down the existing technical barrier.
If Redhat wants to continue with their "SELinux only" position, that's their
call. If Ubuntu wants to take a more inclusive approach they should be able
to. That does not mean that every bizarre and/or unnatural security module
that's proposed should be included in the mainline.

> Although the upstream Linux Kernel focuses only on in-tree kernel code,
> CONFIG_MODULES=y is not limited for in-tree kernel code. It is used by e.g.
> device vendors to deliver their out-of-tree driver code.

I see this argument all the time. The response is "get your driver upstream".
Vendors/developers who whine "It's too hard" get no sympathy from me.

>  Then, I see no reason
> why we can't do the same for LSMs. We simply don't need to "provide efforts for
> fixing bugs in whatever LSMs"; we simply should "allow whatever LSMs to exist".
>

  reply	other threads:[~2022-09-15 15:50 UTC|newest]

Thread overview: 74+ 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:56   ` Paul Moore
2022-08-03  1:56     ` John Johansen
2022-08-03  2:15     ` Casey Schaufler
2022-08-03  2:33       ` Paul Moore
2022-08-03  2:34     ` Steve Grubb
2022-08-03  2:40       ` Paul Moore
2022-09-02 21:30     ` Paul Moore
2022-09-02 23:14       ` Casey Schaufler
2022-09-02 23:57         ` Casey Schaufler
2022-09-06 23:24         ` Paul Moore
2022-09-07  0:10           ` John Johansen
2022-09-07  0:39             ` Casey Schaufler
2022-09-07  0:50               ` John Johansen
2022-09-07 14:41             ` Paul Moore
2022-09-07 16:41               ` Casey Schaufler
2022-09-07 17:23                 ` John Johansen
2022-09-07 22:57                   ` Paul Moore
2022-09-07 23:27                 ` Paul Moore
2022-09-07 23:53                   ` Casey Schaufler
2022-09-08  0:19                     ` John Johansen
2022-09-08  3:57                     ` Paul Moore
2022-09-08 18:05                       ` Casey Schaufler
2022-09-08 18:35                         ` John Johansen
2022-09-08 19:32                         ` Paul Moore
2022-09-08 22:56                           ` Casey Schaufler
2022-09-10  4:17                             ` Tetsuo Handa
2022-09-12 17:37                               ` Casey Schaufler
2022-09-13 10:47                                 ` Tetsuo Handa
2022-09-13 14:45                                   ` Casey Schaufler
2022-09-14 13:57                                     ` Tetsuo Handa
2022-09-14 15:50                                       ` Casey Schaufler
2022-09-15 14:27                                         ` Tetsuo Handa
2022-09-15 14:54                                           ` John Johansen
2022-09-15  7:45                                       ` John Johansen
2022-09-15 14:27                                         ` Tetsuo Handa
2022-10-25  9:48                                       ` Tetsuo Handa
2022-10-25 10:26                                         ` John Johansen
2022-10-25 11:20                                           ` Tetsuo Handa
2022-10-25 14:12                                             ` Casey Schaufler
2022-10-25 22:12                                               ` Tetsuo Handa
2022-10-25 22:41                                                 ` Casey Schaufler
2022-10-26 10:19                                                   ` Tetsuo Handa
2022-10-26 15:30                                                     ` Casey Schaufler
2022-10-28 10:14                                                     ` John Johansen
2022-10-30  4:03                                                       ` Tetsuo Handa
2022-10-30  7:23                                                         ` John Johansen
2022-10-30 14:02                                                           ` Tetsuo Handa
2022-10-30 16:37                                                             ` Kees Cook
2022-10-30 20:56                                                               ` Casey Schaufler
2022-10-31 10:26                                                               ` Tetsuo Handa
2022-10-31 15:47                                                                 ` Casey Schaufler
2022-10-26 20:11                                             ` Paul Moore
2022-10-27  0:02                                               ` Tetsuo Handa
2022-10-28  9:50                                                 ` Paul Moore
2022-10-28 13:58                                                   ` Tetsuo Handa
2022-10-28 17:40                                                     ` Kees Cook
2022-10-29  9:33                                                       ` Tetsuo Handa
2022-09-14 13:42                             ` Paul Moore
2022-09-27 20:54                               ` Casey Schaufler
2022-09-27 22:37                                 ` Paul Moore
2022-09-07  0:31           ` Casey Schaufler
2022-09-07 15:13             ` Paul Moore
2022-09-07 17:08               ` Casey Schaufler
2022-09-07 23:04                 ` Paul Moore
2022-09-07 23:26                   ` Casey Schaufler
2022-09-08 15:18   ` Tetsuo Handa
2022-09-08 16:00     ` Casey Schaufler
2022-09-08 18:52     ` Paul Moore
2022-09-09 11:32       ` Tetsuo Handa
2022-09-14 13:56         ` Paul Moore
2022-09-15 14:27           ` Tetsuo Handa
2022-09-15 15:50             ` Casey Schaufler [this message]
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=c2a2ca9b-3fc1-c034-6cc2-4400838c3354@schaufler-ca.com \
    --to=casey@schaufler-ca.com \
    --cc=jmorris@namei.org \
    --cc=john.johansen@canonical.com \
    --cc=keescook@chromium.org \
    --cc=linux-audit@redhat.com \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).