lkml.org 
[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
    From
    Date
    On 10/02/2018 03:06 PM, James Morris wrote:
    > On Tue, 2 Oct 2018, Kees Cook wrote:
    >
    >> On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
    >> <john.johansen@canonical.com> wrote:
    >>> Under the current scheme
    >>>
    >>> lsm.enabled=selinux
    >>>
    >>> could actually mean selinux,yama,loadpin,something_else are
    >>> enabled. If we extend this behavior to when full stacking lands
    >>>
    >>> lsm.enabled=selinux,yama
    >>>
    >>> might mean selinux,yama,apparmor,loadpin,something_else
    >>>
    >>> and what that list is will vary from kernel to kernel, which I think
    >>> is harder for the user than the lsm.enabled list being what is
    >>> actually enabled at boot
    >>
    >> Ah, I think I missed this in your earlier emails. What you don't like
    >> here is that "lsm.enable=" is additive. You want it to be explicit.
    >>
    >
    > This is a path to madness.
    >
    > How about enable flags set ONLY per LSM:
    >
    > lsm.selinux.enable=x
    > lsm.apparmor.enable=x
    >
    why add the lsm. prefix? I think if we go this route
    selinux.enable=x
    apparmor.enable=x

    is a little cleaner

    the question then becomes is this easier for users? Doing something
    similar to this was discussed earlier but its more tedious to type
    each of these out, and since they are separate options they can
    get spread out making it easy to miss one when you are changing
    your boot options.

    I honestly don't think we are going to come to a consensus on what is
    best for users because different sets of users have different priorities.
    But I do think we need to come up with something cleaner than v3

    > With no lsm.enable, and removing selinux=x and apparmor=x.
    >
    this will break the user api, not just the distro/builder kernel
    config. I do think it is probably worth doing, but not everyone agrees.

    > Yes this will break existing docs, but they can be updated for newer
    > kernel versions to say "replace selinux=0 with lsm.selinux.enable=0" from
    > kernel X onwards.
    >
    yes docs can be updated but it does take time to propagate out and their
    are always the dozens of blog, and forum posts etc that google will
    drag up that won't get updated

    > Surely distro packages and bootloaders are able to cope with changes to
    > kernel parameters?
    >
    yes, but users who have been taught to add certain incantations to their
    kernel parameters find it a lot harder

    > We can either take a one-time hit now, or build new usability debt, which
    > will confuse people forever.
    >

    I'm not opposed to taking a one-time hit for usability in the future.

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