HANDLING USAGE RESTRICTIONS FOR CRON / CRONTAB SERVICES
- Layout for this exercise:
- cron is a time-based job scheduler in Unix-like computer operating systems.
- cron can be used to schedule jobs (commands or shell scripts) to run periodically at fixed times, dates, or intervals.
- It typically automates system maintenance or administration though its general purpose nature makes it useful for things like downloading files from the Internet and downloading email at regular intervals.
- cron is driven by a crontab (cron table) file, a configuration file that specifies shell commands to run periodically on a given schedule.
- The crontab files are stored where the lists of jobs and other instructions to the cron daemon are kept.
- Users can have their own individual crontab files and often there is a system wide crontab file (usually in /etc or a subdirectory of /etc) that only system administrators can edit.
https://en.wikipedia.org/wiki/Cron
- Reference for cron:
- Reference for crontab:
- These two files play an important role:
/etc/cron.allow - if this file exists it must contain username for using cron jobs.
/etc/cron.deny - if the cron.allow file does not exist but the /etc/cron.deny file does exist then, to use cron jobs, the user must not be listed in the /etc/cron.deny file.
- If neither of these files exist then, depending on site-dependent configuration parameters, either only the super user can use cron jobs, or all users can use cron jobs.
- However, it is important to notice that root is always allowed to setup a crontab:
- Creating a cron.allow file to include the user johndoe:
- Going back to johndoe user account:
- Editing crontab for johndoe:
- Let's see what files are related with cron:
- Removing cron.allow:
- Specifically denying crontab access to johndoe by creating cron.deny:
- Now, johndoe is not allowed to use crontab:
SUDO / SUDOERS / VISUDO
- In this exercise a Linux Debian server is used:
1 - Introduction
- sudo is a program for Unix-like computer operating systems that allows users to run programs with the security privileges of another user, by default the superuser.
- It originally stood for "superuser do" as the older versions of sudo were designed to run commands only as the superuser.
- However, the later versions added support for running commands not only as the superuser but also as other (restricted) users, and thus it is also commonly expanded as "substitute user do".
- Unlike the similar command su, users must, by default, supply their own password for authentication, rather than the password of the target user.
- After authentication, and if the configuration file, which is typically located at /etc/sudoers, permits the user access, the system invokes the requested command.
- The configuration file sudoers offers detailed access permissions, including enabling commands only from the invoking terminal; requiring a password per user or group; requiring re-entry of a password every time or never requiring a password at all for a particular command line. It can also be configured to permit passing arguments or multiple commands.
https://en.wikipedia.org/wiki/sudo
- Installing sudo (in case it is not already installed by default):
- Properties of sudo:
- visudo is a command-line utility that allows editing the configuration file sudoers in a fail-safe manner.
- It prevents multiple simultaneous edits with locks and performs sanity and syntax checks.
- In my Debian system visudo opens nano editor by default, but it could be changed to another preferred editor:
2 - Editing "sudoers" for users
- Editing sudoers and adding a configuration line for the user roch:
- If sudo is not used roch cannot perform the apt-get update command:
- However, now with the new line added to the file sudoers, the command sudo allows roch to update the system:
- Adding another line for the user johndoe. For instance in this example johndoe will be allowed to reload the Apache server:
- Going to the johndoe user account:
- When trying to reload Apache without sudo it fails:
- Using sudo it works:
3 - Editing "sudoers" for groups
- Creating the group team:
- Adding the user johndoe to the group team:
- Checking that the group team has been correctly created:
- Editing sudoers, let's add a line for the group team, allowing its members to update the system without using any password (NOPASSWD option):
- Going back to jonhdoe (member of the group team):
- Not allowed updating without sudo:
- However updating is successful for johndoe with sudo:
4 - Editing "sudoers" for alias
- Editing sudoers and i) creating the group alias TEAMER , ii) adding johndoe:
- Adding the command alias ON_OFF for both reboot and shutdown commands:
- Assigning ON_OFF to TEAMER:
- Going back to johndoe:
- Now johndoe can reboot the system successfully:
5 - Checking sudo configurations for users
- The sudo command with options (-l = list, -U = users) allows to consult the list of allowed/forbidden command for each user:
- Let's see some examples, like users root and johndoe who are part of the sudoers file:
- If the user is not part of the sudoers file, like marie:
