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:13 +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

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, October 12, 2018 3:19 AM, John Johansen <john.johansen@...onical.com> wrote:
>
> It isn't perfect but it manages consistency across distros as best as
> can be achieved atm.
>
> Its just a fact that some LSMs are not going to be built into some
> kernels. The only way to deal with that is direct people to build
> their own kernels.
>
> The other major problem is that the current LSM stacking patches do
> not deal with "extreme" stacking. So doing
>
> lsm=+apparmor
>
> (I am going to stick with the + syntax atm to avoid confusion between
> adding and setting)
>
> assuming apparmor is builtin will not necessarily get you apparmor if
> another major lsm is enabled. Yes your specific proposal would as it
> specifies it overrides the current major, except that ordering
> important so if say landlock registers before apparmor, you may still
> not get apparmor.
>

I think this will be solved with LSM_ORDER_LAST or something like that
Kees proposed.

> You proposal does not provide a means to ensure you have only a
> specific set of LSMs enabled. As an LSM not explicitly listed in lsm=
> lsm=! may still be enabled. So the user is going to have to be aware
> of the initial LSMs list if they are trying to guarentee a specific
> security arrangement.
>

What about special marker like "!!" which will mean "this string is
explicit?

lsm=!!,apparmor

will enable apparmor and disable everything else.

lsm=!!,!apparmor or lsm=!!

will set the string empty and disable everything.

"!!" in "CONFIG_LSM" will take precedence over "!!" in "lsm=" which
will make "lsm=" totally ignored. This way distro could lock specific
lsm set which isn't possible with current approach.

CONFIG_LSM=!!,yama,loadpin,integrity,apparmor

> This violates one of the hard asks, and I will tell you that this will
> just mean there is going to be some distro patching to make sure it
> exists.
>

I think I can quess who will make those patches :)

> The current explicit list is more consistent, and it is amenable to
> being extended with + or ! as selective add/remove so we are not
> locked into only supporting an explicit list.
>

Jordan