Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Security and Hardening Guide › Local security › Restricting cron and at
ContentsContents
Security and Hardening Guide
  1. Preface
  2. 1 Security and confidentiality
  3. 2 Common Criteria
  4. I Authentication
    1. 3 Authentication with PAM
    2. 4 Using NIS
    3. 5 Setting up authentication clients using YaST
    4. 6 LDAP with 389 Directory Server
    5. 7 Network authentication with Kerberos
    6. 8 Active Directory support
    7. 9 Setting up a freeRADIUS server
  5. II Local security
    1. 10 Physical security
    2. 11 Software management
    3. 12 File management
    4. 13 Encrypting partitions and files
    5. 14 Storage encryption for hosted applications with cryptctl
    6. 15 User management
    7. 16 Restricting cron and at
    8. 17 Spectre/Meltdown checker
    9. 18 Configuring security settings with YaST
    10. 19 Authorization with PolKit
    11. 20 Access control lists in Linux
    12. 21 Intrusion detection with AIDE
  6. III Network security
    1. 22 X Window System and X authentication
    2. 23 Securing network operations with OpenSSH
    3. 24 Masquerading and firewalls
    4. 25 Configuring a VPN server
    5. 26 Managing a PKI with XCA, X certificate and key manager
    6. 27 Improving network security with sysctl variables
    7. 28 Enabling compliance with FIPS 140-2
  7. IV Confining privileges with AppArmor
    1. 29 Introducing AppArmor
    2. 30 Getting started
    3. 31 Immunizing programs
    4. 32 Profile components and syntax
    5. 33 AppArmor profile repositories
    6. 34 Building and managing profiles with YaST
    7. 35 Building profiles from the command line
    8. 36 Profiling your Web applications using ChangeHat
    9. 37 Confining users with pam_apparmor
    10. 38 Managing profiled applications
    11. 39 Support
    12. 40 AppArmor glossary
  8. V SELinux
    1. 41 Configuring SELinux
  9. VI The Linux Audit Framework
    1. 42 Understanding Linux audit
    2. 43 Setting up the Linux audit framework
    3. 44 Introducing an audit rule set
    4. 45 Useful resources
  10. A GNU licenses
Navigation←→
Security and Hardening Guide › Local security › Restricting cron and at
Top
←→
Applies to openSUSE Leap 15.3

16 Restricting cron and at Edit source

Abstract

This chapter explains how to restrict access to the cron and at daemons to improve the security of a system.

16.1 Restricting the cron daemon
16.2 Restricting the at scheduler

16.1 Restricting the cron daemon Edit source

The cron system is used to automatically run commands in the background at predefined times. For more information about cron, refer to the Book “Reference”, Chapter 15 “Special system features”, Section 15.1.2 “The cron package”.

The cron.allow file specifies a list of users that are allowed to execute jobs via cron. The file does not exist by default, so all users can create cron jobs—except for those listed in cron.deny.

To prevent users except for root from creating cron jobs, perform the following steps.

  1. Create an empty file /etc/cron.allow: 

    tux > sudo touch /etc/cron.allow

  2. Allow users to create cron jobs by adding their usernames to the file: 

    tux > sudo echo "tux" >> /etc/cron.allow

  3. To verify, try creating a cron job as non-root user listed in cron.allow. You should see the message: 

    tux > crontab -e
no crontab for tux - using an empty one

    Quit the crontab editor and try the same with a user not listed in the file (or before adding them in step 2 of this procedure): 

    wilber > crontab -e
You (wilber) are not allowed to use this program (crontab)
See crontab(1) for more information
Important
Important: Existing cron jobs

Implementing cron.allow only prevents users from creating new cron jobs. Existing jobs will still be run, even for users listed in cron.deny. To prevent this, create the file as described and remove existing user crontabs from the directory /var/spool/cron/tabs to ensure they are not run anymore.

Note
Note: Switching to systemd timer units

You should also consider switching to systemd timer units, as they allow for more powerful and reliable task execution. By default, users cannot use them to run code when they are not logged in. This limits the way users can interact with the system while not being connected to it.

For more information about systemd timer units, refer to Book “Reference”, Chapter 10 “The systemd daemon”, Section 10.7 “systemd timer units”.

16.2 Restricting the at scheduler Edit source

The at job execution system allows users to scheduled one-time running jobs. The at.allow file specifies a list of users that are allowed to schedule jobs via at. The file does not exist by default, so all users can schedule at jobs—except for those listed in at.deny)

To prevent users except for root from scheduling jobs with at, perform the following steps.

  1. Create an empty file /etc/at.allow: 

    tux > sudo touch /etc/at.allow

  2. Allow users to schedule jobs with at by adding their usernames to the file: 

    tux > sudo echo "tux" >> /etc/at.allow

  3. To verify, try scheduling a job as non-root user listed in at.allow: 

    tux > at 00:00
at>

    Quit the atprompt with Ctrl–C and try the same with a user not listed in the file (or before adding them in step 2 of this procedure): 

    wilber > at 00:00
You do not have permission to use at.
Note
Note: Uninstalling at

at is not widely used anymore. If you do not have valid use cases, consider uninstalling the daemon instead of just restricting its access.

→Chapter 17 Spectre/Meltdown checker←Chapter 15 User management
Print this page

© 2022 SUSE