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]

Message-ID: <1a8ac9f4-8f82-5d3b-46ef-08801793443e@canonical.com>
Date:   Thu, 11 Oct 2018 17:26:35 -0700
From:   John Johansen <john.johansen@...onical.com>
To:     Jordan Glover <Golden_Miller83@...tonmail.ch>,
        Kees Cook <keescook@...omium.org>
Cc:     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

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.

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 is possible some of the LSMs in the list are not available for a
given kernel, but that is a problem with even the additive approach.
That is
  lsm=+apparmor

will not add apparmor to the set of LSMs available at run time if
apparmor has not been built into the kernel.


> I it's better to assume that average user has rather vague knowledge
> about lsm and don't delve deep into Kconfig's of their chosen distro.
> If they want to use "lsm=" their goal is to disable/enable on or more
> things. My proposition will work better for those. More advanced users
> still will may pass any "lsm=" string as they like, this having full
> control.
> 
> Jordan
>