Chapter 8. Customizing and Writing Policy

97

3. Tell

audit2allow

to look in

dmesg

for denial messages, only since the last

load_policy

ran,

and write that to

domains/misc/local.te

:

audit2allow  d  l  o domains/misc/local.te

Look in

local.te

to be sure you don't have any duplicate rules. This is one reason for having

audit2allow

generate rules since the last

load_policy

, to keep from creating duplicates.

Once you have a complete set of working rules, you may want to look for ways to rewrite and

simplify the rules. One way to do this is to have

audit2allow

run one final time against the

entire set of denial messages. It looks for ways to consolidate rules into single lines:

# For example, two passes of audit2allow yield these rules:

allow httpd_t user_home_t:dir getattr;

allow httpd_t user_home_t:dir search;

# Looking at all of denials in $AUDIT_LOG

# may reveal some consolidation of rules, for example:

audit2allow  d  o domains/misc/consolidated_local.te

grep "user_home_t:dir" domains/misc/consolidated_local.te

allow httpd_t user_home_t:dir { getattr search };

4. Test your policy. Run

make load

and try your previously denied operation(s).

5. At this point you may need to do multiple iterations of these steps. Each additional rule allows

the operation to get one step further. You use the subsequent denial to write the next rule, and the

process continues.

After multiple iterations, you have a set of rules. Now you want to analyze the rules to be sure they

follow the principle of least privilege. This is where policy analysis with apol is useful, as described

in Section 6.3 Using apol for Policy Analysis.

To make your policy more elegant and efficient, look for macros that provide you the permissions

created by your new rules. You can then scrap one or more rules in favor of a macro, which simplifies

code reuse. Ideally, your rules benefit from bug fixes and enhancements to the entire policy because

your rules build on the policy as a privately maintained set of rules, relying upon the overall structure

of the parent policy.

For example, you are running the targeted policy on a newly installed server that is using your in 

house, custom configured

syslog ng

instead of

sysklogd

. You find that the policy for

syslogd

does not cover all of the non standard logging operations that you perform. Some of the additional

operational requirements for your

syslog ng

implementation are to open non standard files and

UDP and TCP ports, as well as call non standard routines.

The following are a sampling of the

avc: denied

messages you have received:

Jan 10 04:02:17 example kernel: audit(1009218137.102:0): \

avc:

denied

{ write } for

pid=6109 exe=/sbin/syslog ng \

name=kmsg dev=proc ino= 268435446 \

scontext=system_u:system_r:syslogd_t \

tcontext=system_u:object_r:proc_kmsg_t tclass=file

Jan 10 04:02:17 example kernel: audit(1009218137.105:0): \

avc:

denied

{ read } for

pid=16202 exe=/bin/bash name=mtab \

dev=dm 0 ino=7146016 scontext=system_u:system_r:syslogd_t \

tcontext=system_u:object_r:etc_runtime_t tclass=file

...

Jan 10 16:20:35 example kernel: audit(1009284205.210:0): \

avc:

denied

{ chown } for

pid=6109 exe=/sbin/syslog ng \

capability=0 scontext=system_u:system_r:syslogd_t \

tcontext=system_u:system_r:syslogd_t tclass=capability

Jan 10 16:20:35 example kernel: audit(1009284205.210:0): \

avc:

denied

{ fowner } for

pid=6109 exe=/sbin/syslog ng \

capability=3 scontext=system_u:system_r:syslogd_t \