lkml.org 
[lkml]   [2018]   [Oct]   [4]   [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/03/2018 04:59 PM, Randy Dunlap wrote:
    > On 10/3/18 4:55 PM, Kees Cook wrote:
    >> On Wed, Oct 3, 2018 at 2:34 PM, James Morris <jmorris@namei.org> wrote:
    >>> On Wed, 3 Oct 2018, Kees Cook wrote:
    >>>
    >>>> On Wed, Oct 3, 2018 at 11:28 AM, James Morris <jmorris@namei.org> wrote:
    >>>>> On Wed, 3 Oct 2018, Kees Cook wrote:
    >>>>>
    >>>>>> On Wed, Oct 3, 2018 at 11:17 AM, James Morris <jmorris@namei.org> 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
    >>>> CONFIG_LSM_DISABLE.
    >>>
    >>> Ok, but it may end up being clearer, simpler, and thus more secure to just
    >>> have a single way to configure LSM.
    >>>
    >>> For example:
    >>>
    >>> - All LSMs which are built are NOT enabled by default
    >>>
    >>> - You specify enablement and order via a Kconfig:
    >>>
    >>> CONFIG_LSM="selinux,yama"
    >>>
    >>> - This can be entirely overridden by a boot param:
    >>>
    >>> lsm="apparmor,landlock"
    >>
    >> This doesn't work with how SELinux and AppArmor do their bootparams,
    >> unfortunately. (And Paul and Stephen have expressed that the
    >> documented selinux on/off must continue to work.) For example, let's
    >> say you've built an Ubuntu kernel with:
    >>
    >> CONFIG_SELINUX=y
    >> ...
    >> CONFIG_LSM="yama,apparmor"
    >>
    >> (i.e. you want SELinux available, but not enabled, so it's left out of
    >> CONFIG_LSM)
    >>
    >> Then someone boots the system with:
    >>
    >> selinux=1 security=selinux
    >>
    >> In what order does selinux get initialized relative to yama?
    >> (apparmor, flagged as a "legacy major", would have been disabled by
    >> the "security=" not matching it.)
    >>
    >
    > To me, "security=selinux" means SELinux and nothing else, so I think that
    > all of these params are inviting a lot of confusion.
    >
    > Sorry, I don't have a good answer for this.
    >

    Your not the only one. I have had users ask about why they are getting
    other security messures (yama in particular) when they specified a
    specific security=



    >>
    >> The LSM order needs to be defined externally to enablement because
    >> something may become enabled when not listed in the order.
    >>
    >> Now, maybe I misunderstood your earlier suggestion, and what you meant
    >> was to do something like:
    >>
    >> CONFIG_LSM="yama,apparmor,!selinux"
    >>
    >> to mean "put selinux here in the order, but don't enable it". Then the
    >> problem becomes what happens to an LSM that has been built in but not
    >> listed in CONFIG_LSM?
    >>
    >> Related to that, this means that when new LSMs are added, they will
    >> need to be added to any custom CONFIG_LSM= or lsm= parameters. If
    >> that's really how we have to go, I'll accept it, but I think it's a
    >> bit unfriendly. :P
    >>
    >> Another reason I don't like it is because it requires users to know
    >> about all the LSMs to make changes. One LSM can't be added/removed
    >> without specifying ALL of the LSMs. (i.e. there is no trivial way to
    >> enable/disable a single LSM without it growing its own enable/disable
    >> code as in SELinux/AppArmor. I'd hoped to make that easier for both
    >> users and developers.) Again, I can live with it, but I think it's
    >> unfriendly.
    >>
    >> I just want to have a direct I can go that meets all the requirements.
    >> :) I'm fine to ignore my sense of aesthetics if everyone can agree on
    >> the code.
    >
    >

    \
     
     \ /
      Last update: 2018-10-04 08:23    [W:2.688 / U:0.172 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site