Message-ID: <8251564f-ba7a-1777-a606-dec472b32f35@canonical.com>
Date:   Fri, 12 Oct 2018 11:24:27 -0700
From:   John Johansen <john.johansen@...onical.com>
To:     Jordan Glover <Golden_Miller83@...tonmail.ch>
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

On 10/12/2018 04:31 AM, Jordan Glover wrote:
> 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.
> 
possibly, though that was proposed with a config patchset different than
the current proposal.

>> 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?
> 
what about a special marker like "+" which means the string is addative
;)

> 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 :)
>

:)

Maybe but I am not the only one who is asking for it, and the majority of
the user bases I represent don't have this requirement. But with my distro
hat on it really is a requirement for a distro that wants to enable
users to have access to every lsm, but have a sane default set that
can be supported.

Its really not an insane security policy that new security measures
are vetted before they are enabled.

>> 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
> 

Powered by blists - more mailing lists