linux-kernel - Re: [PATCH] LSM: Allow syzbot to ignore security= parameter.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201902070230.x172UUG6002087@www262.sakura.ne.jp>
Date:   Thu, 07 Feb 2019 11:30:30 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To:     Casey Schaufler <casey@...aufler-ca.com>
Cc:     Dmitry Vyukov <dvyukov@...gle.com>,
        Paul Moore <paul@...l-moore.com>,
        Stephen Smalley <sds@...ho.nsa.gov>,
        syzbot <syzbot+21016130b0580a9de3b5@...kaller.appspotmail.com>,
        tyhicks@...onical.com, John Johansen <john.johansen@...onical.com>,
        James Morris <jmorris@...ei.org>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-security-module@...r.kernel.org,
        Serge Hallyn <serge@...lyn.com>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
        Jeffrey Vander Stoep <jeffv@...gle.com>,
        SELinux <selinux@...r.kernel.org>,
        Russell Coker <russell@...er.com.au>,
        Laurent Bigonville <bigon@...ian.org>,
        syzkaller <syzkaller@...glegroups.com>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] LSM: Allow syzbot to ignore security= parameter.

Casey Schaufler wrote:
> On 2/6/2019 2:23 AM, Tetsuo Handa wrote:
> > But as I update the documentation ( https://tomoyo.osdn.jp/2.6/chapter-3.html.en#3.6 ),
> > I came to think that we should ignore security= parameter when lsm= parameter is specified.
> >
> > Currently, it is possible to enable TOMOYO and only one of SELinux/Smack/AppArmor. Therefore,
> > it is possible to disable only TOMOYO by specifying security=selinux when we want to enable
> > only SELinux, by specifying security=smack when we want to enable only Smack, by specifying
> > security=apparmor when we want to enable only AppArmor. That is, we can use security= parameter
> > in order to specify the other LSM module which should not be disabled.
> >
> > But when it becomes possible to enable TOMOYO and more than one of SELinux/Smack/AppArmor,
> > we will no longer be able to selectively disable one LSM module using security= parameter, for
> > security= parameter is intended for specifying only one LSM module which should be enabled.
> > That is, we will need to use lsm= parameter in order to selectively disable LSM modules.
> 
> Yes. That is correct. The existing behavior of security= is maintained.

But the existing behavior of CONFIG_DEFAULT_SECURITY is not maintained.
This might cause a problem like

  commit e5a3b95f581da62e2054ef79d3be2d383e9ed664
  Author: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
  Date:   Sat Feb 14 11:46:56 2009 +0900

      TOMOYO: Don't create securityfs entries unless registered.

      TOMOYO should not create /sys/kernel/security/tomoyo/ interface unless
      TOMOYO is registered.

for Ubuntu users because Ubuntu kernels are built with

  CONFIG_SECURITY_SELINUX=y
  CONFIG_SECURITY_SMACK=y
  CONFIG_SECURITY_TOMOYO=y
  CONFIG_SECURITY_APPARMOR=y
  CONFIG_SECURITY_YAMA=y
  CONFIG_DEFAULT_SECURITY="apparmor"

. Due to CONFIG_DEFAULT_SECURITY="apparmor", majority of Ubuntu users are enabling
only AppArmor without explicitly specifying "security=apparmor".

Currently default CONFIG_LSM setting is

  "yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor"

but Ubuntu kernels would have to be built with non-default CONFIG_LSM setting like

  "yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo"

in order to make sure that AppArmor is by default chosen for the LSM_FLAG_EXCLUSIVE module.

Now that TOMOYO becomes a !LSM_FLAG_EXCLUSIVE module, not specifying "security=apparmor" will
automatically enable TOMOYO. And majority of Ubuntu users will unexpectedly encounter TOMOYO
messages. But removing "tomoyo" from CONFIG_LSM setting in order to save majority of Ubuntu
users from unexpectedly encountering TOMOYO messages also has a problem; Ubuntu users who want
to enable only TOMOYO from LSM_FLAG_LEGACY_MAJOR modules can specify "security=tomoyo", but
Ubuntu users who want to enable TOMOYO and one of SELinux,Smack,AppArmor (including syzbot)
will have to explicitly specify "lsm=" because "security=" can't allow enabling multiple
LSM_FLAG_LEGACY_MAJOR modules.

> The new behavior of lsm= is provided to allow general handling of a list
> of security modules. It uses the same form of data as CONFIG_LSM.
> 
> > Then, I think that it is straightforward (and easier to manage) to ignore security= parameter
> > when lsm= parameter is specified.
> 
> That reduces flexibility somewhat. If I am debugging security modules
> I may want to use lsm= to specify the order while using security= to
> identify a specific exclusive module. I could do that using lsm= by
> itself, but habits die hard.

"lsm=" can be used for identifying a specific exclusive module, and Ubuntu kernels would
have to use CONFIG_LSM (or "lsm=") for identifying the default exclusive module (in order
to allow enabling both TOMOYO and one of SELinux,Smack,AppArmor at the same time).

Since "security=" can't be used for selectively enable/disable more than one of
SELinux,Smack,TOMOYO,AppArmor, I think that recommending users to migrate to "lsm=" is the
better direction. And ignoring "security=" when "lsm=" is specified is easier to understand.