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.
