SELinux/cron

From Gentoo Wiki
Jump to: navigation, search

Contents

Structure

Domains

The cron daemon itself (like vixie-cron) runs in the crond_t domain. Depending on the cron daemon used, this daemon either immediately executes the jobs (hence its ability to transition to various other domains) or does this through an intermediate domain (system_cronjob_t for system cronjobs and cronjob_t for user cronjobs).

The crontab_t and admin_crontab_t domains are used by the users (and administrators) for maintaining their crontab files. These files are read in by the cron daemon.

File types/labels

The following table lists the file type/labels defined in the cron module (part of the base policy).

Type Function Description
cronjob_t Domain Domain for end user cronjobs
system_cronjob_t Domain Domain for system cronjobs
crond_t Domain Domain for the cron daemon
admin_crontab_t Domain Domain for administrator-started crontab commands
crontab_t Domain Domain for user-started crontab commands
crond_exec_t Entrypoint Entrypoint for the cron daemon binaries
crontab_exec_t Entrypoint Entrypoint for the crontab commands
cron_spool_t Configuration Spool files (where the user crontab files are in)
user_cron_spool_t Configuration Spool files (for the user crontab files)
system_cron_spool_t Configuration Spool files (where the system crontab files are in)
cron_var_lib_t Label for cron's /var/lib items
cron_var_run_t Label for cron's /var/run items
cron_log_t Label for cron's logfiles (/var/log/cron)
crond_tmp_t Label for the cron daemon's temporary files
crond_var_run_t Label for the cron daemon's /var/run items
system_cronjob_lock_t Label for the system cronjobs' lock files
system_cronjob_tmp_t Label for the system cronjobs' temporary files
admin_crontab_tmp_t Label for temporary files created by a system administrators' crontab command
crontab_tmp_t Label for temporary files created by a users' crontab command

Booleans

The cron domain supports the following SELinux booleans, which can be set / unset using the standard setsebool statements.

Boolean Default Description
cron_can_relabel false Allow jobs running in the system_cronjob_t domain to relabel files and directories. When set, these jobs can also call the setfiles and restorecon commands.
fcron_crond false Needed to set more privileges for the cron domains in case fcron is used as a cron daemon. These privileges are not necessary for other cron daemons and as such are "behind" this boolean.

Using cron SELinux module

System administration

If you want to perform system administrative tasks using cronjobs, you will need to take special care that the domain in which the job runs has sufficient privileges.

First, make sure that your cronjobs run in the system_cronjob_t domains. This means that the cronjobs must be defined as either

  • scripts in the /etc/cron.hourly, /etc/cron.daily, ... directories
  • crontab entries in the /etc/cron.d directory
  • crontab entries in the /etc/crontab file

Also make sure that the HOME variable is kept as HOME=/ and not changed to something like HOME=/root. The reason for this is that system cron job policies might not hold any privilege in /root and might fail if the HOME variable is set to that location.

Next, verify that the commands you want to run (and thus their target domain in which they will run) are allowed for the system_cronjob_t domain.

For instance, to verify if we can call emerge:

root # sesearch -s system_cronjob_t -t portage_t -A
Found 1 semantic av rules:
  allow system_cronjob_t portage_t : process transition;

If the domain does not have the necessary privileges, you need to update the policy. More information on maintaining the SELinux policy can be found in the Gentoo Hardened SELinux Handbook.

An example policy file to allow executing dmesg:

root # cat fixcron.te
policy_module(fixcron, 1.0)

require {
  type system_cronjob_t;
}

dmesg_domtrans(system_cronjob_t)

In order to find out which specific calls are necessary, it can come in handy to use the privileges assigned to the sysadm_t domain. Take a look at this sysadm.te file. If you search for "dmesg" you will notice the following in the file:

128 	')
129 	
130 	optional_policy(`
131 	        dmesg_domtrans(sysadm_t)
132 	')
133 	
134 	optional_policy(`

It is this call - dmesg_domtrans - that we are interested in (and which you can notice in the sample policy mentioned above. It is possible that you notice a _run or _exec instead. Try this one first, but most of the time you'll need a _domtrans method.

For more information or help with managing your policies, do not hesitate to drop by on #gentoo-hardened in irc.freenode.net.

User (including root) cronjobs

Note
Part of this is for users which have the ubac USE flag set, but it is pertinent for others as well

When working with end user crontabs (those triggered / managed through the crontab command), you must take care that you do this as the SELinux user which is associated with the file (this is a result of the SELinux User Based Access Control, aka UBAC). In other words, if you want to edit the root users' crontab file, you need to be the root SELinux user (and not a staff user that su/sudo'ed into root).

If this was not done correctly, you will get the following error:

cron[20642]: (root) ENTRYPOINT FAILED (crontabs/root)

Verify that the file's user and SELinux user match:

root # ls -Z /var/spool/cron/crontabs/root
staff_u:object_r:user_cron_spool_t /var/spool/cron/crontabs/root
root # semanage login -l | grep root
root              root

In the above case, the root Unix account (cfr filename of the crontab file) is mapped to the root SELinux user (cfr second "root" in the semanage login -l output). However, the SELinux user of the crontab file is staff_u instead of root, which is why the failure occurred.

To fix this, use chcon:

root # chcon -u root /var/spool/cron/crontabs/root

Another problem that you might see is immediately at startup:

cron[26653]: (system_u) ENTRYPOINT FAILED (/etc/crontab)

In this case, even if the user of the file is correct, it is most likely due to the /etc/selinux/*/contexts/default_context file containing an incorrect definition. Look at the cron-related line and verify that each mentioned context is valid. For instance:

root # seinfo -rsystem_r -x | grep cronjob
  system_cronjob_t

In the above case, cronjob_t is not valid, but system_cronjob_t is.

Reporting cron and SELinux issues

If you have an issue with cron and believe that it is related to SELinux, please also give the output of the following commands.

First, get the domain under which system-level jobs will run:

root # getseuser system_u system_u:system_r:crond_t
seuser:  system_u, level (null)
Context 0        system_u:system_r:system_cronjob_t

Next, get the domain under which user-level jobs will run:

root # getseuser john system_u:system_r:crond_t
seuser:  user_u, level (null)
Context 0        user_u:user_r:cronjob_t
Note
The getseuser command usually takes a Unix account name for the first argument, but treats system_u as a special case.
Personal tools
Namespaces

Variants
Actions
Gentoo Websites logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Navigation
Toolbox
Categories