MCS separation is a key feature in sVirt technology. We currently use it for separation of our Virtual machines using libvirt to launch vms with different MCS labels. SELinux sandbox relies on it to separate out its sandboxes. OpenShift relies on this technology for separating users, and now docker uses it to separate containers. When I discover a hammer, everything looks like a nail. I recently saw this email. "I have trouble understanding how MCS labels work, they are not being enforced on my RHEL7 system even though selinux is "enforcing" and the policy used is "targeted". I don't think I should be able to access those files: $ ls -lZ /tmp/accounts-users /tmp/accounts-admin -rw-rw-r--. backup backup guest_u:object_r:user_tmp_t:s0:c3 /tmp/accounts-admin -rw-rw-r--. backup backup guest_u:object_r:user_tmp_t:s0:c99 /tmp/accounts-users backup@test ~ $ id uid=1000(backup) gid=1000(backup) groups=1000(backup) context=guest_u:guest_r:guest_t:s0:c1 root@test ~ # getenforce Enforcing I can still access them even though they have different labels (c3 and c99 as opposed to my user having c1). backup@test ~ $ cat /tmp/accounts-users domenico balance: -30 backup@test ~ $ cat /tmp/accounts-admin don't lend money to domenico Am I missing something? " MCS Is different then type enforcement. We decided not to apply MCS Separation to every type. We only apply it to the types that we plan on running in a Multi-Tennant way. Basically it is for objects that we want to share the same access to the system, but not to each other. We introduced an attribute called mcs_constrained_type. On my Fedora Rawhide box I can look for these types: seinfo -amcs_constrained_type -x mcs_constrained_type netlabel_peer_t docker_apache_t openshift_t openshift_app_t sandbox_min_t sandbox_x_t sandbox_web_t sandbox_net_t svirt_t svirt_tcg_t svirt_lxc_net_t svirt_qemu_net_t svirt_kvm_net_t If you add the mcs_constrained_type attribute to a type the kernel will start enforcing MCS separation on the type. Adding a policy like this will MCS confine guest_t # cat myguest.te policy_module(mymcs, 1.0) gen_require(` type guest_t; attribute mcs_constrained_type; ') typeattribute guest_t mcs_constrained_type; # make -f /usr/share/selinux/devel/Makefile # semodule -i myguest.pp Now I want to test this out. First i have to allow the guest_u user to use multiple MCS labels. You would not have to do this with non user types. # semanage user -m -r s0-s0:c0.c1023 guest_u Create content to read and change it MCS label # echo Read It > /tmp/test # chcon -l s0:c1,c2 /tmp/test # ls -Z /tmp/test unconfined_u:object_r:user_tmp_t:s0:c1,c2 /tmp/test Now login as a guest user # id -Z guest_u:guest_r:guest_t:s0:c1,c2 # cat /tmp/test Read It Now login as a guest user with a different MCS type # id -Z guest_u:guest_r:guest_t:s0:c3,c4 # cat /tmp/test cat: /tmp/test: Permission denied
Dan Walsh's Blog
- How come MCS Confinement is not working in SELinux even in enforcing mode?