anacron under FC6/SELinux/strict

Ted Rule ejtr at layer3.co.uk
Mon Jan 8 16:07:40 UTC 2007


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 at 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 at topaz ~]#


[root at 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 at topaz ~]#


-- 
Ted Rule

Director, Layer3 Systems Ltd

W: http://www.layer3.co.uk/





More information about the fedora-selinux-list mailing list