[lkml]   [2018]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH security-next v5 00/30] LSM: Explict ordering
On Thu, Oct 11, 2018 at 3:58 PM, Jordan Glover
<> wrote:
> On Thursday, October 11, 2018 7:57 PM, Kees Cook <> wrote:
>> To switch to SELinux at boot time with
>> "CONFIG_LSM=yama,loadpin,integrity,apparmor", the old way continues to
>> work:
>> selinux=1 security=selinux
>> This will work still, since it will enable selinux (selinux=1) and
>> disable all other major LSMs (security=selinux).
>> The new way to enable selinux would be using
>> "lsm=yama,loadpin,integrity,selinux".
> It seems to me that legacy way is more user friendly than the new one.
> AppArmor and SElinux are households names but the rest may be enigmatic
> for most users and the need for explicit passing them all may be
> troublesome. Especially when the new ones like sara,landlock or cows :)
> will be incoming. Moreover to knew what you have to pass there, you need
> to look at CONFIG_LSM in kernel config (which will vary across distros
> and also mean copy-paste from the web source may won't work as expected)
> which again most users don't do.
> I think there is risk that users will end up with "lsm=selinux" without
> realizing that they may disable something along the way.
> I would prefer for "lsm=" to work as override to "CONFIG_LSM=" with
> below assumptions:
> I. lsm="$lsm" will append "$lsm" at the end of string. Before extreme
> stacking it will also remove the other major (explicit) lsm from it.
> II. lsm="!$lsm" will remove "$lsm" from the string.
> III. If "$lsm" already exist in the string, it's moved at the end of it
> (this will cover ordering).

We've had things sort of like this proposed, but if you can convince
James and others, I'm all for it. I think the standing objection from
James and John about this is that the results of booting with
"lsm=something" ends up depending on CONFIG_LSM= for that distro. So
you end up with different behaviors instead of a consistent behavior
across all distros.

Now, in the future blob and extreme stacking world, having the
explicit lsm= list shouldn't be too bad since LSMs will effectively
ALL be initialized -- but they'll be inactive since they have no
policy loaded.

But I still agree with you: I'd like a friendlier way to
disable/enable specific LSMs, but an explicit lsm= seems to be the
only way.

> It's possible that something lime this was discussed already
> but without full examples it was hard to me for tracking things.

It's been a painful thread. ;)


Kees Cook
Pixel Security

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