This is part 4 of a 5 part post on identifying and fixing an SELinux constraint violation. If you have not already read the previous parts, you may want to start at the beginning.

Preparing to give mount_t the attribute mcsreadall

Excellent, so we could grant mount_t the attribute 'mcsreadall' and our constraint violation would disappear. At this point, it is always a good idea to pause and consider the ramifications of a policy change, does the grant make sense, is it too broad or too narrow?

To answer that, we need to start off by getting a better idea of what other permissions the attribute 'mcsreadall' would grant mount_t. All we know right now is that it would permit "dir { search read ioctl lock }".

Searching through the policy turned up three additional grants:

mlsconstrain file { read ioctl lock execute execute_no_trans }
    (( h1 dom h2 ) or ( t1 == mcsreadall ) or 
    (( t1 != mcsuntrustedproc ) and (t2 == domain)));

mlsconstrain fifo_file { open }
    (( h1 dom h2 ) or ( t1 == mcsreadall ) or
     (( t1 != mcsuntrustedproc ) and ( t2 == domain )));

mlsconstrain { lnk_file chr_file blk_file sock_file } { getattr read ioctl }
    (( h1 dom h2 ) or ( t1 == mcsreadall ) or
     (( t1 != mcsuntrustedproc ) and (t2 == domain)));

Unsurprisingly, mcsreadall does roughly what one would assume, it allows processes of that type to preform all read operations on files, directories, fifos, links, character devices, block devices, and sockets. That is a little more access than we actually require in this case, mount has little need to read the content of a file outside its category, it would be nice to narrow the scope a bit. Unfortunately that brings us to a fork in the road, do we grant 'mount_t' access via the mcsreadall attribute, or do we create a different way to grant mount_t the access it needs?

It would certainly be possible to create something like 'mcssearchalldir' by adding the attribute, splitting up the constraints, adding the appropriate interface, and applying the new attribute to mount_t via the new interface. The question is, does the security benefit of such a change outweigh the added complexity, including the additional maintenance burden?

Adding additional granularity to the policy is a big question, a question probably best discussed with security experts or decided by the policy maintainer since making another attribute for constraint would practically require forking the policy. So, let's side step that one for now and assume granting mount_t the mcsreadall attribute constitutes an acceptable risk.

Next up, part 5: Giving mount_t the mcsreadall attribute.