Announcing security hardened kernels for testing

[John Richard Moser]

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



Matt Zimmerman wrote:
| On Tue, Jan 04, 2005 at 04:27:44PM +0000, Mike Hearn wrote:
|
|
|>On Tue, 04 Jan 2005 16:16:55 +0100, Martin Pitt wrote:
|>
|>>At the Mataro conference we discussed about various proactive security
|>>enhancements for Ubuntu [1]. Amongst other things we agreed to provide
|>>a security enhanced kernel that integrates PaX [2]. By separating
|>>writeable and executable memory, PaX prevents the exploitation of a
|>>whole class of common security vulnerabilities, the buffer overflows.
|>
|>Why was PaX chosen over exec-shield? The Linux community has much greater
|>experience with this set of patches than PaX, I know we
|>already dealt with some of the fallout of that in the Wine project.
|

(pay attention to the comments at the end about the age and development
status of PaX and ES)

|
| PaX is what Martin chose to work on; if you would like to experiment
with a
| different implementation, that is welcome as well.
|

PaX is an extended memory protection policy.  Exec Shield pretty much
attempts to provide the same NX functionality as a hardware-supported
platform with poor emulation.  In ES, if you mprotect() a high address
to be executable, the lower addresses are automatically executable due
to design flaws.

PaX is different because it does not mimic the AMD64 behavior on x86,
but rather employs a new memory protection policy altogether.  Memory
may no longer be PROT_WRITE|PROT_EXEC, and may never transition to
PROT_EXEC after its creation.  This is why PaX is actually useful on
non-x86 architectures.

PaX also emulates an NX bit on x86 better so that it really does what's
expected.  There are two methods, one having <1% overhead (constantly)
and another having variable overhead.  SEGMEXEC splits the address space
in half to do it, which allows for a <1% processing overhead and pretty
much no extra ram usage; while PAGEEXEC uses kernel-assisted MMU
walking, which can become a huge performance detriment in some cases.
SEGMEXEC is of course the recommended mode on x86 :)

On non-x86 architectures, PAGEEXEC uses the existant hardware NX bit, so
it imposes 0 overhead and thus is the recommended mode.  SEGMEXEC isn't
even available on these archs.  AMD64 and PPC are good examples.

[1] is a detailed explaination of PaX; [2] has a comparison of
technologies.  [3] is skeletal and needs more data.  It's notable that
PaX is from October, 2000, and still actively maintained; while ES and
W^X both are from May, 2003, and are still actively maintained.  PaX
therefore has seniority.  The PaX developer, unlike Ingo Molnar, is also
more of a security guy than a random kernel hack guy; Ingo is good at
making new preemption schemes and schedulers, and should probably focus
more on that.

In short, I believe PaX has more technical merit than Exec Shield.
Martin seems to agree with this, or is at least examining PaX to decide
for himself.

[1] http://en.wikipedia.org/wiki/PaX
[2] http://en.wikipedia.org/wiki/NX_bit
[3] http://en.wikipedia.org/wiki/Exec_Shield

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

iD4DBQFB3s3chDd4aOud5P8RAuq3AJjYdtKkH+6gcUZwrPvqqxA7qF00AJ9f2OD6
U+BOMB12hhWoCVvVE7H/aw==
=oUw0
-----END PGP SIGNATURE-----