SELinux tips 'n tricks

[gharris999]

Managing SELinux on a home audio server has seemed like such a daunting task that I've always just disabled it on my fedora boxes. I've bitten the bullet this time around, though. Frankly, I had to do a heck-of-a-lot of googling to get things right and never did find a clear 'n simple tutorial that was easy to wade through and provided just enough info to get the job done. Everything out there seemed like info-overkill...much like SELinux itself.

Sites I did visit that were helpful, though, included:

The UnOfficial SELinux FAQ: http://www.crypt.gen.nz/selinux/faq.html
..and
Dan Wash's Blog: http://danwalsh.livejournal.com/24750.html

Let's have this thread be a clearing house for information about how to get SBS working properly with SELinux. Please post 'recipes' that work below.

[gharris999]

If you have an app that persistently causes SELinux to complain, and yet you trust the app completely (as in 'you wrote it'), here's an easy way to hit SELinux on the head with a hammer and tell it to shut-up:

Problem Example:

My SrvrPowerCtrl plugin for SBS does a system call to ifconig when it's first initialized. It does this to get the server's mac address and it offers the mac address up to clients who ask for it via [srvrpowerctrl status] cli requests. A client could use this info to, for instance, subsequently WOL the server.

Anyway..SELinux consistently complained about this behaviour without actually denying the call, even though the call is innocuous. From /var/log/audit/audit.log:


type=AVC msg=audit(1264237025.806:145): avc: denied { read write } for pid=4307 comm="ifconfig" path="socket:[124523]" dev=sockfs ino=124523 scontext=unconfined_u:system_r:ifconfig_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=tcp_socket
type=AVC msg=audit(1264237025.806:145): avc: denied { read } for pid=4307 comm="ifconfig" path="/var/lib/squeezecenter_trunk/cache/InstalledPlugins/Plugins/SrvrPowerCtrl/Plugin.pm" dev=dm-0 ino=524930 scontext=unconfined_u:system_r:ifconfig_t:s0 tcontext=unconfined_u:object_r:mysqld_db_t:s0 tclass=file

The fix:

Assuming that you don't have multiple SELinux complaints going on..i.e. that you have an isolated problem, try this:

1). Boot the server, run the app, and wait for the SELinux TroubleShooter to report the alert.

2). Open a terminal and, as root, do:

# audit2allow -b

Audit2allow will propose a rule to 'fix' all the alerts raised since the last boot. Inspect the output of that command and see if it looks ok. E.G.: this is the rule that it proposed in order to fix my SrvrPowerCtrl problem:


#============= ifconfig_t ==============
allow ifconfig_t initrc_t:tcp_socket { read write };
allow ifconfig_t mysqld_db_t:file read;

#============= initrc_t ==============
#!!!! This avc can be allowed using the boolean 'allow_execmod'

allow initrc_t lib_t:file execmod;

Personally, I don't really understand how permissive a rule is being proposed there. Any comments as to whether this opens up a gaping security hole?

Anyway, let's apply the fix:

Run:

# audit2allow -b -M myfix

Audit2allow generates two files: myfix.te which is the 'type enforcement' text file version of the proposed new rule:


module myfix 1.0;

require {
type ifconfig_t;
type mysqld_db_t;
type initrc_t;
type lib_t;
class tcp_socket { read write };
class file { read execmod };
}

#============= ifconfig_t ==============
allow ifconfig_t initrc_t:tcp_socket { read write };
allow ifconfig_t mysqld_db_t:file read;

#============= initrc_t ==============
#!!!! This avc can be allowed using the boolean 'allow_execmod'

allow initrc_t lib_t:file execmod;

..and myfix.pp, which is the compiled binary 'policy package' version of the rule.

Now, apply the rule:

# semodule -i myfix.pp

That's it. Two simple commands to silence the warnings and permit the app to run under SELinux.

One thing to remember: if you need to use this same method subsequently to fix another problem app, you'll need to use a name other than 'myfix'. Using 'myfix' again will wipe-out the previous fix and overwrite it with the new one.

[gharris999]

SELinux won't let you run SBS from svn checked-out code unless you relabel some of the compiled modules.

Example:

Say I'm running SC 7.3.4 from a check-out in /usr/share/squeezecenter_trunk/server. SELinux won't allow perl to run slimserver.pl because it doesn't like the fact that several compiled .so modules get loaded. From /var/log/audit/audit.log:


type=AVC msg=audit(1264236676.788:124): avc: denied { execmod } for pid=3798 comm="slimserver.pl" path="/usr/share/squeezecenter_trunk/server/CPAN/arch/5.10/i386-linux-thread-multi/auto/DBD/mysql/mysql.so" dev=dm-0 ino=273523 scontext=unconfined_u:system_r:initrc_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file
type=AVC msg=audit(1264236738.749:129): avc: denied { execmod } for pid=3845 comm="slimserver.pl" path="/usr/share/squeezecenter_trunk/server/CPAN/arch/5.10/i386-linux-thread-multi/auto/XML/Parser/Expat/Expat.so" dev=dm-0 ino=273778 scontext=unconfined_u:system_r:initrc_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file
type=AVC msg=audit(1264236790.125:134): avc: denied { execmod } for pid=3889 comm="slimserver.pl" path="/usr/share/squeezecenter_trunk/server/CPAN/arch/5.10/i386-linux-thread-multi/auto/GD/GD.so" dev=dm-0 ino=273604 scontext=unconfined_u:system_r:initrc_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file

We can fix this with two simple commands. In a terminal, as root, relabel the *.so files, and then apply the new security context:


# /usr/sbin/semanage fcontext -a -t textrel_shlib_t "/usr/share/squeezecenter_trunk/server/CPAN/arch(/.+\.so)??"
# /sbin/restorecon -R -v /usr/share/squeezecenter_trunk/server/CPAN/arch

That's it. SELinux now allows perl to run slimserver.pl.