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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0d23d1a5-d4af-debf-6b5f-aaaf698daaa8@schaufler-ca.com>
Date:   Wed, 6 Feb 2019 09:03:06 -0800
From:   Casey Schaufler <casey@...aufler-ca.com>
To:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Dmitry Vyukov <dvyukov@...gle.com>
Cc:     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@...ho.nsa.gov>,
        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.

On 2/6/2019 2:23 AM, Tetsuo Handa wrote:
> On 2019/02/04 17:07, Dmitry Vyukov wrote:
>> On Fri, Feb 1, 2019 at 2:09 PM Tetsuo Handa
>> <penguin-kernel@...ove.sakura.ne.jp> wrote:
>>> On 2019/02/01 19:50, Dmitry Vyukov wrote:
>>>> On Fri, Feb 1, 2019 at 11:44 AM Tetsuo Handa
>>>> <penguin-kernel@...ove.sakura.ne.jp> wrote:
>>>>> On 2019/02/01 19:09, Dmitry Vyukov wrote:
>>>>>> Thanks for the explanations.
>>>>>>
>>>>>> Here is the change that I've come up with:
>>>>>> https://github.com/google/syzkaller/commit/aa53be276dc84aa8b3825b3416542447ff82b41a
>>>>> You are not going to apply this updated config to upstream kernels now, are you?
>>>>> Removing CONFIG_DEFAULT_SECURITY="apparmor" from configs used by upstream kernels
>>>>> will cause failing to enable AppArmor (unless security=apparmor is specified).
>>>>
>>>> We do use  security=apparmor, see:
>>>> https://github.com/google/syzkaller/blob/master/dashboard/config/upstream-apparmor.cmdline
>>>> https://github.com/google/syzkaller/blob/master/dashboard/config/upstream-selinux.cmdline
>>>> https://github.com/google/syzkaller/blob/master/dashboard/config/upstream-smack.cmdline
>>>>
>>> Oh, security= parameter is explicitly specified on all targets?
>>> Then, we can abuse CONFIG_DEBUG_AID_FOR_SYZBOT option. ;-)
>>>
>>> LSM folks, may we use this patch for linux-next.git ?
>>> CONFIG_DEBUG_AID_FOR_SYZBOT is a linux-next.git-only kernel config option used by syzbot.
>>
>> Then we also need this on syzbot side, right? Otherwise it seems that
>> all instances will default to a single security module.
>> https://github.com/google/syzkaller/commit/ffec3d1894ffd05966b50efa49ca19af76c9ea81
>>
> Right.
>
> 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.
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.

> Furthermore, we could even avoid introducing lsm= parameter
> by allowing security= parameter to specify multiple LSM modules.

security=yama would work differently than it does today.
There would be no way to specify an exclusive module but
no minor modules.

If I have Yama and SELinux built in I could never disable Yama.

	security=selinux - would not disable Yama

whereas

	lsm=selinux      - would disable Yama

> For example, security= parameter
> is interpreted as a list of all LSM modules which should be enabled when it contains a comma,
> and it is interpreted as one of LSM_FLAG_LEGACY_MAJOR modules which should be enabled otherwise.
> Then, specifying security=selinux or security=smack or security=tomoyo or security=apparmor or
> security=none will respectively enable SELinux, Smack, TOMOYO, AppArmor, none of
> SELinux/Smack/TOMOYO/AppArmor. And specifying e.g. security=, will disable all LSM modules.

We debated the possibility of making the comma an indication
that we had an explicit list. It comes down to the "trailing
comma" syntax, where "security=selinux" and "security=selinux,"
mean different things. Consensus was that this is too clever,
and everyone would hate it.