100

Chapter 8. Customizing and Writing Policy

New Policy Writing Procedure

1. Work with a proper daemon under Red Hat Enterprise Linux. This means it has an initscript in

/etc/init.d/

and can be managed using

chkconfig

. For example, this procedure assumes

you are going to use the

service

command to control starting and stopping the daemon.

For this procedure, you are writing policy for the fictional

foo

package and it's associated

foo

daemon. Use a real daemon name in this place when developing your own policy.

2. Create a file at

$SELINUX_SRC/domains/program/foo.te

.

3. Put the daemon domain macro call in the file:

daemon_domain(foo)

4. Create the file contexts file,

$SELINUX_SRC/file_contexts/program/foo.fc

.

5. Put the first list of file contexts in

file.fc

. You may need to add to this later, depending on the

needs of the

foo

daemon.

/usr/bin/foo

system_u:object_r:foo_exec_t

/var/run/foo.pid

system_u:object_r:foo_var_run_t

/etc/foo.conf

system_u:object_r:foo_conf_t

6. Load the new policy with

make load

.

7. Label the

foo

files:

restorecon /usr/bin/foo /var/run/foo.pid /etc/foo.conf

8. Start the daemon,

service foo start

.

9. Examine your audit log for denial messages:

grep "avc:

denied" /var/log/messages > /tmp/avc_denials

cat /tmp/avc_denials

Familiarize yourself with the errors the daemon is generating. You are writing policy with the help

of

audit2allow

, but you need to understand the nature of the denials. You can also use seaudit

for viewing the log messages, as explained in Section 6.2 Using seaudit for Audit Log Analysis.

10. Use

audit2allow

to start the first round of policy rules.

audit2allow  l  i /var/log/messages  o \

/etc/selinux/targeted/src/policy/domains/program/foo.te

When looking at the generated rules, if you see a rule that gives the

foo_t

domain

read

access

to a file or directory, change the permission to read

{ read gettatr }

. The domain is likely to

need that permission if it already wants to read a file.

11. Look to see if the

foo_t

domain tries to create a network socket, that is,

udp_socket

or

tcp_socket

as the object class in the AVC denial:

avc:

denied

{ create } for

pid=7279 exe=/usr/bin/foo \

scontext=root:system_r:foo_t tcontext=root:system_r:foo_t\

tclass=udp_socket

If this is the case, then add the

can_network()

macro to

foo.te

:

can_network(foo_t)

12. Continue to iterate through the basic steps to generate all the rules you need. Each set of rules

added to the policy may reveal additional permission needs from the

foo_t

domain.

a. Start the daemon.

b. Read the AVC messages.

c. Write policy from the AVC messages, using

audit2allow

and your own knowledge,

looking for chances to use macros.

d. Load new policy.

e. Go back to beginning, starting the daemon ...