Hello Brandon, I wasn't able to use an untrusted user account to induce this behaviour. So, I'm making this bug public so that more people can be made aware of the misconfiguration that is being encouraged.
It's unfortunate that the providers of this advice never actually tested it themselves. It's unfortunate that the cron manpages don't detail proper permissions for these files. It's unfortunate that crontab(1) doesn't perform this access control check while it has root privileges. It's perhaps most especially unfortunate that this check isn't actually performed by cron(8) at all -- a user listed in /etc/cron.deny isn't actually denied running cron jobs, but is denied managing cron jobs. Existing configurations would keep working. (Probably this is not news to most sysadmins but I'd long since forgotten this detail.) So now, the question is what remediation do we take? - adjusting cron(8) feels like a good idea but would take a fair chunk of effort to not be silly about the implementation. It might also break configurations using the 'gatekeeping' feature of crontab(1). - adjusting crontab(1). I'm not sure how much work this would take but feels like a good approach. - fixing the manpages to describe the correct permissions. This feels like a good idea regardless of changes we may make to crontab(1). Thanks -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cron in Ubuntu. https://bugs.launchpad.net/bugs/1813833 Title: User without read permission on cron.allow can execute crontab Status in cron package in Ubuntu: New 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://secscan.acron.pl/ubuntu1604/5/1/8 and the CIS Level 1 benchmark for Ubuntu. The result of this bug is that a sysadmin attempting to lock down cron by following standard security guidance will fail to do so. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cron/+bug/1813833/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
