6

I want to install cron on my live web server to run a daily backup script of a local folder. Are there any security considerations I need to be aware of when installing cron?

My web server uses Ubuntu Linux 10.10.

5
  • 1
    What are you afraid of?
    – sanmai
    Sep 8, 2011 at 10:45
  • 2
    Which OS? Please be specific. Windows Cron is as insecure as Windows. Linux cron is still Linux and has all the security of the OS installation.
    – S.Lott
    Sep 8, 2011 at 10:45
  • Maybe I'm just a bit paranoid because it is the live system. It did not came pre-installed, so I was unsure if there are some security considerations that needed to be made. Sep 8, 2011 at 10:50
  • 1
    @S.Lott Windows isn't insecure. Bad Windows admins make Windows insecure. If you let me admin a linux box it'll get broken into in about 2 minutes.
    – mrdenny
    Sep 8, 2011 at 11:21
  • @mrdenny♦: "Windows Cron is as insecure as Windows" can be read as "Windows Cron is as secure as Windows". It sure seemed like a trivial isomorphism.
    – S.Lott
    Sep 8, 2011 at 11:58

2 Answers 2

6

In essence it's secure, but also it is another way for an attacker to, once compromised the system, make some backdoor persistent and/or auto-open it anytime you close it.

You can use the files /etc/cron.allow and /etc/cron.deny to just make your user able to use it. Both have the same format: 1 username per line.

  1. If /etc/cron.allow exists, only the users listed there would be able to have a crontab. No more files are taken into account. Kind of a whitelist.
  2. If /etc/cron.allow does not exist, but /etc/cron.deny does, then anyone but those listed there can have a crontab. Kind of a blacklist.
  3. If neither of them exist, then depending on the UNIX/Linux version then anyone may be allowed to use it, or just the super user (Debian/Ubuntu allow anybody, while redhat based versions seems to only allow root).

In ubuntu by default /etc/cron.deny exists. You can create /etc/cron.allow and put there just your user.

Take into account that these files only manage the users allowed to have a personal crontab (ie. execute crontab -e). The system-wide crontab (/etc/crontab, /etc/cron.d/*, /etc/cron.daily/*. /etc/cron.weekly/*, /etc/cron.monthly/*) will work regardless of the cron.allow/cron.deny files.

3
  • I'm not convinced by your third statement "3. If neither of them exist, then anyone can use it.". The crontab(1) man pages from different systems I have seem to all agree that "If neither of these files exists then only the super user will be allowed to use crontab.". Apr 18, 2015 at 14:01
  • @GZBK it may depend on the system. On debian & ubuntu if these files do not exist then all users can use cron. Going to edit... Apr 19, 2015 at 12:24
  • On my side I was referring to OpenBSD and OpenSUSE. Interesting enough I see now that FreeBSD document the behavior is "depending on site-dependant on configuration parameters" without expliciting the actual involved parameters. At last, the POSIX man page states that under such circumstances "only a process with appropriate privileges shall be allowed to submit a job", the concept of "appropriate privileges" remaining undefined as far as I know. Therefore in such circumstances I think the behavior is just variable and I would definitively recommend to avoid having none of these files present. Apr 19, 2015 at 12:47
1

Yes, it's secure. Just make sure the scripts you run with it are secure. Review them yourself and give them only the rights they need.

You must log in to answer this question.

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