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
>> <[email protected]> wrote:
>>> On 2019/02/01 19:50, Dmitry Vyukov wrote:
>>>> On Fri, Feb 1, 2019 at 11:44 AM Tetsuo Handa
>>>> <[email protected]> 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.
