Re: thoughts on kernel security issues

[John Richard Moser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Ingo Molnar wrote:
> * John Richard Moser <nigelenki@xxxxxxxxxxx> wrote:
> 
> 
>>>There was a kernel-based randomization patch floating around at some 
>>>point, though. I think it's part of PaX. That's the one I hated. 
>>
>>PaX and Exec Shield both have them; personally I believe PaX is a more
>>mature technology, since it's 1) still actively developed, and 2) been
>>around since late 2000.  The rest of the community dissagrees with me
>>of course, [...]
> 
> 
> might this disagreement be based on the fact that exec-shield _is_ being
> actively developed and is in active use in Fedora/RHEL, and that split
> out portions of exec-shield (e.g. flexmmap, PT_GNU_STACK, NX) are
> already in the upstream kernel?
> 

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.

Split-out portions of PaX (and of ES) don't make sense.  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.
 So every part prevents every other part from being pushed gently aside.

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).

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.

> (but no doubt PaX is fine and protects against exploits at least as
> effectively as (and in some cases more effectively than) exec-shield, so
> you've definitely not made a bad choice.)
> 

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

PaX disables vsyscall when using PAGEEXEC on x86 because (since 2.6.6 or
so) pipacs uses the same method as ExecShield as a best-effort, falling
back to kernel-assisted MMU walking if that fails.  Wasted effort with
vsyscall.

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.

Aside from that, I just trust the PaX developer more.  He's already got
a more developed product; he's a security developer instead of a
scheduler developer; and he reads CPU manuals for breakfast.  I think a
lot of PaX is developed without real hardware-- I know he at least
doesn't have an AMD64 (which is what I use PaX on-- and yes I use the
regression tests), and he does a fine job anyway.  This indicates to me
that this is a serious project with someone who knows what he's doing,
so I trust it more.

> 	Ingo
> 

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB7pbmhDd4aOud5P8RAuV2AJ44dE9gvqZ9xwfENaWA6Hm81ALcfQCaA7mk
QFZejeyBBLd1sdtSj3o4Avk=
=hNuJ
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/