SELinux policy constraint declarations superficially resemble the constraints implemented via neverallow rules. However, they support a richer language for specifying constraints and, at the same time, have a narrower purpose: constraint declarations restrict the permissions that can be granted by an access-vector rule.

Figures Figure 8-1 through Figure 8-5 show the statement syntax, which is relatively complex. Fortunately, it’s unusual for a system administrator to need to modify the constraint declarations supplied by a sample SELinux policy.

Figure 8-1. Constraint declaration

Figure 8-2. Syntax of cexpr

Figure 8-3. Syntax of cexpr_prim

Figure 8-4. Syntax of user_names

Figure 8-5. Syntax of cnames

Constraint declarations impose restrictions on access-vector rules. Therefore, constraint declarations and access-vector rules share some syntactic elements. In particular, recall that access-vector rules involve two security contexts: a source context and a target context. In constraint declarations, you can refer to these contexts by using the special tokens summarized in Table 8-1.

u1

u2

r1

r2

t1

t2

Constraints declarations reside in the file constraints. Only a handful of constraints appear within the sample SELinux policies distributed with SELinux. For instance, the Fedora Core 2 implementation defines two constraints that restrict the ability to transition between user and role identities:

constrain process transition
    ( u1 == u2 
    or (t1 == privuser and t2 == userdomain )
    or (t1 == crond_t and t2 == user_crond_domain)
    or (t1 == userhelper_t)
    or (t1 == priv_system_role and u2 == system_u )
    );

constrain process transition
    ( r1 == r2 
    or ( t1 == privrole and t2 == userdomain )
    or (t1 == crond_t and t2 == user_crond_domain)
    or (t1 == userhelper_t)
    or (t1 == priv_system_role and r2 == system_r )
    );

The first constraint allows these identity changes to occur only if one of the following circumstances exists:

The second constraint operates analogously but constrains changes of role rather user identity. These constraints are intended to allow only safe transitions between user identities and roles. Hence, with only the few identified exceptions, only privileged users can transition to new identities or roles.

The policy of Fedora Core 2 also defines two constraints that restrict the ability to label objects with a user identity other than the current identity:

constrain { dir file lnk_file sock_file fifo_file chr_file blk_file } 
{ create relabelto relabelfrom }
    ( u1 == u2 or t1 == privowner );

constrain { tcp_socket udp_socket rawip_socket netlink_socket packet_socket 
unix_stream_socket unix_dgram_socket } 
{ create relabelto relabelfrom }
    ( u1 == u2 or t1 == privowner );

The first constraint restricts create, relabelto, and relabelfrom permissions over seven classes of file-like objects (dir, file, lnk_file, sock_file, fifo_file, chr_file, and blk_file). The operations are permitted only if they do not alter the user identity or the source type has the attribute privowner. The second constraint operates similarly but restricts operations over seven classes of network-related objects, rather than file-like objects.