Re: thoughts on kernel security issues

[Arjan van de Ven <arjan@infradead.org>]

> ES has been actively developed since it was poorly implemented in 2003.
>  PaX has been actively developed since it was poorly implemented in
> 2000.  PaX has had about 4 times longer to go from a poor
> proof-of-concept NX emulation patch based on the plex86 announcement to
> a full featured security system, and is written by a competant security
> developer rather than a competant scheduler developer.

I would call that an insult to Ingo.


> Split-out portions of PaX (and of ES) don't make sense.  

they do. Somewhat. 
> ASLR can be
> evaded pretty easily:  inject code, read %efp, find the GOT, read
> addresses.  The NX protections can be evaded by using ret2libc.  on x86,
> you need emulation to make an NX bit or the NX protections are useless.

actually modern x86 cpus have hardware NX. 

> PT_GNU_STACK annoys me :P  I'm more interested in 1) PaX' full set of
> markings (-ps for NX, -m for mprotect(), r for randmmap, x for
> randexec), 2) getting rid of the need for anything but -m, and 3)
> eliminating relocations.  Sometimes they don't patch GLIBC here and
> Firefox won't load flash or Java because they're PT_GNU_STACK and don't
> really need it (the java executables are marked, but the java plug-in
> doesn't need PT_GNU_STACK).

so remark them.

> 
> I guess it works on Exec Shield, but it frightens me that I have to
> audit every library an executable uses for a PT_GNU_STACK marking to see
> if it has an executable stack.

there is lsexec which does this automatic for you based on running
propcesses

> 
> Either or if it stops an exploit; there's no "stopping an exploit
> better," just stopping more of them and having fewer loopholes.  As I
> understand, ES' NX approximation fails if you relieve protections on a
> higher mapping

which is REALLY rare for programs to do

> -- which confuses me, isn't vsyscall() a high-address
> executable mapping, which would disable NX protection for the full
> address space?

just like PaX, execshield has to disable the vsyscall page.
Exec-Shield actually has the code to 1) move the vsyscall page down in
the address space and 2) randomize it per process, but that is inactive
right now since it needs a bit of help from the VM that isn't provided
anymore since 2.6.8 or so.


> PaX though gives me powerful, flexible administrative control over
> executable space protections as a privileged resource.
> mprotect(PROT_EXEC|PROT_WRITE) isn't something normal programs need; so
> it's not something I allow everyone to do.

it's a balance between compatibility and security. PaX strikes a
somewhat different balance from E-S. E-S goes a long way to avoid
breaking things that posix requires, even if they are silly and rare.
Apps don't DO   PROT_EXEC|PROT_WRITE normally after all.. so this added
"protect" is to a point artifical.