RSBAC Grsec Selinux ProPolice and Pax
Christopher James Coleman
ug97cjc at cs.bham.ac.uk
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