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.
The following table lists the file type/labels defined in the cron module (part of the base policy).
|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|
The cron domain supports the following SELinux booleans, which can be set / unset using the standard setsebool statements.
|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
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:
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: (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: (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: