Re: [RFC][PATCH 7/7] kref: Implement using refcount_t

[Kees Cook]

On Wed, Nov 16, 2016 at 12:31 AM, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
>
> * Kees Cook <keescook@xxxxxxxxxxxx> wrote:
>
>> On Tue, Nov 15, 2016 at 11:16 AM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>> >
>> >
>> > On 15 November 2016 19:06:28 CET, Kees Cook <keescook@xxxxxxxxxxxx> wrote:
>> >
>> >>I'll want to modify this in the future; I have a config already doing
>> >>"Bug on data structure corruption" that makes the warn/bug choice.
>> >>It'll need some massaging to fit into the new refcount_t checks, but
>> >>it should be okay -- there needs to be a way to complete the
>> >>saturation, etc, but still kill the offending process group.
>> >
>> > Ideally we'd create a new WARN like construct that continues in kernel space
>> > and terminates the process on return to user. That way there would be minimal
>> > kernel state corruption.
>
> Yeah, so the problem is that sometimes you are p0wned the moment you return to a
> corrupted stack, and some of these checks only detect corruption after the fact.

Exactly.

>> Right, though I'd like to be conservative about the kernel execution
>> continuing... I'll experiment with it.
>
> So what I'd love to see is to have a kernel option that re-introduces some
> historic root (and other) holes that can be exploited deterministically -
> obviously default disabled.
>
> I'd restrict this to reasonably 'deterministic' holes, and the exploits themselves
> could be somewhere in tools/. (Obviously only where the maintainers agree to host
> the code.) They wouldn't give a root shell, they'd only test whether they reached
> uid0 (or some other elevated privilege).

Have you looked at what lkdtm (CONFIG_LKDTM) does? It is explicitly a
collection of specific bad behaviors designed to trigger kernel flaw
mitigations.

> The advantages of such a suite would be:
>
>  - Uptodate tests on modern kernels: It would allow the (controlled) testing of
>    live kernel exploits even on the latest kernel - and would allow the testing of
>    various defensive measures.
>
>  - It would also make sure that defensive measures _remain_ effective against
>    similar categories of bugs. We've had defensive measure regressions in the
>    past, which was only discovered when the next exploit came out ...
>
>  - Testing of new defensive measures: It would help convert this whole
>    probabilistic and emotion driven "kernel protection" business into something
>    somewhat more rational. For example new protection mechanisms should have a
>    demonstrated ability to turn an existing exploit test into something less
>    dangerous.
>
>  - Education: It would teach kernel developers the various patterns of holes,
>    right in the code. Maybe being more directly exposed to what can get you p0wned
>    is both a stronger education force plus it could give people ideas about how to
>    protect better.
>
>  - I also think that collecting the various problems into a single place will give
>    us new insights into patterns, bug counts and various exploit techniques.

Unless I'm missing some detail of your idea, lkdtm already does all of this.

> The disadvantages would be:
>
>  - Maintenance: do we want to add extra (compiled out by default) code to the
>    kernel whose only purpose is to demonstrate certain types of bugs?
>
>  - Exposing exploits: Do we want to host a powerful collection of almost-exploits
>    in tools/ ? I don't think we have a choice but to face the problem directly -
>    but others might disagree.

They don't need to be exploits to test self-protection systems.

> I think most of the negatives could be kept small by starting small, allowing
> maintainers to explicitly opt-in, and observing the effects as we go. But YMMV.

I certainly think lkdtm could be further expanded, but I'd love to see
what you think is specifically missing...

-Kees

-- 
Kees Cook
Nexus Security