I've patched my local FC6 strict policy to accommodate the use of
anacron; as the machine is generally powered off overnight, anacron gets
far more usage than crond. The FC6 strict policy,
selinux-policy-2.4.6-17.fc6.noarch.rpm, appeared to fail to run the
overnight jobs in the correct domains.
Whilst investigating the issue, I noted the following:
crond starts up in crond_t, but seemingly transitions itself to
system_crond_t via setexeccon().
anacron is also started in crond_t, but doesn't bother to call
setexeccon(), and hence remains forever in crond_t.
Under targeted policy only, crond_t is a typealias for system_crond_t
The various auto-transitions to logrotate_t, logwatch_t and so on, are
apparently linked to system_crond_t rather than crond_t. Hence
anacron jobs never transition to system_crond_t, unless the policy is
targeted, in which case anacron is already in system_crond_t by virtue
of the typealias.
The fcron package in Extras appears to have sufficient functionality to
replace both anacron and cron, and also knows about setexeccon(), but I
didn't investigate this further.
The nsarefpolicy contains a separate transition from initrc_t to
system_crond_t for anacron_exec_t, but the latest FC6 policy,
(selinux-policy-2.4.6-17.fc6.noarch.rpm), has both the anacron_exec_t
definition and the alternative transition patched out.
The latest rawhide policy contains some additional fixes for anacron
covering /var/spool/anacron and /var/lock usage, but not the
anacron_exec_t definition or the initrc_t -> system_crond_t transition.
Because the cron.fc already defines a label for /usr/sbin/anacron, I've
manually labelled /usr/sbin/anacron to anacron_exec_t for the present.
Obviously this label will be undone by any /.autorelabel I'm forced to
invoke, until such time as this patch, or an equivalent fix, is
released.
My current patch module, incorporating the cron fixes already in
selinux-policy-2.4.6-21.fc6.noarch.rpm, is as below. The ifdef strict
clause at the end avoids a double definition of the same policy on
targeted where crond_t and system_crond_t are the same thing.
I guess that in an ideal world, anacron itself would be patched to
launch all it's child jobs in system_crond_t, further emulating crond's
behaviour, and thereby avoiding this fixup.
[root@topaz ~]# cat /root/selinux.local/localanacron.fc
# anacrond executable will have:
# label: system_u:object_r:anacron_exec_t
# MLS sensitivity: s0
# MCS categories: <none>
# We cant easily override the /usr/sbin/anacron setting in Fedora
policy, so we create
# a clone binary and label as anacron_exec_t
/usr/sbin/anacrond --
gen_context(system_u:object_r:anacron_exec_t,s0)
/var/lock/subsys/anacron --
gen_context(system_u:object_r:system_crond_lock_t,s0)
/var/spool/anacron(/.*)?
gen_context(system_u:object_r:cron_spool_t,s0)
[root@topaz ~]#
[root@topaz ~]# cat /root/selinux.local/localanacron.te
policy_module(localanacron,0.1.1)
require {
type system_crond_t;
type system_crond_lock_t;
type cron_spool_t;
type crond_var_run_t;
}
########################################
#
# Anacron local policy
#
type anacron_exec_t;
corecmd_executable_file(anacron_exec_t)
# anacron transitions directly to system_crond_t,
# rather than crond_t because it doesnt currently
# perform a setexeccon internally
init_daemon_domain(system_crond_t,anacron_exec_t)
# Allow anacron to update spool files in /var/spool/anacron
allow system_crond_t cron_spool_t:file create_file_perms;
# This is to handle creation of files in /var/lock directory. (anacron)
allow system_crond_t system_crond_lock_t:file create_file_perms;
files_lock_filetrans(system_crond_t,system_crond_lock_t,file)
# Allow anacron to write to /var/run/anacron.pid
ifdef(`strict_policy',`
allow system_crond_t crond_var_run_t:file create_file_perms;
files_pid_filetrans(system_crond_t,crond_var_run_t,file)
')
[root@topaz ~]#
--
Ted Rule
Director, Layer3 Systems Ltd
W: http://www.layer3.co.uk/
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
