Thread (57 messages) 57 messages, 6 authors, 2018-11-20

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

From: Jordan Glover <hidden>
Date: 2018-10-12 11:31:10
Also in: linux-arch, linux-security-module, lkml

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, October 12, 2018 2:26 AM, John Johansen [off-list ref] wrote:
On 10/11/2018 04:53 PM, Jordan Glover wrote:
quoted
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, October 12, 2018 1:09 AM, Kees Cook keescook@chromium.org wrote:
quoted
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help