Re: Linux Kernel Defence Map

[Kees Cook <keescook () chromium org>]

On Wed, Apr 4, 2018 at 9:15 AM, Alexander Popov <alex.popov () linux com> wrote:
> Linux kernel security is a very complex area. It would be nice to have some
> graphical representation of its current state. So I've created a Linux Kernel
> Defence Map showing the relations between:
>  - vulnerability classes / exploitation techniques,
>  - kernel defences,
>  - bug detection means.
>
> Link:
>    https://github.com/a13xp0p0v/linux-kernel-defence-map
>
> N.B. The node connections don't mean "full mitigation". These connections
> represent some kind of relation. So ideally, this map should help to navigate in
> documentation and Linux kernel sources.
>
> I wrote it in DOT language and generated the picture using GraphViz. So it is
> very pleasant to maintain this map with git.
>
> I would be grateful for any feedback.

This is cool; thanks for starting it! There are many nuances, details,
and caveats for a lot of the defense details, but I do like showing
the general relationships. Having some much longer accompanying text
would be nice to dive more deeply into each bubble in the chart. I'd
like to capture as much of that as possible in upstream's
Documentation/security/self-protection.rst! :)

Some initial thoughts in looking at the chart:


Upstream's SLAB_FREELIST_HARDENED is based on an "unnamed" (always-on)
grsecurity defense (see commit 2482ddec670f), so that should have a
dashed line, but I'm not sure how to name the new bubble.

KPTI defends against info leaks and "finding kernel objects" too, in a
way. Maybe just add a whole "side channels" bubble?

(I think "info leaks" and "finding kernel objects" may need some kind
of clarifying language for how they're different)

I didn't immediately parse that "Pointer Obfuscation" meant the %p
hashing, but I don't have a good suggestion about how to improve that
language. :)

Upstream's /proc/sys/net/core/bpf_jit_harden (see commit 4f3446bb809f)
and other JIT features (RO-setting, randomized offset, etc) are
designed to defend against JIT Abuse.

UDEREF and SMAP pointing at ret2usr+ROP is fine, but seems
"incomplete". Is there a good name for "reading user memory and
operating on a malicious structure"? It's a more narrow exploit
technique than ROP or executing userspace memory, but it's important
to cover.

I'd expect UDEREF to point at ret2usr, too.

Maybe add CPU_SW_DOMAIN_PAN and ARM64_SW_TTBR0_PAN to point at both
ret2usr and the new "access userspace" bubble?


-Kees

-- 
Kees Cook
Pixel Security