Dave Cantrell and Tom London have recently asked me about how can they tell if an Access was added in a recent release? Tom was trying to figure out whether he could remove a custom policy module and David has a bug report 508070 that stated the dhclient application was being denied sys_ptrace access, David noticed that he was not seeing the access any longer in Fedora 11, he asked if the access was allowed.
Here are a couple of ways you can check to see if an access was added to the current selinux policy.
One tool that I use quite often to examine policy for access is sesearch, part of the setools package. sesearch allows you to examine the installed SELinux policy file /etc/selinux/POLICYTYPE/policy/policy.VE
#sesearch --allow --dontaudit -s dhcpc_t -p sys_ptrace
Found 1 semantic av rules:
dontaudit dhcpc_t dhcpc_t : capability { dac_read_search sys_module sys_ptrace sys_tty_config } ;
* -s indicates the Source Type of the AVC.
* -p indicates the access.
In this case I checked both for allow rules and dontaudit rules.
You can also use sesearch to examine all the access available for a certain domain (process). If you wanted to see all of the access allowed for the dhcpc_t domain, you could just execute
sesearch --allow -s dhcpc_t
We have just added python bindings to sesearch for Fedora 12. We are starting to use these in setroubleshoot so we can suggest possible labels for a denied domain. For example, if someone sets up a directory /myweb in the / directory, it would be labeled default_t, then they tried to execute httpd using this directory they would get a denial saying httpd_t can not write default_t. The setroubleshoot plugin uses sesearch to find the types that httpd_t can write too, and suggests these as alternative file labels.
Another way you could check is to feed the avc message to audit2why (audit2allow -w)
# audit2why -i /tmp/t
node=apogee10.apogeect.com type=AVC msg=audit(1245934965.118:83): avc: denied { sys_ptrace } for pid=7132 comm="ps" capability=19 scontext=unconfined_u:system_r:dhcpc_t:s
Was caused by:
Unknown - should be dontaudit'd by active policy Possible mismatch between this policy and the one under which the audit message was generated.
Possible mismatch between current in-memory boolean settings vs. permanent ones.
I often use audit2why to examine different policies to see if this version of policy has the access. When I get a AVC bug report against RHEL5, I will check Fedora 11 to see if the access has been added.
audit2why can also tell you if there is a boolean to allow the access or if the access is caused by a constraint.
audit2why and sesearch are handy tools for examining SELinux policy.
