Role-Based Access Control (RBAC)
Role-based access control (RBAC) is a method that allows and restricts access to subjects or users based on the role of the user. When reading, pay attention to the description of an RBAC system and be able to describe the system, as well as to name the user that only RBAC can restrict. How does this one restriction increase the difficulty for an attacker to compromise the system? What is the set of rules called that manages the RBAC system? Although you will not be asked to create an RBAC policy, read through the rest of the document and try to follow the examples of how an RBAC policy is coded on a system.
10. Socket Policies
The RBAC system supports policies on what local IP addresses and ports can be reserved on the machine, as well as what remote hosts and ports can be communicated with. These two different accesses are abstracted to bind and connect rules,
respectively. The syntax for the rules is:
connect <IP/host>/<netmask>:<port/portrange> <socket type 1>... <socket type n> <proto 1>... <proto n> bind <IP/host>/<netmask>:<port/portrange> <socket type 1>... <socket type n> <proto 1>... <proto n> or: connect disabled bind disabled
"proto" can be any of the protocol names listed in /etc/protocol or "any_proto" to denote any protocol. "socket type" is most commonly "ip", "dgram", or "stream", but can also be "raw_sock", "rdm", or "any_sock" to denote any socket type. Most of the parameters for these rules are optional, particularly the netmask and port or port range. If a port is supplied, then at least an IP address of 0.0.0.0/0 needs to be supplied.
As with capability restrictions, resource restrictions, and many other RBAC features, if the socket policies are omitted for a given subject, then the subject is allowed to bind or connect to anything normally allowed by the system. Note though that if
a connect rule is given, then at least one bind rule must also be specified. Older versions of gradm (before the 9/16/09 2.1.14 release) will treat the unspecified
rule as a "disabled" rule, whereas new versions will generate an error on such policies.
 |
Unlike with file objects and capabilities, policy inheritance has not been implemented for socket policies. Therefore, the socket policies for a given subject are solely determined by that subject alone. |
Here are some example rules:
subject /usr/bin/ssh o ... connect 192.168.0.0/24:22 stream tcp connect ourdnsserver.com:53 dgram udp
In this example, ssh is allowed to connect to ssh servers anywhere on the class C 192.168.0.X network. It is also allowed to do DNS lookups through the host specified.
The hostname is resolved at the time the RBAC system is enabled.
subject /usr/bin/nc o ... bind 0.0.0.0/0:1024-65535 stream tcp connect 22.22.22.22:5190 stream tcp
In this example, netcat is allowed to listen on ports 1024 through 65535 on any local interface for TCP connections. It is also able to connect to TCP port 5190
of the 22.22.22.22 host.
subject /bin/strange o ... bind disabled connect 192.168.1.5:6000-6006 stream tcp
This example illustrates how you can have bind disabled but still specify connect rules, or conversely, have connect disabled and only specify bind rules.
As you can see from the examples above, you can have as many socket policies as you wish for a given subject, and as you'll read below there are some powerful extensions to the socket policies.
Per-interface Socket Policies
Rules such as:
bind eth1:80 stream tcp bind eth0#1:22 stream tcp
are allowed, giving you the ability to tie specific socket rules to a single interface (or by using the inverted rules mentioned below, all but one interface). Virtual interfaces are specified by the <ifname>#<vindex> syntax. If an interface is specified, no IP/netmask or host may be specified for the rule.
Inverted Socket Policies
Rules such as:
connect ! www.google.com:80 stream tcp
are allowed, which allows you to specify that a process can connect to anything except to port 80 of www.google.com with a stream TCP socket. The inverted socket matching also works on bind rules.