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: <8f48e1d0-c109-f8a9-ea94-9659b16cae49@i-love.sakura.ne.jp>
Date:   Wed, 6 Feb 2019 19:23:03 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     Casey Schaufler <casey@...aufler-ca.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@...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 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.

Then, I think that it is straightforward (and easier to manage) to ignore security= parameter
when lsm= parameter is specified. Furthermore, we could even avoid introducing lsm= parameter
by allowing security= parameter to specify multiple LSM modules. 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.