2.9 SCHEDULER SECURITY

2.9 SCHEDULER SECURITY

2.9.1 Restricting cron and at Access

In the Linux world, cron and at are the applications of choice for scheduling. Cron is utilized when you need to have a particular job run on a regular basis at the same time interval each time. At is utilized when you want to schedule something to run once at a particular time. By default, access to cron and at are unrestricted. This means that all users have access to modify, add or delete jobs. Cron stores these scheduled jobs in user -specific files called crontabs. Cron periodically queries these crontab files for jobs to run. Jobs are run with the permissions of the user that scheduled the job. Some guidelines to consider when securing cron are:

• Log all Cron jobs “ Red Hat is configured by default to send cron messages via the syslog function to /var/cron/log

• Restrict access to Cron and at “ Only allow those users who have a need to run scheduled jobs access to cron . Cron regulates access through the /etc/cron.allow file. At regulates access through the /etc/at.allow file. Cron.allow and at.allow specify which users are explicitly permitted to schedule cron or at jobs, all other users will be denied access. If a cron.allow or at.allow file does not exist, cron and at will look for a cron.deny or at.deny file respectively. It is not necessary to use the cron.deny or at.deny file so do not create one. If neither of these files exist, cron will allow all users access to cron .

  Note  

  Root will always have access to schedule jobs regardless of the contents of the cron.allow file. To create the cron.allow file:

   $su # echo root > /etc/cron.allow 

• Ensure that programs executed by cron have the appropriate permissions “ Most system administrators love scripts. Scripts are excellent tools for automating many repetitive tasks that system administrators perform. By scheduling these scripts through cron, an administrator can perform a weekly or daily function automatically and gain valuable time. Some scripts require root permissions to run properly, so many times an administrator will run the script from root's crontab. This can create a security problem. Administrators usually create their scripts from their own accounts and those scripts are usually located in their home directories. This means that the permissions on the script are those of the administrator. If an attacker were to gain access to the administrators' own account, he would have access to modify the script. Since the script runs with root permissions, the attacker's commands would run as root. In order to prevent this, ensure that the user whose crontab is running the script or program also owns that script program.