Compared to AppArmor, which one trains on specific processes,
Grsecurity's RBAC is the first to provide full system learning that can
automatically generate least-privilege policies covering the entire
system, without manual configuration.
If one is already familiar with writing AppArmor policies, then writing
policies for the grsec RBAC should come naturally. Many average users
are confused by AppArmor logs and don't know how to parse/interpret the
DENIED messages. I personally find that grsec's logging is easier to
read and that I'm able to quickly understand the nature of the violation.
Enabling AppArmor in Debian currently requires installing (sometimes
even building) some software, adding some boot parameters to the Linux
kernel through GRUB, and rebooting. Then you need to fiddle with the
profiles you want, set them to complain/enforce, etc.
If I have RBAC enabled in my grsec kernel, then the /dev/grsec device is
present and I can start using it right away (as long as gradm is installed).
Finally, since I'm already in the habit of quoting from grsecurity.net,
there is much that Grsecurity is able to do through not being reliant on
the Linux Security Modules framework:
"Grsecurity does not use LSM and thus is not constrained by the set
of hooks LSM provides. With this freedom it is able to implement a
number of unconventional features not possible in any LSM. Grsecurity
allows overriding and auto-learning of resource limits on a per-subject
basis, provides per-subject limits on the number of times a service can
crash in a given time interval, can limit access to roles by IP address,
tags policy violation logs with the IP address of the originator of the
violation, provides mandatory control over per-subject PaX flags,
supports policies on individual scripts run directly, and many more
features not available elsewhere."
