User without read permission on cron.allow can execute crontab
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cron (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
/etc/cron.allow is meant to list the users who are allowed to execute crontab. For a user who is not listed, the output should be:
$ crontab -e
You (ubuntu) are not allowed to use this program (crontab)
See crontab(1) for more information
When /etc/cron.allow is not readable by that user, though, it's treated as though the file doesn't exist at all:
$ sudo chmod o-r /etc/cron.allow
$ crontab -e
<opens the crontab editor; on exit: >
crontab: installing new crontab
The obvious workaround is to ensure that /etc/cron.allow is world readable, but unfortunately there are a lot of security tools and documentation out there that explicitly require both using cron.allow and also setting the permission on cron-related files to 600. Examples include https:/
The result of this bug is that a sysadmin attempting to lock down cron by following standard security guidance will fail to do so.
CVE References
affects: | apport (Ubuntu) → cron (Ubuntu) |
information type: | Private Security → Public Security |
Changed in cron (Ubuntu): | |
status: | New → Confirmed |
Hello Brandon, thanks for the report. It'll take us a little while to figure out the ideal behavior.
Thanks