Message-ID: <CAJfZ7=n5FOxHXMLRrDQ3F-kDqbYngNoYKcz6_PWi1rPa0_8WpA@mail.gmail.com>
Date:   Mon, 22 Feb 2021 22:12:46 +0100
From:   Nicolas Iooss <nicolas.iooss@....org>
To:     Casey Schaufler <casey@...aufler-ca.com>
Cc:     Mickaël Salaün <mic@...ikod.net>,
        James Morris <jmorris@...ei.org>,
        "Serge E . Hallyn" <serge@...lyn.com>,
        Kees Cook <keescook@...omium.org>,
        linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        Mickaël Salaün <mic@...ux.microsoft.com>
Subject: Re: [PATCH v3 1/1] security: Add CONFIG_LSM_AUTO to handle default
 LSM stack ordering

On Mon, Feb 22, 2021 at 9:32 PM Casey Schaufler <casey@...aufler-ca.com> wrote:
>
> On 2/22/2021 10:31 AM, Mickaël Salaün wrote:
> > On 22/02/2021 17:51, Casey Schaufler wrote:
> >> On 2/22/2021 7:06 AM, Mickaël Salaün wrote:
> >>> From: Mickaël Salaün <mic@...ux.microsoft.com>
> >>>
> >>> Add a new option CONFIG_LSM_AUTO to enable users to delegate default LSM
> >>> stacking order to kernel developers.  This enable to keep a consistent
> >>> order of enabled LSM when changing the LSM selection, especially when a
> >>> new LSM is added to the kernel.
> >> TL;DR - NAK
> >>
> >> Do you think that we might have considered this when stacking was
> >> introduced?
> > I didn't dig the detailed history of LSM stacking, but you are in Cc
> > because I know that you know. I may have though that the main goal of
> > the current LSM stacking implementation was to enable to stack existing
> > LSMs, which works well with this CONFIG_LSM list, but doesn't work as
> > well for new LSMs.
>
> It works just fine for new LSMs if you treat them as significant
> features which may have significant impact on the behavior of the
> system.
>
> >> Did you even consider the implications before sending
> >> the patch?
> > Yes, and it doesn't change much the current behavior without user
> > interaction. However, it gives the choice to users to choose how they
> > want their configuration to evolve.
>
> Automatic inclusions of new LSMs would be counter to existing practice.
> It won't work for "major" LSMs.
>
>
> >> This only makes any sense if you want to compile in
> >> AppArmor and/or Smack but always use SELinux. The existing Kconfig
> >> model handles that perfectly well.
> > This patch series doesn't change this behavior if the user doesn't want
> > it to change.
>
> Well, there's the question. If a distribution/system uses the new scheme
> "users" are going to get new LSMs spontaniously. If they don't it's up to
> the "user". Unsophisticated users won't want this, and the others don't
> need it.

Hello, sorry if I missed something simple but I did not understand
what "Automatic inclusions of new LSMs " and "get new LSMs
spontaniously" is about. If I understood the kernel practice
development correctly, when a new LSM will be included, it will have a
dedicated "config SECURITY_MYNEWLSM" which will be default to "n" in
order to respect the "principle of least astonishment". How could such
a new LSM be automatically/spontaneously added to the LSM list?

I understand that this is a tough issue and that the subject might
have been discussed a few years ago, and if that's the case, it would
be nice to have pointers to some clear documentation or past emails
(and it would be very very nice if the kernel documentation was
updated to document the current state of LSM stacking: for example
https://www.kernel.org/doc/html/v5.11/admin-guide/LSM/index.html still
documents the "security=" kernel parameter even though it conflicts
with CONFIG_LSM and can be ignored by the kernel in practise).

Thanks,
Nicolas

Powered by blists - more mailing lists