On Tue, Dec 17, 2019 at 12:53 AM Dmitry Vyukov <[email protected]> wrote:
> +Matthew for a lockdown question
> We are considering [ab]using lockdown (you knew this will happen!) for
> fuzzing kernel. LOCKDOWN_DEBUGFS is a no-go for us and we may want a
> few other things that may be fuzzing-specific.
> The current inflexibility comes from the global ordering of levels:
>
> if (kernel_locked_down >= level)
> if (kernel_locked_down >= what) {
>
> Is it done for performance? Or for simplicity?
Simplicity. Based on discussion, we didn't want the lockdown LSM to
enable arbitrary combinations of lockdown primitives, both because
that would make it extremely difficult for userland developers and
because it would make it extremely easy for local admins to
accidentally configure policies that didn't achieve the desired
outcome. There's no inherent problem in adding new options, but really
right now they should fall into cases where they're protecting either
the integrity of the kernel or preventing leakage of confidential
information from the kernel.
On 2020/01/03 4:57, Matthew Garrett wrote:
> On Tue, Dec 17, 2019 at 12:53 AM Dmitry Vyukov <[email protected]> wrote:
>> +Matthew for a lockdown question
>> We are considering [ab]using lockdown (you knew this will happen!) for
>> fuzzing kernel. LOCKDOWN_DEBUGFS is a no-go for us and we may want a
>> few other things that may be fuzzing-specific.
>> The current inflexibility comes from the global ordering of levels:
>>
>> if (kernel_locked_down >= level)
>> if (kernel_locked_down >= what) {
>>
>> Is it done for performance? Or for simplicity?
>
> Simplicity. Based on discussion, we didn't want the lockdown LSM to
> enable arbitrary combinations of lockdown primitives, both because
> that would make it extremely difficult for userland developers and
> because it would make it extremely easy for local admins to
> accidentally configure policies that didn't achieve the desired
> outcome. There's no inherent problem in adding new options, but really
> right now they should fall into cases where they're protecting either
> the integrity of the kernel or preventing leakage of confidential
> information from the kernel.
>
Can we resume this topic?
I think build-time lockdown (i.e. kernel config option) is more reliable
and easier to use.
On 2020/02/18 19:54, Tetsuo Handa wrote:
> On 2020/01/03 4:57, Matthew Garrett wrote:
>> On Tue, Dec 17, 2019 at 12:53 AM Dmitry Vyukov <[email protected]> wrote:
>>> +Matthew for a lockdown question
>>> We are considering [ab]using lockdown (you knew this will happen!) for
>>> fuzzing kernel. LOCKDOWN_DEBUGFS is a no-go for us and we may want a
>>> few other things that may be fuzzing-specific.
>>> The current inflexibility comes from the global ordering of levels:
>>>
>>> if (kernel_locked_down >= level)
>>> if (kernel_locked_down >= what) {
>>>
>>> Is it done for performance? Or for simplicity?
>>
>> Simplicity. Based on discussion, we didn't want the lockdown LSM to
>> enable arbitrary combinations of lockdown primitives, both because
>> that would make it extremely difficult for userland developers and
>> because it would make it extremely easy for local admins to
>> accidentally configure policies that didn't achieve the desired
>> outcome. There's no inherent problem in adding new options, but really
>> right now they should fall into cases where they're protecting either
>> the integrity of the kernel or preventing leakage of confidential
>> information from the kernel.
>>
>
> Can we resume this topic?
>
> I think build-time lockdown (i.e. kernel config option) is more reliable
> and easier to use.
>
Here is an example of need to lockdown specific ations. Can we proceed?
https://lkml.kernel.org/r/CACT4Y+azQXLcPqtJG9zbj8hxqw4jE3dcwUj5T06bdL3uMaZk+Q@mail.gmail.com
On Thu, Feb 27, 2020 at 2:11 PM Tetsuo Handa
<[email protected]> wrote:
> Here is an example of need to lockdown specific ations. Can we proceed?
As I said before, unless the thing being blocked is a primitive that's
intended to allow modification or reading of kernel memory (directly
or indirectly), I don't think lockdown is the right place for it to
be.