RSBAC Grsec Selinux ProPolice and Pax

Christopher James Coleman ug97cjc at
Mon Jan 12 05:40:03 PST 2004

On Mon, 12 Jan 2004, Robert Connolly wrote:
> RSBAC and Grsec are each only supported by 1 developer. Selinux has several 
> large companies (immunix, redhat), a gov't agency support, and is the best 
> doccumented. Selinux is also able to work with Pax. I think Selinux has a 
> better life expectency. I didn't look into OpenWall.

GRSec has been around for a long time, as has Openwall. Openwall is a 
collection of a few measures against common exploits (link races, non-exec 
stack, ...). GRSec with version 2 is starting to offer RBAC on top of it's 
MAC and general hardening patches (GRSec has virtually everything Openwall 
has, and more - though replaces the non-exec stack with PaX, hoping to 
provide non-exec in more regions of memory). GRSec's role mechanism seems 
nowhere near as tightly integrated as the SELinux role concept - this is 
just my experience.

Aside from the possible vulnerabilities introduced by LSM, it is thought 
by many that LSM does not offer as complete of a system as kernel patching 
has previously delivered. See both the GRSec and RSBAC sites for a 
discussion on this.

At the end of the day, all of the systems are good and strong. What needs 
to be decided is a thorough security policy, and then looking into which 
is the best to implement that particular system in.

You comment on the amount of people developing each, but this is not 
completely relevant. Amon Ott and Brad Spengler have both managed very 
well as the sole programmers on there project, plus their communities 
provide them patches. SELinux is actually suffering slightly at their 
wider development. I have been subscribed to their mailing list for quite 
some time now, and people regularly step on each others toes.

> Grsec doesn't replace propolice. Pax/Grsec doesn't stop a return to libc 
> attack, Pax does however _prevent_ it by using a random function.

PaX is not designed to detect buffer overflows (as far as I understand 
it). It approaches protection from a different vector (that is transparent 
to most programs, though some have issues). It uses page/segment logic to 
make sure that memory that does not need to be executable is not. As you 
said, it also offers address space layout randomisation to help prevent 
common things such as a return-into-lib(c). I think that PaX and propolice 
go fairly well together.


More information about the hlfs-dev mailing list