Chapter 8. Customizing and Writing Policy

101

13. If the domain tries to access

port_t

, which relates to

tclass=tcp_socket

or

tclass=udp_socket

in the AVC log message, you need to determine what port number

foo

needs to use. To diagnose, put these rules in

foo.te

:

allow foo_t port_t:tcp_socket name_bind;

auditallow foo_t port_t:tcp_socket name_bind;

The

auditallow

rule helps you determine the nature of the port connection attempt.

14. Iterate through the remaining AVC denials. When they are resolved with new policy, you can

configure the unique port requirements for the

foo_t

domain.

15. With the daemon started, determine which port

foo

is using. Look at the AVC allowed message

and see what port the daemon is connected to:

lsof | grep foo.*TCP

foo

2283

root

3u

IPv6

3192

TCP *:4242 (LISTEN)

The

foo

daemon is listening on port 4242.

16. Remove the generic

port_t

rule, replacing it with a specific rule for a new port type based on the

foo_t

domain.

type foo_port_t, port_type;

allow foo_t foo_port_t:tcp_socket name_bind;

Add this line to

$SELINUX_SRC/file_contexts

. This reserves the port 4242 for the domain

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/

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