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.

[category: /en/linux/selinux | Permalink]