Linux Essentials for Cybersecurity, First Edition

Chapter 17 Develop an Automation Security Policy

Now that you have learned how to automate processes (Chapter 14, “Crontab and At,”) and create BASH scripts (Chapter 15, “Scripting,” and Chapter 16, “Common Automation Tasks,”), it is time to learn how to create a security policy for these features. This chapter focuses on what you should consider when creating an automation security policy.

After reading this chapter and completing the exercises, you will be able to do the following:

Create a security policy for the use of crontab and at.

Create a security policy for BASH scripts.

Securing crontab and at

Some of the security features for crontab and at were covered in Chapter 14. Recall that you can determine who has access to the crontab command by modifying the contents of either the /etc/cron.allow or /etc/cron.deny file. The /etc/at.allow and /etc/at.deny files are used to determine who can use the at command.

Your security policy should clearly indicate who can use these commands. The decision should be made for each system in your environment. The following describes some of the considerations that have an impact on your decision:

• On system-critical servers, consider removing access to the crontab and at commands for all users. These commands can either impact system performance (if users have system-intensive crontab and at jobs) and potentially provide the means for a hacker to exploit the system.

• On workstations, considering only providing access to users who routinely use the workstations and deny all others.

• Monitor crontab and at jobs on a regular basis. Explore the commands that are executed (these are stored in text files in the /var/spool/cron and /var/spool/at directories) for suspicious jobs or jobs that use large amounts of system resources.

• Create written rules for the use of crontab and at that all users must follow. Include consequences for misuse.

It is also important to make sure specific files and directories that are related to the crontab and at jobs are properly secured. Consider the following permission suggestions (typical default permissions shown in parentheses):

• /var/spool/cron (drwx------): This default permission set is as secure as you can make this directory.

• /var/spool/at (drwx------): This default permission set is as secure as you can make this directory.

• /etc/crontab (-rw-r--r--): On most systems, regular users have no need to access this file, so consider changing the permissions to -rw------.

• /etc/cron.d (drwxr-xr-x): On most systems, regular users have no need to access this file, so consider changing the permissions to drwx-----.

• /etc/cron.daily (drwxr-xr-x): On most systems, regular users have no need to access this file, so consider changing the permissions to drwx-----.

• /etc/cron.hourly (drwxr-xr-x): On most systems, regular users have no need to access this file, so consider changing the permissions to drwx-----.

• /etc/cron.monthly (drwxr-xr-x): On most systems, regular users have no need to access this file, so consider changing the permissions to drwx-----.

• /etc/cron.weekly (drwxr-xr-x): On most systems, regular users have no need to access this file, so consider changing the permissions to drwx-----.

• /etc/cron.deny (-rw-r--r--): On most systems, regular users have no need to access this file, so consider changing the permissions to -rw------.

• /etc/cron.allow (-rw-r--r--): On most systems, regular users have no need to access this file, so consider changing the permissions to -rw------.

• /etc/at.deny (-rw-r--r--): On most systems, regular users have no need to access this file, so consider changing the permissions to -rw------.

• /etc/at.allow (-rw-r--r--): On most systems, regular users have no need to access this file, so consider changing the permissions to -rw------.

• /usr/bin/crontab (-rwsr-xr-x): To ensure no user besides the root user can execute the crontab command, remove the SUID permission and the permissions for group and other: -rwx------.

• /usr/bin/at (-rwsr-xr-x): To ensure no user besides the root user can execute the at command, remove the SUID permission and the permissions for group and other: -rwx------.

• /etc/anacrontab (-rw-r--r--): On most systems, regular users have no need to access this file, so consider changing the permissions to -rw------.

Two additional concerns that you should take into consideration when creating a security policy for crontab and at:

• Remember that each system has its own crontab and at systems. The policy you create has to take into consideration different rules for different systems.

• If you remove a user’s ability to use the crontab and at commands, then any of that user’s existing crontab and at jobs would still execute. Disabling access only limits the user’s ability to create more crontab and at jobs. Your security policy should also have a procedure in place to identify and remove existing jobs when a user is blocked access.

Securing BASH Scripts

BASH scripts allow you to create tools. Often folks who write shell scripts do not consider security; however, hackers will make use of existing scripts to compromise the system, so having a security policy for BASH scripts is important. This section outlines some security features you should consider when creating a security policy for BASH scripts.

Access to Scripts

Some scripts are meant to be tools for everyone, but some are for specific users (database administrators, system administrators, and so on). Carefully consider where you place scripts, and make sure only the authorized users have access to the scripts and the ability to execute them.

Also consider on which systems you place scripts. Placing BASH scripts on a publicly accessible system poses a greater threat than on an internal server.

Do not allow anyone the ability to modify a script, except for the owner of the script. For example, a good permission set for a script would be -rwxr-x--- whereas a bad permission set would be -rwxrwx---. The second permission set would allow any group member the ability to modify the contents of the script.

Never place SUID or SGID permission on a BASH script. A hacker who knows BASH can take advantage by running extra commands from the script, which could provide access to files that the hacker would normally not be able to access.

Script Contents

In order to execute a script, the read permission has to be enabled for a user. This means that, unlike with most system binary commands, a user can see everything in a BASH script. As a result, you should have a script security policy that requires all scripts to be free of any sensitive data (usernames, passwords, and so on).

It is also safer to user the absolute path when executing commands in a script. For example, consider the following:

#!/bin/bash
cd /data
ls -l jan_folder
rm jan_folder/file1

A safer script would be this:

/usr/bin/cd /data
/usr/bin/ls -l jan_folder
/usr/bin/rm jan_folder/file1

If you do not use the absolute path, then the user’s PATH variable is used to determine the location of the command. This could lead to a situation where the wrong command is executed. For example, hackers like to place rouge rm, ls, and cd commands in directories like /tmp (these commands will exploit or damage the system).

Dealing with Data

One area of concern when writing shell scripts is user data. This data can be gathered either by command-line arguments, via user-created environment variables, or through interaction with the user (for example, the read command). When dealing with user data, consider the following:

• Avoid running critical commands that are based on user data. For example, do not accept a value from the user and then try to execute the passwd command using that value.

• Do not trust that environment variables are set correctly.

• Perform validity checks on all user-related data. For example, if you are expecting a user to provide a ZIP code of five digits, verify they provide exactly five digits.

Shell Settings

Consider the following shell settings:

• set -u: This setting causes your shell script to exit prematurely if an unset variable is used.

• set -f: This setting causes the expansion of wildcards to be avoided. Wildcard expansion can be an issue with data that comes from users.

• set -e: This setting causes a script to exit automatically if any command in the script fails.

Shell Style

Although it is not just a security-based topic, you should also consider reviewing Google’s Shell Style Guide (https://google.github.io/styleguide/shell.xml). It has many best practices that can result in better shell scripts. This could also lead to more secure code, as best practices often mean you are following a good set of rules and are less likely to create a security hole in your code.

Lastly, if you ever execute another user’s script, read the script first to make sure it executes the correct commands. This is especially true for any script you find on the Internet.

Summary

In this chapter, you explored several topics related to creating a security policy for automation tools (crontab and at) and BASH scripts.

Review Questions

1. The permissions for the /var/spool/cron directory should be d_____.

2. Which command will result in only allowing the root user the ability to run the crontab command?

a. rm /etc/crontab

b. rm -r /var/spool

c. chmod 0700 /usr/bin/crontab

d. rm /usr/bin/crontab

3. BASH scripts should never have the _____ and SGID permissions set.

4. Which of the following will cause a BASH script to exit when a command in the script fails?

a. set -u

b. set -f

c. set -e

d. set -v

5. Which of the following will cause a BASH script to exit when an unset variable is used?