In the first chapter of this series i discussed SELinux users and explained some of the properties of the pre-defined SELinux Users. These profiles should cover most common usage scenarios. In the event that non of the pre-defined SELinux Users really fit a Linux users' profile one can decide to introduce a new restricted environment tailor made to the requirements that are determined.
The easiest way to do this is to base a new custom SELinux User Domain of off a existing one rather then create a new restricted environment from scratch. In this article i will show you how the create a Custom SELinux User Domain that is based of off the user_t restricted user environment. I will also show you ways to map this User Domain to a custom SELinux User so that Linux users can be mapped to this environment as described in the chapter called SELinux Users.
The case is the following: I have to add a restricted user to this system with requirements that are almost identical to the SELinux user user_u. The exeption is the this user also must be able to list the /var mountpoint.
To accomplish this, a new SELinux restricted user environment based of off the user_t User Domain should be created and installed with a SELinux Policy Module. We can extend this Policy Module to allow the listing of /var, and we can create a map for the new User Domain to a new SELinux user. We can also use the semanage command to manually map our new User Domain to a new SELinux User instead of adding this map to the Policy Module itself.
To complete this task i will need access to the SELinux Source Policy for referencing purposes. In this example i will use SELinux Source Policy that is publicly available and browsable at http://oss.tresys.com/projects/refpolicy/browser/trunk/. Although that in this example using upstream Tresys Reference Policy will suffice, it should be noted that in most cases one should refer to distribution specific SELinux Source Policy instead.
First let's have a look that the user_t User Domain SELinux Source Policy Module in the Tresys Source Policy here:
Our new User Domain called myuser_t will be based of off this user_t Policy Module. There will be some minor modifications to target the Fedora Distro specific policy instead:
mkdir ~/myuser; cd ~/myuser;
echo "policy_module(myuser, 0.0.1)" > myuser.te;
echo "role myuser_r;" >> myuser.te;
echo "userdom_unpriv_user_template(myuser)" >> myuser.te;
The policy above will create a new SELinux restricted User Domain that is almost identical to that of the user_t user environment that is mapped to the user_u SELinux User in a default installation.
Now i am going to add the policy that allows this environment access to list the /var mountpoint:
echo "files_list_var(myuser_t)" >> myuser.te;
Next i will programmatically map our myuser_t SELinux User Domain to a new SELinux user called myuser_u:
echo "gen_user(myuser_u, user, myuser_r, s0, s0)" >> myuser.te;
Note that the above policy is similar to running the following semanage command manually:
sudo semanage user -a -L s0 -r s0-s0 -R myuser_r -P user myuser_u
Policy for the customized User Domain is now ready. A binary SELinux Policy Module should now be build from the Source Policy:
make -f /usr/share/selinux/devel/Makefile
Alternatively the following commands can be used to build a binary Policy Module:
checkmodule -M -m -o myuser.mod myuser.te
semodule_package -o myuser.pp -m myuser.mod
Install the new binary Policy Module that has been created:
sudo semodule -i myuser.pp
Finally we should define default SELinux Security Contexts for our new SELinux user in order to let the login programs know which User Domain to use:
cp /etc/selinux/targeted/contexts/users/user_u /etc/selinux/targeted/contexts/users/myuser_u
sed -i 's/user/myuser/g' /etc/selinux/targeted/contexts/users/myuser_u
Now we can simply add a new Linux User and map this user to our fresh myuser_u SELinux User with the useradd command and -Z option or with the semanage command with the -m option.
Instead of modifying default SELinux Users and SELinux User Domains create new ones.
refer: man semodule, man semanage, man checkmodule, man semodule_package
Security Session at the 2017 Kernel Summit - For folks attending Open Source Summit Europe next week in Prague, note that there is a security session planned as part of the co-located Kernel Summit te...
2 dagen geleden