RSBAC Grsec Selinux ProPolice and Pax

Christopher James Coleman ug97cjc at
Sun Jan 18 05:24:48 PST 2004

On Sun, 18 Jan 2004, Archaic wrote:
> They both use MAC and RBAC, so what's different? What specifically can
> GRSec not do? Is the problem because of the daemon being chrooted?

SELinux's RBAC mechanism allows for automatic transition between zones,
whereas the GRSec RBAC mechanism allows only for manual transition through
the gradm2 application. However, this is not to say you cannot achieve the
same aims in GRSec. Also, remember that GRSec has many kernel patches on
top of what is described in their access systems - and some of these
perform hardening especially relating to the chroot environment (you can
see a list on their features page). If you want to `chroot without chroot'
in GRSec, then you can implement an ACL for the program that means the
entire filesystem it is not dealing with is `hidden' - ie, it cannot see
it, though information leakage as to the existance of files may be

As I stated before, SELinux/GRSec/RSBAC are all, pretty much, capable of
doing whatever the others can do. What needs to happen is for a security
policy to be defined in unambiguous terms. At that point it is then
easiest to see which system will achieve those aims with the most
certainty. That is not to say that all systems cannot be an option,
despite one system having been favoured.

I would also agree with `Archaic', and his arguments for the crossovers.
Yes, it will mean in some areas that two systems are guarding against the
same problem - but, the issue is that at least one succeeds, not that the
other may not get opportunity.

I have played with SELinux and GRSec. I would say that GRSec is definitely
the easier of the two, especially if somebody does not intend to do a lot
of reading. Especially for a beginner user, GRSec's ability to `learn' is
a great help in creating policy. SELinux policies tend to `feel' more
watertight, but I am not sure that they are particularly when it comes
down to it.

Just my thoughts,

More information about the hlfs-dev mailing list