6

The /etc/crontab file has the permissions:

-rw-r--r--

I understand that this file is for system cron jobs and other users should not have permission to modify it. The current permissions allows all users read access to the file, enabling them to view the contents.

Is it necessary for all users to be able read /etc/crontab? I believe that all users should not know some administrative commands, so wouldn't it be better to change the permissions to -rw-r-----?

I used the permission string from CentOS and have not tested it on other distros.

2 Answers 2

Reset to default
6

This would be security by obscurity. There is no real benefit by preventing normal users from reading /etc/crontab. Even if a user can't read the file, it's still possible to gather the executed command just by regularly capturing the process list with ps or by reading /proc.

There should be no need at all to hide some administrative commands except when you put credentials in the command-line. But you should never put credentials in the command line anyway as a normal user can read the command-line, so no real benefit.

There is a mount option/kernel patch for procfs preventing PID leakage as well as some kernel modules like grsec which prevent PID leaks.

The benefit of having the file system readable is that you can have a look/debug the system as a non root user. You don't have to switch to the root user just to check the system crontabs.

3
  • 1
    I disagree somewhat. It is not merely "security by obscurity" to want to keep cronjob details away from regular users. I would call it a (small) part of "defense in depth". Basically, you're right, someone could POSSIBLY determine the contents of my crontab by watching all processes over a length of time, but IMO, that's just fine. Any extra amount of time that a non-root intruder is forced to spend to analyze weaknesses in my system is extra time that I GAIN to detect his presence and take remedial action.
    – Steven Monday
    May 18, 2012 at 22:26
  • 1
    @StevenMonday I disagree somewhat: making /etc/crontab non-world-readable isn't so much security by obscurity as pointless. I would not store confidential information there. The times the jobs run are not confidential information, not even to a defense-in-depth level, to someone with an account on the machine.
    – Gilles 'SO- stop being evil'
    May 19, 2012 at 13:17
  • @Gilles: Looks like we agree to disagree. Somewhat. ;-)
    – Steven Monday
    May 20, 2012 at 3:26
2

/etc/crontab is the main - crontab - resposible for triggering cron.daily, weekly, ...

So if a user wants to know when daily/weekly and so on are being run he/she should be able to check that (fixed time on CentOS, relative time from system boot in SLES).

But actual root-jobs should be placed at /etc/cron.d/specialtime_user, /etc/cron.daily/* and so on, or will be placed in /var/spool/cron/root. The former is sometimes a little bit strange - regarding access rights (I stubled across that on SLES, where I tried to set more restrictive rights on a file there) - the latter should be readable only by root.

3
  • This argument makes sense to me: /etc/crontab on a CentOS box just isn't interesting enough to bother making it unreadable to normal users.
    – Warren Young
    May 21, 2012 at 21:16
  • "/etc/crontab is the main - crontab - resposible for triggering cron.daily, weekly" - That is only true for Debian. See the crond(8) manpage.
    – Adam Monsen
    Apr 24, 2014 at 18:52
  • @Monsen and for SLES 10, 11 and RHEL 5, and...
    – Nils
    Apr 25, 2014 at 9:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .