[Bug 1813833] Re: User without read permission on cron.allow can execute crontab

[Seth Arnold]

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
Foundations Bugs, 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