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:
Code:
--------------------
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:
Code:
--------------------
#============= 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:
Code:
--------------------
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
------------------------------------------------------------------------
gharris999's Profile: http://forums.slimdevices.com/member.php?userid=115
View this thread: http://forums.slimdevices.com/showthread.php?t=74410
_______________________________________________
unix mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/unix
