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 to
. 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.
