SELinux/cron

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).

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

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  variable is kept as   and not changed to something like. The reason for this is that system cron job policies might not hold any privilege in  and might fail if the   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:

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:

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
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:

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:

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:

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:

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