SELinux [Electronic resources] نسخه متنی

8.1 Constraint Declarations

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.