[PATCH security-next v5 00/30] LSM: Explict ordering

[Jordan Glover]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, October 12, 2018 2:26 AM, John Johansen <john.johansen at canonical.com> wrote:

> On 10/11/2018 04:53 PM, Jordan Glover wrote:
>
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On Friday, October 12, 2018 1:09 AM, Kees Cook keescook at chromium.org wrote:
> >
> > > 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.
> >
> > Ok, I'll try :)
> > The final lsm string contains two parts: Kconfig "CONFIG_LSM=" and boot
> > param "lsm=". Changing even only one of those parts also changes the
> > final string.
> > In case of distros, it's the "CONFIG_LSM=" which changes. Even when "lsm="
> > stays constant, the behavior will be different, example:
> > Distro A has: CONFIG_LSM=loadpin,integrity,selinux
> > Distro B has CONFIG_LSM=yama,loadpin,integrity,selinux
> > User on distro A wants to enable apparmor with:
> > lsm=loadpin,integrity,apparmor
> > which they do and add it to howto on wiki.
> > User on distro B want to enable apparmor, they found info on some wiki and do:
> > lsm=loadpin,integrity,apparmor
> > Puff, yama got disabled!
> > Above example shows why I think "consistent behavior across all distros"
> > argument for current approach is flawed - because distros aren't
> > consistent. In my proposition the user will just use "lsm=apparmor" and
> > it will consistently enable apparmor on all distros which is what they
> > really wanted, but all pre-existing differences across distros will
> > remain unchanged.
>
> Are you sure about that? I have had more than one question about
> security=X resulting in a system with more than just X enabled. Ie why
> is yama enabled when I specifically set security to X.
>

So, non-explicit list will match current "security=" behavior which users
are more familiar with. The current answer for this question is "because
your distro enabled it and you didn't disabled it. With non-explcit list
that answer will stay the same.

With explicit list, the question will be "why is yama disabled when I
enabled AppArmor with lsm=apparmor".

To ask both questions user have to know that something like "yama" exist
in first place.

As for question what users typically want you may look at search results
for "disable/enable yama" and "disable/enable apparmor/selinux". The
difference is several orders of magnitude. That's why I think typical user
just want to switch on/off one major lsm. I don't think anecdotal evidence
is representative here.

> There will certainly be cases where what you describe is exactly what
> the user wants. The problem is an explosion of options isn't good
> for the user either.
>
> What I want at the moment is the discussion about different ways to
> enable LSMs to be split off so this work can move forward.
>
> > The current approach requires that everyone who dares to touch "lsm="
> > knows about existence of all lsm, their enabled/disabled status on
> > target distro and their order. I doubt there are many people other
> > than recipients of this mail who fit for the above.
>
> Without having gotten a chance to review the current set of patches
> that was not what was discussed, it should only requires they know the
> set that they want.
>

"it should only requires they know the set that they want" is very
hard requirement and I don't think most users will pass this.
Especially when sets like:

lsm=yama,loadpin,integrity,apparmor
lsm=loadpin,integrity,yama,apparmor

will behave differently.

Jordan