Deploying Customized Binary Policy - Red Hat ENTERPRISE LINUX 4 - SELINUX GUIDE Manual

Chapter 8. Customizing and Writing Policy
13. If the domain tries to access
tclass=udp_socket
needs to use. To diagnose, put these rules in
allow foo_t port_t:tcp_socket name_bind;
auditallow foo_t port_t:tcp_socket name_bind;
The
auditallow
14. Iterate through the remaining AVC denials. When they are resolved with new policy, you can
configure the unique port requirements for the
15. With the daemon started, determine which port
and see what port the daemon is connected to:
lsof | grep foo.*TCP
foo 2283 root
The daemon is listening on port 4242.
foo
16. Remove the generic
domain.
foo_t
type foo_port_t, port_type;
allow foo_t foo_port_t:tcp_socket name_bind;
Add this line to
$SELINUX_SRC/file_contexts
:
foo_t
ifdef('foo.te', 'portcon tcp 4242 system_u:object_r:foo_port_t')

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 cus-
tomize 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
1. In your development environment, make a copy of the source tree for the policy you are work-
ing from. If you want to add a single daemon to confinement under the targeted policy, use
/etc/selinux/targeted/src/policy/
environment, obtain and use the strict source, which is usually at
# Copy the entire tree to a custom/ directory:
cp -r /etc/selinux/targeted/ /etc/selinux/custom/
port_t
in the AVC log message, you need to determine what port number
rule helps you determine the nature of the port connection attempt.
3u IPv6 3192
rule, replacing it with a specific rule for a new port type based on the
port_t
, which relates to
:
foo.te
domain.
foo_t
is using. Look at the AVC allowed message
foo
TCP *:4242 (LISTEN)
. This reserves the port 4242 for the domain
. If you want to work from a fully confined SELinux
tclass=tcp_socket
/etc/selinux/strict/
101
or
foo
.