| 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. Table 8-1. Special tokens used in constraint declarations | Token | Description | u1
| User given in source context | u2
| User given in target context | r1
| Role given in source context | r2
| Role given in target context | t1
| Type given in source context | t2
| Type given in target context |
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 user identity is unchanged. -
The source type has the privuser attribute and the target type has the userdomain attribute. -
The source type is crond_t and the target type has the attribute user_crond_domain (only the domains user_crond_t and sysadm_crond_t have this attribute). -
The source type is userhelper_t . -
The source type has the priv_system_role attribute and the target user is system_u . -
The priv_system_role attribute indicates domains that change role from a user role to system_r or change identity from a user identity to system_u . 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.  | Because constraints currently play a small role in typical SELinux policies, you likely don't need to understand them in complete detail. It's enough that you understand their function, which is to prevent certain changes to security contexts. | |
| 