[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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.

Peter Busser
The Adamantix Project
Taking high-security Linux out of the labs, and into the real world

Reply to: