Russel Coker
explained how to generate a local policy module from the error log.
Note that this approach (audit2allow) suffers from the same problems that
automatic policy learning suffers from (at least when not done very smartly).
The generated policy will exactly cover the behaviour you had during logging;
functionality that you didn't use is not covered, but misbehaviour that
occured during this time is.
Thats basically why SELinux doesn't use this autolearning approach considered
a "benefit" of AppArmor by some (as you've just seen, you can do that with
SELinux, too).
So let me show you an alternate way:
First of all, install the refpolicy-*-dev (from my experimental repository
on alioth) or selinux-policy-refpolicy-dev (unstable) packages.
Next you'll need an audit error to fix, e.g.:
audit(1173577161.426:3436296): avc: denied search for pid=23862 comm="amavisd-new" name="lib" dev=md2 ino=63745 scontext=system_u:system_r:amavis_t tcontext=system_u:object_r:var_lib_t tclass=dir
So that obviously is amavis trying to access /var/lib (you can verify this
by checking that ino= is the inode number of this directory). Looking at
/var/lib/amavis reveals that these files are labeled amavis_var_lib_t, so the
amavis policy is lacking just this simple tweak.
While Russel's approach would work fine, I'll try to show how this would be
fixed in the actual policy. The approach I use is documented somewhat in the
README.Debian at least in my packages.
I'll create a file named amavisfix.te:
policy_module(amavisfix,1.0.0);
require
type amavis_t;
files_list_var_lib( amavis_t )
The name "files_list_var_lib" was looked up in the
Refpolicy
API documentation. Granted, it takes some time to get used to their
naming scheme, but it's actually quite consistent.
Now I run
make -f /usr/share/selinux/refpolicy-strict/include/Makefile
and it creates a compiled module, amavisfix.pp, for me that I can install
with "semodule -i amavisfix.pp". The audit error should now be gone, and
amavis should function. I can now file a bug report with upstream that the
amavis policy is lacking "files_list_var_lib( amavis_t )" and they'll be
happy to add that. :-)
Note that "files_list_var_lib" has an actual semantic meaning what the
process is being granted; audit2allow lines are just technical representations
of the access violations seen.
Some of the more advanced SELinux IDEs might be able to suggest you
appropriate interfaces by looking at the audit errors; I havn't tried them yet.
