Of cron and permissions
Learnt something new about cron today..
A while back, this little vulnerability came up regarding a vulnerability in the Linux kernel in handling core dumps. In a nutshell, attackers could get a root shell on a vulnerable machine by dumping core to /etc/cron.d and waiting a little more than a minute.
Back when the vulnerabililty was announced, a short workaround was also posted. This simple workaround recommended setting chmod 750 /etc/cron.*, seemingly based on the fact that the sample exploit code required a change in directory to /etc/cron.d before dumping core.
The reasoning went that if a user couldn’t even get into /etc/cron.d or /etc/cron.* for that matter, the core wouldn’t be able to be dumped it the directory and be exploited.
Now, when we were implementing this workaround on one of our servers, we (ok, I) got a little over-zealous and ended up giving those 750 permissions to /etc/cron[.]*/*.
As you can figure.. this was a Bad Thing.
cron just about gave up on us after that, with this beautiful little nugget after restarting the daemon
myserver crond: (CRON) STARTUP (V5.0)
myserver crond: (*system*) BAD FILE MODE (/etc/crontab)
myserver crond: (*system*) BAD FILE MODE (/etc/cron.d/mailman)
and crond resolutely refused to run any scripts in /etc/cron.* after that.
It took a bit of digging, but the solution was simple…
… DO NOT chmod 750 /etc/cron.*/*. BAD IDEA.
We got back our friendly crond after pacifying it with some nicer permissions as show below
- /etc/crontab ——- 644
- /etc/cron.d ——– 754
- /etc/cron.d/* —— 644
- /etc/cron.*ly ——- 750
- /etc/cron.*ly/*—– 500
Well, at least cron‘s happy now. And our scripts run fine.
(The /etc/cron.*/* scripts should run so long as they’re set executable by root, which is the user that cron executes the scripts under. You just need this 750 workaround for the /etc/cron.* directories themselves)
Filed under: centos, cron, linux | 6 Comments