CS406: Information Security

Policy generalization

There exist some features of the RBAC system to aid in simplification and generalization of policies. One of these is the recently added "replace" rule. The replace rule allows you to assign a string to a variable, and then use that variable within any subject or object pathname to have it replaced with the string. The syntax of replace rules are:

replace <variable name> <replace string>

So for example:

replace CVSROOT /home/cvs

 The defined variable can then be used as follows:

replace CVSROOT /home/cvs
replace PUBHTML public_html



subject $(CVSROOT)/bin/test o
 $(CVSROOT)/grsecurity r
 /home/spender/$(PUBHTML) r
 ... 

 The variables defined with replace rules can be reassigned at any location in the policy. All rules in the policy until another redefinition of the variable will use that new assigned value for the variable. For example:

replace CVSROOT /home/cvs
 $(CVSROOT)/grsecurity r
 replace CVSROOT /var/cvs
 $(CVSROOT)/test r

 would cause the following object rules to be created:

/home/cvs/grsecurity r
 /var/cvs/test r

Special Cases
There are some special cases you should know about when writing policies for the RBAC system.

There exist some unique accesses to filesystem objects that require specific object modes. For instance, a process that connects to a unix domain socket (/dev/log for example) will need "rw" set as the object mode for that socket.

Adding the setgid or setuid flag to a path requires the "m" object mode.

Creating a hard-link requires at minimum a "cl" object mode. The remaining object flags must match on the target and the source. So for instance, if a process is creating a hard-link from /bin/bash to /bin/bash2, example rules would be:

/bin/bash rx
/bin/bash2 rxcl

Creating a symlink requires the "wc" object mode.

Wildcarded Objects

One very useful feature of the RBAC system is the support of wildcards in objects. The "*" character matches zero or more characters, "?" matches exactly one character, and "[]" can be used to specify an inclusive or exclusive list or range of characters to match. Depending on how these wildcard characters are used, they have different effects. Here are four examples of the use of wildcards:

/dev/tty* rw
/home/*/bin rwx
/dev/tty[0-9] rw
/dev/tty? rw

The first example would match /dev/ttya, /dev/tty0, /dev/ttyS0, etc. Since a '*' at the end of a path can match the '/' character as well, if a '/dev/tty/somefile' path existed, the first example would match it also.

The second example would match /home/user1/bin, /home/user2/bin, etc. Note that this rule would not match the path /home/user1/test/bin as the wildcard characters will not match '/' unless it appears at the end of a path. To use the particular wildcarded object for this example, a /home object must exist as an "anchor" for the wildcarded object. If you forget to add one, gradm will remind you.

The third example would match /dev/tty0, /dev/tty1,..., /dev/tty9 and nothing else.

The fourth example would match /dev/ttya and /dev/tty0 just like the first example, but would not match /dev/ttyS0 since only one character can match the '?' wildcard.

Wildcards are evaluated at run-time, providing a powerful way of specifying and simplifying policy. Since wildcard matching is based off pathnames and not inode/device pairs though, they aren't intended to be used for objects which are known to be hard-linked at policy enable time.