danwalsh


Dan Walsh's Blog

Got SELinux?


Previous Entry Add to Memories Share Next Entry
How do I tell if an access was added in the latest policy release?
danwalsh

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.VERSION file. David could have executed a command like the following:


#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:s0-s0:c0.c1023 tcontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 tclass=capability

 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.


You are viewing danwalsh