Automatic full system policy learning

Grsecurity's RBAC has provided the very first learning system that can automatically generate least-privilege full system policies without man ual configuration. While the default learning heuristics will provide secure results for most users while predicting future access needs, it also supports a simple human-readable configuration file to drive the policy generat ion. Have a directory specific to your system that you wish to ensure is protected by policy? A single line in the configuration file will create a security boundary around any process that reads or writes to files in that di rectory. Users will find that in most cases, full system learning will produce a more secure policy than one created by hand.

Academic analysis of secur ity properties of grsecurity's auto-learned policies

Human-readable policies and logs

If you've ever developed SELinux policies, grsecurity's RBAC policies will be a breath of fresh air. Our policies are similar in appearance to those of AppArmor, though more intuitive. Logs display full paths for the violating process and its parent and describes the nature of the violation in an easily-understandable way. You won't need to be an expert on system c all names and rummage through logs stuffed into the same restrictive template to determine the reason for a policy violation in grsecurity's RBAC system.

Excerpt of a grsecurity RBAC polic y

Intuitive design

The organization of grsecurity's RBAC policies makes intuitive sense. Roles apply to users or groups (with allowance for "special" roles that can be entered with or without authentication). These roles contain a collection of subjects which describe policies for binaries and scripts on the system. Subjects contain a collection of objects, which are the files, capab ilities, network sockets, and resources a process is permitted to use. Combined with the human-readable policies, many users find they are able to jump right in to creating meaningful security policies either through full sys tem learning or by using full system learning as a starting example policy.

Automated policy analysis

Unlike other access control systems, grsecurity's RBAC was not designed to be an all-permissive framework -- it has the specific purpose of lo cking down access to the entire system. Because it has a specific goal, it allows us to implement mandatory policy analysis that catches administrator mistakes and prevents an administrator from deploying a policy that would provide a false sense of security. Any errors found in the policy are described with human-readable, meaningful explanations of what kinds of attacks would be possible if the policy were allowed to be loaded (as it would be i n other access control systems).

Unconventional features

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.

Stackable with LSM

As grsecurity has never used LSM, it does not suffer from a major problem that LSM has been unable to resolve in over 15 years: it does not permit multiple LSMs to be enabled at the same time. Thus while SELinux's default policies cannot be used in conjunction with AppArmor, grsecurity can be used in combination with SELinux, AppArmor, or any other LSM if such a requirement exists.