Re: Grsec/PaX and Exec-shield
Thomas Viehmann wrote:
> So, please don't start insulting and accusing people for doing good work
> and proposing to do even more of it. If there are technical reasons that
> cause you to prefer that exec-shield does not become part of Debian's
> standard kernel, just put them on the table, but save us your conspiracy
I have seen noone accusing Russel from doing good work. The problem here is not
the good work, it is the things he says that can easilly be proven wrong.
For those who don't know, Adamantix is a Debian based distribution aiming to
create a highly secure Linux system. Most packages used in Adamantix are Debian
packages, including the kernel packages. Almost all packages have been
recompiled to make maximum use of the features PaX provides. Most programs run
fine. Only a handful of programs have problems. PaX has been a standard part of
the kernel in Adamantix for almost a year now. And it is used on mission
critical production systems with SLAs.
So what are the facts:
- PaX works, even on Debian kernels. Adamantix proves it.
- It provides more security than you get by installing the latest updates:
(Also proof that it works with Debian)
- It takes less time to apply the patch to the Debian kernel than the time
that is wasted on this discussion.
- The functionality can be tuned to specific needs by changing the kernel
configuration. That means, you can lower the security at a level comparable
to exec-shield if you want to.
- I have installed an Adamantix kernel on a Sarge system and the command line
stuff worked (didn't test it thoroughly). If packages follow the current
Debian policy, they should be mostly okay, even if the most restrictive
settings are used (like in the Adamantix kernel packages).
- You don't need to recompile if you don't want to. It only adds more
security if you do.
- PaX is available on different platforms and not only on i386. That is,
Alpha, PowerPC, HPPA and others.
- The design and implementation of PaX have been documented and are open to
public scrutiny: http://pageexec.virtualave.net/docs/index.html
This includes a description of limitations and design choices made, so you
can find out what trade-offs have been made (or haven't been made).
- PaX is independent from gr-security. And can be downloaded and applied to
the kernel without having to download gr-security.
- It is POSIX compliant. Programs that break are those who try to go beyond
the limits of POSIX. Most of them can be fixed. And those that cannot be
fixed (like the Java JDK, which is available as binary only) can be made
to run without much hassle. The package maintainer can take care of this,
it is as complicated as stripping binaries. We're talking about a handful
of programs here anyway.
- It is possible to have a fully functional distribution running on PaX. The
OpenBSD project proves that, it has features similar to PaX in the kernel,
and you can still run all the goodies.
- Running paxtest shows the differences between PaX and exec-shield. Everyone
is invited to run paxtest to see for yourself.
So far I have heard a lot of talk and a number of opinions on why PaX is bad.
But no proof. I can reasonably proof any of the above. But I have seen no such
proof from those who propose exec-shield so far, only opinions and cheap talk.
Opinions are like assholes, everyone has one. It is proof that counts.
The Adamantix Project
Taking high-security Linux out of the labs, and into the real world