[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <0b6c66ab-7cfe-da99-40e7-d36a81ac79ef@canonical.com>
Date: Mon, 1 Oct 2018 16:57:51 -0700
From: John Johansen <john.johansen@...onical.com>
To: Kees Cook <keescook@...omium.org>
Cc: Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>,
Casey Schaufler <casey@...aufler-ca.com>,
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
Stephen Smalley <sds@...ho.nsa.gov>,
"Schaufler, Casey" <casey.schaufler@...el.com>,
LSM <linux-security-module@...r.kernel.org>,
Jonathan Corbet <corbet@....net>,
"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 v3 18/29] LSM: Introduce lsm.enable= and
lsm.disable=
On 10/01/2018 04:38 PM, Kees Cook wrote:
> On Mon, Oct 1, 2018 at 4:30 PM, Kees Cook <keescook@...omium.org> wrote:
>> If we keep it, "apparmor=0 lsm_enable=apparmor" would mean it's
>> enabled. Is that okay?
>
> Actually, what the v3 series does right now is leaves AppArmor and
> SELinux alone -- whatever they configured for enable/disable is left
> alone.
>
> The problem I have is when processing CONFIG_LSM_ENABLE ... what do I
> do with the existing "enable" flag? It's set by both
> CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE and apparmor=0/1.
>
> Right now I can't tell the difference between someone booting with
> apparmor=0 or CONFIG_LSM_ENABLE not including apparmor.
>
> i.e. how do I mix CONFIG_LSM_ENABLE with apparmor=0/1? (assuming
> CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE has been removed)
>
right, Its a mess and confusing not just us but for the user. I think
it is worth considering removing the apparmor= and apparmor.enabled
options so that we can clean this up.
If we do keep it, there are three options
1. last option wins (above)
2. add more states so we can track the different combination (more
complex and probably not worth it)
3. we ignore any apparmor=1 (he default state) and only look at
whether apparmor.enabled has been toggled to 0 during setup.
At which point it stays that way.
if we keep it, I think an explicit disable should win, so
option 3, but I can live with 1.
Powered by blists - more mailing lists