1

Scenario: I want to block www-data from using cron.

I have added a few other users into cron.allow, chmod 600 it.
I would expect no other users jobs get executed.

Still, crontab -u www-data -e allows me to edit its crontab.
That would be fine by me. One could use it to detect tampering attempts. Created cron.deny anyhow, the crontab is additionally not even editable.

crontab -u www-data -e

The user www-data cannot use this program (crontab)

This is the first thing I do on a clean server (Ubuntu 18.04). A few hours later, a cryptominer comes in, writes somehow /var/spool/cron/crontab/www-data - the jobs get executed. But cron.allow, cron.deny are still in place - meaning the setup was ignored.

...that cannot be the intended behavior...

fileCrontabWww="/var/spool/cron/crontab/www-data"
echo 'MAILTO=root' > "$fileCrontabWww"
chown root:root "$fileCrontabWww"
chmod 200 "$fileCrontabWww"

Jobs are not executed any more. But I had to lock it down to 200 permissions, because the cron is reading the files as root. journalctl -u cron shows:

cron[680]: (www-data) INSECURE MODE (mode 0600 expected) (crontabs/www-data)

Oh well. I have what I needed. But is this how to work with cron in attempt to harden it? Or was the usecase scenario never played through?

Also an interesting fact, from https://help.ubuntu.com/community/CronHowto

Note, userids on your system which do not appear in /etc/shadow will NOT have operational crontabs, if you desire to enter a user in /etc/passwd, but NOT /etc/shadow that user's crontab will never run.

Which is not really usable as restrictive approach, because of unexpected side consequences.

From Differences between `/etc/crontab`, files under `/etc/cron.d/` and `/var/spool/cron/crontabs/root`?

/var/spool/cron/crontabs is the stuff managed by the crontab command.

But the management tool and the worker somehow drift apart, showing inconsistent behavior. What is the workflow here?

informatik-handwerk.de
  • 11
  • NB: I understand that the actual security hole lies somewhere sooner down the road. But I have not found yet where, so noticing that is not really helpful. – informatik-handwerk.de Sep 19 '20 at 22:30
  • 1
    cron.allow and cron.deny presumably need to be readable to the service enforcing these constraints - have you checked that they are? In any case, this is probably something best enforced with SELinux or similar frameworks. I wouldn't be surprised if www-data is already prohibited from creating cron jobs by default. – l0b0 Sep 20 '20 at 00:47
  • Were the jobs already in a crontab file when you hardened? – waltinator Sep 20 '20 at 01:09
  • @waltinator: The lockdown script is the first thing I run, before provisioning with anything else... @l0b0 the spool is definitely read as root user, but thank you for the suggestion, I will try to chown root:crontab the configuration files... SElinux is way too much time investment right now for me, I am a programmer, not a sys admin so I have a huge technology gap to overcome. – informatik-handwerk.de Sep 20 '20 at 21:36
  • Comments are designed for US to ask YOU questions about your Question. You should Edit your question to add information. By updating your Question, and using the formatting buttons, you make all the information available to new readers. People shouldn't have to read a long series of comments to get the whole story. – waltinator Sep 20 '20 at 21:52

0 Answers0