Previous Entry Share Next Entry
More small customizations to policy
Tim Fenn, has asked a question on the Fedora  SELinux mail list that I would like to expand to a wider audience.

> I recently upgraded a machine from FC6 to F7, and I used to use a
> /etc/dhclient-exit-hooks script to call some iptables functions after
> bringing up my external interface.  This used to work on FC6 as long
> as I setsebool -P dhcpc_disable_trans 1, but the policy in F7 no
> longer contains such a boolean, so dhclient-script is prevented from
> getattr/executing iptables.  Is there a simple fix to this, or do I
> need to write a policy and compile it?  If the latter, any pointers on
> what the policy file should contain?
> Thanks for any help,
> tim
We have decided in FC7 and beyond to remove the *_disable_trans booleans.  The problem with these booleans is they caused unexpected side effects.  When you disable a transition of a domain, all of the files created by that domain will not necessarily get created with the right context, this can cause other confined domains, that depend on those contexts to no longer work.  Causing more problems then disable_trans was there to help.  For an extreme example, if you set the boolean syslog_disable_trans,  the /dev/log will get created with a context type of device_t rather then devlog_t and all confined domains that syslog, will now blow up.

So what is the solution to the problem where a confined domain will not work with SELInux in enforcing mode?

Well you can still get the app to not transition, by simply setting the executables file context to bin_t,


This will cause the transitions to not happen.  Of course, this ends up with the same problem of disable_trans described above and will not survive a relabel.

A second and better option is to use audit2allow to create custom policy for your application.  The easiest way to do this is to simply execute
# grep BADAPP_t /var/log/audit/audit.log | audit2allow -M myBADDAPP
# semodule -i myBADAPP.pp

These commands  generates a bunch of allow rules and compiles and builds policy to allow them.  You might want to run your application in permissive mode to gather all the avc messages.

NOTE:  myBADDAPP.pp will replace all the rules of a previously install myBADDAPP.pp

While this is a good solution for a lot of people, it can sometimes write some bad policy.  It is a good idea to look at the generated policy (myBADAPP.te has the generated rules) and try to understand what the audit2allow command has generated.

  • Look for rules allowing writes to standard/default system file context (for example etc_t, usr_t, root_t, var_lib_t, var_run_t, var_log_t, lib_t, bin_t default_t )  you might have a labeling problem.  A restorecon on the file/directory that the confined application is trying to writte, might solve your problem.
  • Look for rules that allow the execution of a files labeled as an APP_exec_t, this usually indicates you need a rule allowing a transition to the other confined domain.  Adding a transtion rule APP_domtrans(myBADDAPP_t) will allow you confined app to run the second confined application under the correct domain and eliminate lots of AVC messages and prevent you from adding those rules to your confined domain.  This is an example of writing policy for least priveledge,  only give the allow rules to the domains that need them.

So lets get back to Tim's question:

Worst Solution:

He basically wants to be able to run iptables rules when he brings up and down his interfaces.  In FC6 he disabled the transition on dhcp which potentially could have left files like /etc/resolv.conf with the wrong label, causing lots of other problems.  In FC7, he can change the context to bin_t, but that could also end up with resolv.conf having a bad context. 

Better Solution:

Or he can run his start up in permissive mode.

# setenforce 0
service Network start
#setenforce 1
# grep dhcp /var/log/audit/audit.log | audit2allow -M mydhcp
# semodule -i mydchp.pp

This will give dhcp all of the power of iptables

Best solution,  Create a custom policy file that will allow dhcpc_t to transition to iptables_t.

Make sure you install the policy devel interfaces.

# yum install selinux-policy-devel

Create a te file that looks something like:

#cat mydhcp.te

# Declarations
require {
        type dhcpc_t;


Compile up the custom policy

# make -f /usr/share/selinux/devel/Makefile

Install the policy package

# semodule -i mydhcp.pp

Now you still may have additional avc's that you have to handle. and you can add those to your local policy packages.

# service network start
# audit2allow -R -m -l -i /var/log/audit/audit.log >> mydhcp.te

Note:  -R tells audit2allow to search for appropriate interface rather then just generate allow rules.   -l says only look at avc messages since the last time I generated policy.   -m Says generate all of the rules to generate a module. 

# make -f /usr/share/selinux/devel/Makefile
# semodule -i mydhcp.pp

Your rules should be more specify now to dhcpc and iptables_t, giving you a better custom policy.  If you don't understand the rules that are added, you can always ask someone to look at your custom policy.  One of the big advantages of Open Source is the many eyes theory.

  • 1
You can try audit2allow -R

Which attempts to find reference library functions that match the avc's. And it might find a transition interface. Audit2allow without any qualifier takes the straight AVC and just translates it directly to allow rules. The goal of sepolgen and audit2allow -R is to make better decisions.

Sometimes execing a app_exec_t without transition is a good idea. For example most confined domains, only transition when run from initrc_t, if run directly they stay in the current domain.

A good example of when you would want this is the cvs command. When you run it as a service you want it to be locked down and only able to r/w to cvs_data_t directrories, But when a user runs the same command, you want it to stay in the users domain, which allows it to r/w all directories the user can r/w.

  • 1

Log in

No account? Create an account