linux-kernel - Re: [PATCH security-next v5 00/30] LSM: Explict ordering

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 12 Oct 2018 11:31:01 +0000
From:   Jordan Glover <Golden_Miller83@...tonmail.ch>
To:     John Johansen <john.johansen@...onical.com>
Cc:     Kees Cook <keescook@...omium.org>,
        James Morris <jmorris@...ei.org>,
        Casey Schaufler <casey@...aufler-ca.com>,
        Stephen Smalley <sds@...ho.nsa.gov>,
        Paul Moore <paul@...l-moore.com>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Mimi Zohar <zohar@...ux.vnet.ibm.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        LSM <linux-security-module@...r.kernel.org>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH security-next v5 00/30] LSM: Explict ordering

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, October 12, 2018 2:26 AM, John Johansen <john.johansen@...onical.com> wrote:

> On 10/11/2018 04:53 PM, Jordan Glover wrote:
>
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On Friday, October 12, 2018 1:09 AM, Kees Cook keescook@...omium.org wrote:
> >
> > > We've had things sort of like this proposed, but if you can convince
> > > James and others, I'm all for it. I think the standing objection from
> > > James and John about this is that the results of booting with
> > > "lsm=something" ends up depending on CONFIG_LSM= for that distro. So
> > > you end up with different behaviors instead of a consistent behavior
> > > across all distros.
> >
> > Ok, I'll try :)
> > The final lsm string contains two parts: Kconfig "CONFIG_LSM=" and boot
> > param "lsm=". Changing even only one of those parts also changes the
> > final string.
> > In case of distros, it's the "CONFIG_LSM=" which changes. Even when "lsm="
> > stays constant, the behavior will be different, example:
> > Distro A has: CONFIG_LSM=loadpin,integrity,selinux
> > Distro B has CONFIG_LSM=yama,loadpin,integrity,selinux
> > User on distro A wants to enable apparmor with:
> > lsm=loadpin,integrity,apparmor
> > which they do and add it to howto on wiki.
> > User on distro B want to enable apparmor, they found info on some wiki and do:
> > lsm=loadpin,integrity,apparmor
> > Puff, yama got disabled!
> > Above example shows why I think "consistent behavior across all distros"
> > argument for current approach is flawed - because distros aren't
> > consistent. In my proposition the user will just use "lsm=apparmor" and
> > it will consistently enable apparmor on all distros which is what they
> > really wanted, but all pre-existing differences across distros will
> > remain unchanged.
>
> Are you sure about that? I have had more than one question about
> security=X resulting in a system with more than just X enabled. Ie why
> is yama enabled when I specifically set security to X.
>

So, non-explicit list will match current "security=" behavior which users
are more familiar with. The current answer for this question is "because
your distro enabled it and you didn't disabled it. With non-explcit list
that answer will stay the same.

With explicit list, the question will be "why is yama disabled when I
enabled AppArmor with lsm=apparmor".

To ask both questions user have to know that something like "yama" exist
in first place.

As for question what users typically want you may look at search results
for "disable/enable yama" and "disable/enable apparmor/selinux". The
difference is several orders of magnitude. That's why I think typical user
just want to switch on/off one major lsm. I don't think anecdotal evidence
is representative here.

> There will certainly be cases where what you describe is exactly what
> the user wants. The problem is an explosion of options isn't good
> for the user either.
>
> What I want at the moment is the discussion about different ways to
> enable LSMs to be split off so this work can move forward.
>
> > The current approach requires that everyone who dares to touch "lsm="
> > knows about existence of all lsm, their enabled/disabled status on
> > target distro and their order. I doubt there are many people other
> > than recipients of this mail who fit for the above.
>
> Without having gotten a chance to review the current set of patches
> that was not what was discussed, it should only requires they know the
> set that they want.
>

"it should only requires they know the set that they want" is very
hard requirement and I don't think most users will pass this.
Especially when sets like:

lsm=yama,loadpin,integrity,apparmor
lsm=loadpin,integrity,yama,apparmor

will behave differently.

Jordan