[lkml]   [2018]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH security-next v4 23/32] selinux: Remove boot parameter
On Wed, Oct 3, 2018 at 11:28 AM, James Morris <> wrote:
> On Wed, 3 Oct 2018, Kees Cook wrote:
>> On Wed, Oct 3, 2018 at 11:17 AM, James Morris <> wrote:
>> > On Tue, 2 Oct 2018, John Johansen wrote:
>> >> To me a list like
>> >> lsm.enable=X,Y,Z
>> >
>> > What about even simpler:
>> >
>> > lsm=selinux,!apparmor,yama
>> We're going to have lsm.order=, so I'd like to keep it with a dot
>> separator (this makes it more like module parameters, too). You want
>> to mix enable/disable in the same string? That implies you'd want
>> implicit enabling (i.e. it complements the builtin enabling), which is
>> opposite from what John wanted.
> Why can't this be the order as well?

That was covered extensively in the earlier threads. It boils down to
making sure we do not create a pattern of leaving LSMs disabled by
default when they are added to the kernel. The v1 series used
security= like this:

+ security= [SECURITY] An ordered comma-separated list of
+ security modules to attempt to enable at boot. If
+ this boot parameter is not specified, only the
+ security modules asking for initialization will be
+ enabled (see CONFIG_DEFAULT_SECURITY). Duplicate
+ or invalid security modules will be ignored. The
+ capability module is always loaded first, without
+ regard to this parameter.

This meant booting "security=apparmor" would disable all the other
LSMs, which wasn't friendly at all. So "security=" was left alone (to
leave it to only select the "major" LSM: all major LSMs not matching
"security=" would be disabled). So I proposed "lsm.order=" to specify
the order things were going to be initialized in, but to avoid kernels
booting with newly added LSMs forced-off due to not being listed in
"lsm.order=", it had to have implicit fall-back for unlisted LSMs.
(i.e. anything missing from lsm.order would then follow their order in
CONFIG_LSM_ORDER, and anything missing there would fall back to
link-time ordering.) However, then the objection was raised that this
didn't provide a way to explicitly disable an LSM. So I proposed
lsm.enable/disable, and John argued for CONFIG_LSM_ENABLE over


Kees Cook
Pixel Security

 \ /
  Last update: 2018-10-03 22:12    [W:0.154 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site