8.4. Deploying Customized Binary Policy
Building custom binary policy requires the policy source, but there are security risks to having the full policy source on a production server. Should an attacker gain root control, they could rebuild the policy to weaken or neutralize SELinux. For this reason, you want to use only binary policy on production servers.
If you are using binary policy provided by Red Hat, this is not an issue. You can manage the policy packages as you do any other software packages, such as through Red Hat Network. If you do customize your policy, you may want to manage it using RPM packages, either manually or as part of custom channels in Red Hat Network. Even if you manage the policy files by hand, as this procedure demonstrates, the underlying principles are the same.
Unlike software source code, SELinux policy is independent of the architecture of the system it is built on. You can have multiple development trees with vastly different policy needs expressed, all residing and built in a single development environment. In fact, it is recommended to use software version control, such as CVS, if you are going to be doing any measurable level of customization.
This short procedure demonstrates how to build and deploy policy from a development environment into a production environment.
Building and Deploying Policy
In your development environment, make a copy of the source tree for the policy you are working from. If you want to add a single daemon to confinement under the targeted policy, use /etc/selinux/targeted/src/policy/. If you want to work from a fully confined SELinux environment, obtain and use the strict source, which is usually at /etc/selinux/strict/.
# Copy the entire tree to a custom/ directory: cp -r /etc/selinux/targeted/ /etc/selinux/custom/
Build and test your policy. You can test locally on your development machine, or follow the outline of this procedure to deploy custom binary policy files to your test environment. Use apol to analyze your policy, as described in Section 6.3 Using apol for Policy Analysis.
When you are ready to deploy, use tar to pack your policy files. Notice that the source directory is not included.
tar -czvf tgt.tgz targeted/policy/ targeted/contexts/ \ targeted/booleans
Alternately, you can use star so that you can preserve the xattrs for the policy files. This is explained in Section 5.1.4 Make Backups or Archives That Retain Security Contexts. However, since you are going to initiate a relabel on boot anyway, you can use tar instead. The policy files unpack and gain the default file label such as system_u:object_r:default_t and are relabeled upon boot.
If this is the first time the custom policy has been deployed on this system, you need to configure SELinux to use the policy on the next boot.
Note It is extremely difficult to change policy without rebooting the system. The file system needs to be relabeled and every process starting with init needs to be restarted under the new policy. This is the reason rebooting is required for switching policy.
In /etc/selinux/config, change the value for SELINUXTYPE to the name of the new policy. The name is the same as the directory name in /etc/selinux. For example, the custom policy at /etc/selinux/custom/ has the value of SELINUXTYPE=custom.
You can do this using system-config-securitylevel. Under the SELinux tab, change the Policy Type: to custom. This area of system-config-securitylevel is automatically populated from the names of actual policy directories under /etc/selinux/.
Initiate a reboot and relabel.
touch /.autorelabel reboot
If you have troubles getting the custom policy to work on the test or production environment, work through the denials like you did when writing the policy in the first place.
Make sure the file system is labeled correctly. If you cannot touch /.autorelabel, either use setenforce 0 or boot into permissive mode.
You may need to boot into single-user mode and attempt a manual relabel of the file system. Although this is not normally recommended, it can be a working method to get enough labeling correct to have the /.autorelabel work correctly. You can read more about this at Section 5.2.2 Relabel a File System.
Work through the denial errors one at a time. You may need to temporarily install the policy source to relabel or rebuild the policy.