From: Kees Cook <keescook@chromium.org>
To: John Johansen <john.johansen@canonical.com>,
Paul Moore <paul@paul-moore.com>
Cc: James Morris <jmorris@namei.org>,
Casey Schaufler <casey@schaufler-ca.com>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Stephen Smalley <sds@tycho.nsa.gov>,
"Schaufler, Casey" <casey.schaufler@intel.com>,
LSM <linux-security-module@vger.kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH security-next v3 18/29] LSM: Introduce lsm.enable= and lsm.disable=
Date: Mon, 1 Oct 2018 15:27:40 -0700 [thread overview]
Message-ID: <CAGXu5j+jzmFh-iuXDVHQTq7e=mftpfaqS-45TP_UR3B+qtGcLQ@mail.gmail.com> (raw)
In-Reply-To: <68e4e323-3216-7e77-2807-c3207126ae68@canonical.com>
On Mon, Oct 1, 2018 at 2:46 PM, John Johansen
<john.johansen@canonical.com> wrote:
> On 09/24/2018 05:18 PM, Kees Cook wrote:
>> This introduces the "lsm.enable=..." and "lsm.disable=..." boot parameters
>> which each can contain a comma-separated list of LSMs to enable or
>> disable, respectively. The string "all" matches all LSMs.
>>
>> This has very similar functionality to the existing per-LSM enable
>> handling ("apparmor.enabled=...", etc), but provides a centralized
>> place to perform the changes. These parameters take precedent over any
>> LSM-specific boot parameters.
>>
>> Disabling an LSM means it will not be considered when performing
>> initializations. Enabling an LSM means either undoing a previous
>> LSM-specific boot parameter disabling or a undoing a default-disabled
>> CONFIG setting.
>>
>> For example: "lsm.disable=apparmor apparmor.enabled=1" will result in
>> AppArmor being disabled. "selinux.enabled=0 lsm.enable=selinux" will
>> result in SELinux being enabled.
>>
>> Signed-off-by: Kees Cook <keescook@chromium.org>
>
> I don't like this. It brings about conflicting kernel params that are
> bound to confuse users. Its pretty easy for a user to understand that
> when they specify a parameter manually at boot, that it overrides the
> build time default. But conflicting kernel parameters are a lot harder
> to deal with.
>
> I prefer a plain enabled= list being an override of the default build
> time value. Where conflicts with LSM-specific configs always result in
> the LSM being disabled with a complaint about the conflict.
>
> Though I have yet to be convinced its worth the cost, I do recognize
> it is sometimes convenient to disable a single LSM, instead of typing
> in a whole list of what to enable. If we have to have conflicting
> kernel parameters I would prefer that the conflict throw up a warning
> and leaving the LSM with the conflicting config disabled.
Alright, let's drill down a bit more. I thought I had all the
requirements sorted out here. :)
AppArmor and SELinux are "special" here in that they have both:
- CONFIG for enable-ness
- boot param for enable-ness
Now, the way this worked in the past was that combined with
CONFIG_DEFAULT_SECURITY and the link-time ordering, this resulted in a
way to get the LSM enabled, skipped, etc. But it was highly CONFIG
dependent.
SELinux does:
#ifdef CONFIG_SECURITY_SELINUX_BOOTPARAM
int selinux_enabled = CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE;
static int __init selinux_enabled_setup(char *str)
{
unsigned long enabled;
if (!kstrtoul(str, 0, &enabled))
selinux_enabled = enabled ? 1 : 0;
return 1;
}
__setup("selinux=", selinux_enabled_setup);
#else
int selinux_enabled = 1;
#endif
...
if (!security_module_enable("selinux")) {
selinux_enabled = 0;
return 0;
}
if (!selinux_enabled) {
pr_info("SELinux: Disabled at boot.\n");
return 0;
}
AppArmor does:
/* Boot time disable flag */
static bool apparmor_enabled = CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE;
module_param_named(enabled, apparmor_enabled, bool, S_IRUGO);
static int __init apparmor_enabled_setup(char *str)
{
unsigned long enabled;
int error = kstrtoul(str, 0, &enabled);
if (!error)
apparmor_enabled = enabled ? 1 : 0;
return 1;
}
__setup("apparmor=", apparmor_enabled_setup);
...
if (!apparmor_enabled || !security_module_enable("apparmor")) {
aa_info_message("AppArmor disabled by boot time parameter");
apparmor_enabled = false;
return 0;
}
Smack and TOMOYO each do:
if (!security_module_enable("smack"))
return 0;
if (!security_module_enable("tomoyo"))
return 0;
Capability, Integrity, Yama, and LoadPin always run init. (This series
fixes LoadPin to separate enable vs enforce, so we can ignore its
"enable" setting, which isn't an "am I active?" boolean -- its init
was always run.) With the enable logic is lifted out of the LSMs, we
want to have "implicit enable" for 6 of 8 of the LSMs. (Which is why I
had originally suggested CONFIG_LSM_DISABLE, since the normal state is
enabled.) But given your feedback, I made this "implicit disable" and
added CONFIG_LSM_ENABLE instead. (For which "CONFIG_LSM_ENABLE=all"
gets the same results.)
I think, then, the first question (mainly for you and Paul) is:
Should we remove CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE and
CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE in favor of only
CONFIG_LSM_ENABLE?
The answer will affect the next question: what should be done with the
boot parameters? AppArmor has two ways to change enablement:
apparmor=0/1 and apparmor.enabled=0/1. SELinux just has selinux=0/1.
Should those be removed in favor of "lsm.enable=..."? (And if they're
not removed, how do people imagine they should interact?)
Thanks!
-Kees
--
Kees Cook
Pixel Security
next prev parent reply other threads:[~2018-10-01 22:27 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-25 0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
2018-09-25 0:18 ` [PATCH security-next v3 01/29] LSM: Correctly announce start of LSM initialization Kees Cook
2018-10-01 19:53 ` James Morris
2018-10-01 21:05 ` John Johansen
2018-09-25 0:18 ` [PATCH security-next v3 02/29] vmlinux.lds.h: Avoid copy/paste of security_init section Kees Cook
2018-10-01 19:56 ` James Morris
2018-10-01 21:05 ` John Johansen
2018-09-25 0:18 ` [PATCH security-next v3 03/29] LSM: Rename .security_initcall section to .lsm_info Kees Cook
2018-10-01 19:57 ` James Morris
2018-10-01 21:06 ` John Johansen
2018-09-25 0:18 ` [PATCH security-next v3 04/29] LSM: Remove initcall tracing Kees Cook
2018-09-26 16:35 ` Steven Rostedt
2018-09-26 18:35 ` Kees Cook
2018-09-30 23:25 ` Steven Rostedt
2018-10-01 1:01 ` Kees Cook
2018-10-01 21:07 ` John Johansen
2018-10-01 21:23 ` Steven Rostedt
2018-10-01 22:38 ` Kees Cook
2018-09-25 0:18 ` [PATCH security-next v3 05/29] LSM: Convert from initcall to struct lsm_info Kees Cook
2018-10-01 19:59 ` James Morris
2018-10-01 21:08 ` John Johansen
2018-09-25 0:18 ` [PATCH security-next v3 06/29] vmlinux.lds.h: Move LSM_TABLE into INIT_DATA Kees Cook
2018-10-01 21:10 ` John Johansen
2018-09-25 0:18 ` [PATCH security-next v3 07/29] LSM: Convert security_initcall() into DEFINE_LSM() Kees Cook
2018-10-01 21:12 ` John Johansen
2018-09-25 0:18 ` [PATCH security-next v3 08/29] LSM: Record LSM name in struct lsm_info Kees Cook
2018-10-01 21:13 ` John Johansen
2018-09-25 0:18 ` [PATCH security-next v3 09/29] LSM: Provide init debugging infrastructure Kees Cook
2018-10-01 21:14 ` John Johansen
2018-09-25 0:18 ` [PATCH security-next v3 10/29] LSM: Don't ignore initialization failures Kees Cook
2018-10-01 21:14 ` John Johansen
2018-09-25 0:18 ` [PATCH security-next v3 11/29] LSM: Introduce LSM_FLAG_LEGACY_MAJOR Kees Cook
2018-10-01 21:15 ` John Johansen
2018-09-25 0:18 ` [PATCH security-next v3 12/29] LSM: Provide separate ordered initialization Kees Cook
2018-10-01 21:17 ` John Johansen
2018-10-01 22:03 ` Kees Cook
2018-09-25 0:18 ` [PATCH security-next v3 13/29] LoadPin: Rename "enable" to "enforce" Kees Cook
2018-10-01 21:17 ` John Johansen
2018-09-25 0:18 ` [PATCH security-next v3 14/29] LSM: Plumb visibility into optional "enabled" state Kees Cook
2018-10-01 21:18 ` John Johansen
2018-10-01 21:47 ` James Morris
2018-10-01 21:56 ` Kees Cook
2018-10-01 22:20 ` John Johansen
2018-10-01 22:29 ` Kees Cook
2018-10-01 22:53 ` John Johansen
2018-09-25 0:18 ` [PATCH security-next v3 15/29] LSM: Lift LSM selection out of individual LSMs Kees Cook
2018-10-01 21:18 ` John Johansen
2018-09-25 0:18 ` [PATCH security-next v3 16/29] LSM: Prepare for arbitrary LSM enabling Kees Cook
2018-10-01 21:22 ` John Johansen
2018-09-25 0:18 ` [PATCH security-next v3 17/29] LSM: Introduce CONFIG_LSM_ENABLE Kees Cook
2018-10-01 21:34 ` John Johansen
2018-09-25 0:18 ` [PATCH security-next v3 18/29] LSM: Introduce lsm.enable= and lsm.disable= Kees Cook
2018-10-01 21:46 ` John Johansen
2018-10-01 22:27 ` Kees Cook [this message]
2018-10-01 22:48 ` John Johansen
2018-10-01 23:30 ` Kees Cook
2018-10-01 23:38 ` Kees Cook
2018-10-01 23:57 ` John Johansen
2018-10-01 23:44 ` John Johansen
2018-10-01 23:49 ` Kees Cook
2018-09-25 0:18 ` [PATCH security-next v3 19/29] LSM: Prepare for reorganizing "security=" logic Kees Cook
2018-10-01 21:47 ` John Johansen
2018-09-25 0:18 ` [PATCH security-next v3 20/29] LSM: Refactor "security=" in terms of enable/disable Kees Cook
2018-09-25 0:18 ` [PATCH security-next v3 21/29] LSM: Build ordered list of ordered LSMs for init Kees Cook
2018-09-25 0:18 ` [PATCH security-next v3 22/29] LSM: Introduce CONFIG_LSM_ORDER Kees Cook
2018-09-25 0:18 ` [PATCH security-next v3 23/29] LSM: Introduce "lsm.order=" for boottime ordering Kees Cook
2018-09-25 0:18 ` [PATCH security-next v3 24/29] LoadPin: Initialize as ordered LSM Kees Cook
2018-09-25 0:18 ` [PATCH security-next v3 25/29] Yama: " Kees Cook
2018-09-25 0:18 ` [PATCH security-next v3 26/29] LSM: Introduce enum lsm_order Kees Cook
2018-09-25 0:18 ` [PATCH security-next v3 27/29] capability: Initialize as LSM_ORDER_FIRST Kees Cook
2018-09-25 0:18 ` [PATCH security-next v3 28/29] LSM: Separate idea of "major" LSM from "exclusive" LSM Kees Cook
2018-09-25 0:18 ` [PATCH security-next v3 29/29] LSM: Add all exclusive LSMs to ordered initialization Kees Cook
2018-09-28 15:55 ` [PATCH security-next v3 00/29] LSM: Explict LSM ordering Casey Schaufler
2018-09-28 20:01 ` Kees Cook
2018-09-28 20:25 ` Stephen Smalley
2018-09-28 20:33 ` Stephen Smalley
2018-09-28 20:54 ` Kees Cook
2018-09-29 10:48 ` Tetsuo Handa
2018-09-29 18:18 ` Kees Cook
2018-09-30 2:36 ` Tetsuo Handa
2018-09-30 16:57 ` Kees Cook
2018-09-29 18:19 ` John Johansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGXu5j+jzmFh-iuXDVHQTq7e=mftpfaqS-45TP_UR3B+qtGcLQ@mail.gmail.com' \
--to=keescook@chromium.org \
--cc=casey.schaufler@intel.com \
--cc=casey@schaufler-ca.com \
--cc=corbet@lwn.net \
--cc=jmorris@namei.org \
--cc=john.johansen@canonical.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=sds@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).