CS406: Information Security

Each process on the system has a role and a subject attached to it. This section describes how a process is matched to a role and subject, and how matches are calculated against the objects and capabilities they use. Understanding the flow of matches is necessary for manually creating policies.

Role Hierarchy

When determining a role for a process, the RBAC system matches based on the following role hierarchy, from most specific to least specific:

 user -> group -> default

Both user and group roles are permitted to have the role_allow_ip attributes. When checking the UID or GID against the user or group role, respectively, the role_allow_ip attributes come into play. Imagine the following policy:

role user1 u
role_allow_ip 192.168.1.5
...

If someone attempted to log in to the machine as user1 from any IP address other than 192.168.1.5, they would not be assigned the user1 role. The matching system would then fall back on trying to find an acceptable group role, or if one could not be found, fall back to the default role.

Subject/Object Hierarchy

Hierarchy for subjects and objects involves matching a most specific pathname over a less specific pathname. So, if a /bin object exists, and a /bin/ping object exists, and a process is attempting to read /bin/ping, the /bin/ping object would be the one matching. If /bin/su were being accessed instead, then /bin would match.

The path from most specific to least specific pathname isn't linear however, particularly in the case of subjects using policy inheritance. Imagine the following policy:

role user1 u
 subject /
 / r
 /tmp rwcd
 /usr/bin rx
 /root r
 /root/test/blah r
 ...
 subject /usr/bin/specialbin
 /root/test rw
 ...

If /root/test/blah was being accessed by /usr/bin/specialbin, it would not be able to write to it. The reason for this is that when going from most specific to least specific for a given path (which involves stripping off each trailing path component and attempting a match for the resulting pathname), the matching algorithm will look (in order from most specific to least specific) in each of the subjects the current subject inherits from. In this case, the algorithm saw that no object existed for /root/test/blah in the /usr/bin/specialbin subject, so upon checking the subject for / it found a /root/test/blah object, thus resulting in the read-only permission.

When going from most specific to least specific, a globbed object such as /home/* is treated as less specific than /home/blah (if the requested access is for /home/blah). Globbed objects are matched in the order in which they're listed in the RBAC policy. So in the following example:

role user1 u
 subject /
 / r
 /home r
 /home/* r
 /home/test* rw
 ...

If a process were accessing /home/testing/somefile it would only be allowed to read it, since the /home/* rule was listed first. It was likely that the policy writer didn't intend this behavior (because the /home/test* rule would never match) so the /home/test* object should be swapped to the line the /home/* object is on.

Capability Hierarchy

When determining whether a capability is granted or not, the RBAC system works from most specific subject to least specific (in the case of policy inheritance). The first subject along that path that mentions the capability in question is the one that matches. To illustrate:

role user1 u
 subject /
 ...
 -CAP_ALL
 +CAP_NET_BIND_SERVICE
 subject /bin
 ...
 -CAP_NET_BIND_SERVICE
 subject /bin/su
 ...
 +CAP_SETUID
 +CAP_SETGID

In this example, /bin/su is able to use only CAP_SETUID and CAP_SETGID. A lookup on CAP_NET_BIND_SERVICE would fall back to the /bin subject, since /bin/su inherits from it and did not explicitly list a rule for CAP_NET_BIND_SERVICE. The /bin subject specifies that CAP_NET_BIND_SERVICE be disallowed. Matching against another capability, CAP_SYS_ADMIN for instance, would end up falling back to the / subject, where it would match -CAP_ALL and be denied.