Re: [Ksummit-discuss] [TOPIC] kernel hardening / self-protection / whatever

[ebiederm@xmission.com (Eric W. Biederman)]

Kees Cook <keescook@chromium.org> writes:

> On Mon, Jul 11, 2016 at 12:30 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> Andy Lutomirski <luto@amacapital.net> writes:
>>
>>> Are there useful things to discuss in person about hardening?  (I
>>> don't want to bikeshed about the name at the kernel summit if we can
>>> possibly avoid it.)
>>>
>>> Plausible sub-topics include:
>>>
>>>  - "USERCOPY" hardening
>>>
>>>  - Virtually mapped stacks (I'm hoping to have that in for x86 before
>>> kernel summit...)
>>>
>>>  - Refcount
>>>
>>> I don't how much of this really needs an in-person meeting, but maybe
>>> some if it would benefit.
>>
>> Given the history of the previous work on which much of this kernel
>> hardening work is inspired, I think it makes some sense to discuss what
>> is needed to get various features ready for mainline.
>
> This is a much larger topic, I think. The work being done already by
> the Kernel Self Protection Project is highlighting what's needed to
> bring various features into mainline. Generally they require a lot of
> chopping up into distinct pieces, expanding their portability to other
> architectures, more testing, etc.
>
>> Many kernel hardening features are perceived as having downsides affect
>> performance or code maintainability.  Which quite frankly is a security
>> issue of another flavor because if something does not work well, and or
>
> Sure, but I think this will be done on a case-by-case basis, as each
> thing has wildly different aspects. :)
>
>> is not maintainable after a while it won't get used.  Rarely are we in
>> the situation where defense against attack is the most important thing
>> that people who are deploying linux are worried about.
>
> Yup, of course. This is why I'm trying to make sure that things have
> either near-zero impact or are easily configurable.

Please make certain to leave a big fat comment explaining the security
that is added and why.

I have two brand new patchs that I received today or yesterday sitting
in my inbox to remove security features in the kernel.

A patch to remove the limit on /proc/self/exec only being able to be
changed once.

A patch to muck with kexec_file_load, and get it to accept a new flavor
of unsigned data.  At least I think that is what the patch is.

Eric