Compared to problems with type enforcement (TE) restrictions or missing role allows, constraint violations are relatively rare, or at least they have been in my experience. There are a number of reasons for this, not the least of which is all of the excellent work put into the reference and Fedora/RHEL policies.

That infrequent occurrence unfortunately means there is not a lot of information readily available on how to address a constraint violation, if you ever hit one. (and I stress one here, in somewhere around 8 years of working with SELinux, I can only recall ever hitting a handful of constraint violations)

Due to length, this will be split into 5 parts.

  1. Identifying a constraint violation
  2. An example constraint violation issue
  3. Locating the troublesome constraint
  4. Preparing to give mount_t the attribute mcsreadall
  5. Giving mount_t the mcsreadall attribute

Identifying a constraint violation

Knowing you hit a constraint violation is now pretty simple, both audit2allow and audit2why explicitly say "This avc is a constraint violation." or "Was caused by: Policy constraint violation.".

Don't worry about the actual AVC mentioned here, we will get to that. This is just an example of the output from these tools when you are running up against a constraint violation.

$ echo 'avc:  denied  { search } for  pid=1597 comm="mount.nfs4"' \
'name="" dev=0:16 ino=2 scontext=system_u:system_r:mount_t:s0' \
'tcontext=system_u:object_r:nfs_t:s0:c20 tclass=dir' | audit2allow

#============= mount_t ==============
#!!!! This avc is a constraint violation.  You will need to add
an attribute to either the source or target type to make it

#Contraint rule: 
allow mount_t nfs_t:dir search;

The audit2allow output clearly states it is a constraint violation, unfortunately it is also a little misleading. After the ominous constraint warning, it then proceeds to list what looks like a TE allow rule which could normally be incorporated into the running system with '-M' or by using checkmodule + semodule_package + semodule. Don't be fooled, the constraint violation needs to be addressed in a different manner. audit2allow is showing the TE rule which would be needed if there wasn't a constraint violation, however that TE rule may already be part of the policy.

$ echo 'avc:  denied  { search } for  pid=1597 comm="mount.nfs4"' \
'name="" dev=0:16 ino=2 scontext=system_u:system_r:mount_t:s0' \
'tcontext=system_u:object_r:nfs_t:s0:c20 tclass=dir' | audit2why

avc:  denied  { search } for  pid=1597 comm="mount.nfs4" name=""
dev=0:16 ino=2 scontext=system_u:system_r:mount_t:s0
tcontext=system_u:object_r:nfs_t:s0:c20 tclass=dir

    Was caused by:
        Policy constraint violation.

        May require adding a type attribute to the domain or type
        to satisfy the constraint.

        Constraints are defined in the policy sources in
        policy/constraints (general), policy/mcs (MCS), and
        policy/mls (MLS).

audit2why is pretty clear, it event points you towards the location of the constraint definitions. However, neither of them really give a good idea of how to go about actually correcting the problem.

Next up, part 2: An example constraint violation issue.