Chapter 4 Implementing Additional Security Features and Best Practices

This chapter describes additional ways to enhance the security of an Oracle Linux system, as well as information about best practices for securing your environment.

4.1 Disabling Core Dumps

A core dump is a file that is produced when a process terminates unexpectedly. The core dump contains an image of the process's memory. You can use a core dump to debug problems and inspect the stage of the program when it terminated. You can produce core dumps on-demand or they can be created automatically on termination.

The core file, also referred to a core, is created in the current working directory. Note that the writing of core fails if the directory to which it is to be created is non-writable, or if a file exists with the same name in that location, and that file is non-writable or is not a regular file.

Core dumps can contain information that an attacker might be able to exploit. Core dumps can also take up a large amount of disk space. To prevent the system from creating core dumps when it terminates a program due to a segment violation or other unexpected error, add the following line to /etc/security/limits.conf:

*  hard  core  0

You can restrict access to core dumps to certain users or groups. See the limits.conf(5) manual page for details.

By default, the system prevents the setuid and setgid programs, programs that have changed credentials, and programs containing binaries that do not have read permission from dumping core.

To ensure that the setting is permanently recorded, add the following lines to the /etc/sysctl.conf file:

# Disallow core dumping by setuid and setgid programs
fs.suid_dumpable = 0

Run the sysctl -p command after adding this information to the file.


A value of 1 permits core dumps that are readable by the owner of the dumping process. A value of 2 permits core dumps that are readable only by root for debugging purposes.

4.2 Disable or Restrict the Automatic Bug Reporting Tool

If you are running the Automatic Bug Reporting Tool, abrt, core dumps may continue to be generated for a system, even if you have disabled the core dump facility. On a production system, you may wish to disable or uninstall abrt entirely.

To stop and disable the abrtd service entirely, run:

sudo systemctl disable --now abrtd

If you would prefer to run the service, make sure that you restrict the service so that it only analyzes crashes for binaries installed using signed packages. You might also want to prevent the service from analyzing particular binaries that may reveal sensitive information in a dump, by adding these to a blocklist.

For example, edit /etc/abrt/abrt-action-save-package-data.conf to set the following parameters:

# Require a GPG signature for a package
OpenGPGCheck = yes                                             
# Add any package names to the Blacklist that contain binaries 
# that you want abrt to not store dump data for
BlackList = nspluginwrapper, valgrind, strace, mono-core, bash

# Disable processing of unpackaged binaries
ProcessUnpackaged = no

# Add any paths to the BlackListedPaths that may contain binary 
# executables that you want abrt to not store dump data for
BlackListedPaths = /usr/share/doc/*, */example*, /usr/bin/nspluginviewer, \

Note that although the BlackList and BlackListedPaths options can prevent the service from storing dump data, the dumps are still generated and written to disk briefly before being removed. This action allows abrtd to notify system administrators of a crash without using up disk space.

To actually prevent the core dumps from being written to disk and to prevent abrtd from detecting crashes in an application, edit /etc/abrt/plugins/CCpp.conf and add the absolute path of the binary to be ignored to the IgnoredPaths list. For example:

IgnoredPaths = /path/to/binary

4.3 Configuring and Using Kernel Security Mechanisms

The Linux kernel features some additional security mechanisms that enhance the security of a system. These mechanisms randomize the layout of the address space for a process or prevent code from being executed in non-executable memory.

4.3.1 Address Space Layout Randomization

Address Space Layout Randomization (ASLR) can help defeat certain types of buffer overflow attacks. ASLR can locate the base, libraries, heap, and stack at random positions in a process's address space, which makes it difficult for an attacking program to predict the memory address of the next instruction. ASLR is built into the Linux kernel and is controlled by the parameter /proc/sys/kernel/randomize_va_space. The randomize_va_space parameter can take the following values:


Disable ASLR. This setting is applied if the kernel is booted with the norandmaps boot parameter.


Randomize the positions of the stack, virtual dynamic shared object (VDSO) page, and shared memory regions. The base address of the data segment is located immediately after the end of the executable code segment.


Randomize the positions of the stack, VDSO page, shared memory regions, and the data segment. This is the default setting.

You can change the setting temporarily by writing a new value to /proc/sys/kernel/randomize_va_space, for example:

sudo echo value > /proc/sys/kernel/randomize_va_space

To change the value permanently, add this setting to /etc/sysctl.conf, for example:

kernel.randomize_va_space = value

Then, run the sysctl -p command.

If you change the value of randomize_va_space, you should test your application stack to ensure that it is compatible with the new setting.

If necessary, you can disable ASLR for a specific program and its child processes by using the following command:

setarch `uname -m` -R program [args ...]

4.3.2 Data Execution Prevention or No eXecute

The Data Execution Prevention (DEP) feature, also known as No eXecute (NX), prevents an application or service from executing code in a non-executable memory region. Hardware-enforced DEP works in conjunction with the NX bit on compatible CPUs to help prevent certain types of buffer overflow attacks. This feature is enabled by default and cannot be disabled. It helps to take advantage hardware capabilities to protect your system.

Oracle Linux does not emulate the NX bit in software for CPUs that do not implement the NX bit in hardware.

4.3.3 Position Independent Executables

The Position Independent Executables (PIE) feature loads executable binaries at random memory addresses so that the kernel can disallow text relocation. This feature allows developers to code applications that load at different memory addresses each time the application loads, making it more difficult for an attacker to predict where the application is located in memory, thereby helping to protect against memory-related exploits.

To generate a position-independent binary:

  • Specify the -fpie option to gcc when compiling.

  • Specify the -pie option to ld when linking.

To test whether a binary or library has been built with PIE enabled, run the following command:

sudo readelf -d elfname | grep -i flags

The command should indicate that the PIE flag is set. By default, on Oracle Linux 8 binaries are typically built with this flag set, unless there is a specific reason not to do so, such as a compile issue resulting specifically from setting this option.

4.4 Configuring System Cryptograpic Policies

Oracle Linux 8 includes the update-crypto-policies command that can be used to configure which cryptographic algorithms, ciphers and protocols are enabled on a system for use by applications and services. The command can be used to either relax policy or to harden it further.

The DEFAULT policy that is enforced for an initial installation, helps to protect a system by setting sane rules for all cryptographic activity. For example, the TLS 1.0 and 1.1 protocols are disabled along with the DSA, 3DES, and RC4 algorithms. Furthermore, RSA keys and Diffie-Hellman parameters are only accepted if they are at least 2048 bits long.

The system can be further hardened to use a very conservative FUTURE policy that prevents SHA-1 in signature algorithms and also requires a 3072 bit key length for RSA and Diffie-Hellman.

A FIPS policy level is enforced when FIPS mode is enabled as per Section 4.9, “Configuring a System in FIPS Mode”. This sets the system up to only support the policy requirements specified for FIPS140-2 conformance.

You can check which policy is being enforced by running:

sudo update-crypto-policies --show

You can set the system-wide policy by running the command as follows:

sudo update-crypto-policies --set FUTURE

For more information on this tool and the applications that are affected by it, see the crypto-policies(7) and update-crypto-policies(8) manual pages.

4.5 Checking User Accounts and Privileges

Check the system for unlocked user accounts on a regular basis, for example using a command such as the following:

sudo for u in $(cat /etc/passwd | cut -d: -f1 | sort); do passwd -S "$u"; done

The following output is displayed:

abrt LK 2012-06-28 0 99999 7 -1 (Password locked.)
adm LK 2011-10-13 0 99999 7 -1 (Alternate authentication scheme in use.)
apache LK 2012-06-28 0 99999 7 -1 (Password locked.)
avahi LK 2012-06-28 0 99999 7 -1 (Password locked.)
avahi-autoipd LK 2012-06-28 0 99999 7 -1 (Password locked.)
bin LK 2011-10-13 0 99999 7 -1 (Alternate authentication scheme in use.)

In the output from this command, the second field shows if a user account is locked (LK), does not have a password (NP), or has a valid password (PS). The third field shows the date on which the user last changed their password. The remaining fields show the minimum age, maximum age, warning period, and inactivity period for the password and additional information about the password's status. The unit of time is days.

Use the passwd command to set passwords on any accounts that are not protected.

Use passwd -l to lock unused accounts. Alternatively, use userdel to remove the accounts entirely.


System accounts must be preserved. These are any accounts with user IDs that are less than 1000, and especially any user IDs that are less than 100.

For more information, see the passwd(1) and userdel(8) manual pages.

To specify how users' passwords are aged, edit the settings in the /etc/login.defs file that are described in the following table.




Maximum number of days for which a password can be used before it must be changed. The default value is 99,999 days.


Minimum number of days that is allowed between password changes. The default value is 0 days.


Number of days warning that is given before a password expires. The default value is 7 days.

For more information, see the login.defs(5) manual page.

To change the length of time a user's account can be inactive before it is locked, use the usermod command. For example, you would set the inactivity period to 30 days as follows:

sudo usermod -f 30 username

To change the default inactivity period for new user accounts, use the useradd command:

sudo useradd -D -f 30

A value of -1 specifies that user accounts are not locked due to inactivity.

For more information, see the useradd(8) and usermod(8) manual pages.

To verify that no user accounts other than root have a user ID of 0, you would use the following command:

sudo awk -F":" '$3 == 0 { print $1 }' /etc/passwd

The following is the output of the previous command:


If you install software that creates a default user account and password, you should change the vendor's default password immediately. Centralized user authentication using an LDAP implementation such as OpenLDAP can help to simplify user authentication and management tasks, and also reduces the risk arising from unused accounts or accounts without a password.

By default, an Oracle Linux 8 system is configured so that you cannot log in directly as root. You must log in as a named user before using either the su or sudo command to perform tasks as the root user. This configuration enables system accounting to trace the original login name of any user who performs a privileged administrative action. If you want to grant certain users authority to be able to perform specific administrative tasks by using the sudo command, use the visudo command to modify the /etc/sudoers file.

For example, the following entry grants the user user1 the same privileges as root when using the sudo command, but defines a limited set of privileges to user2 so that he can run commands such as systemctl, rpm, and dnf:

user1           ALL=(ALL)       ALL
user2          ALL= SERVICES, SOFTWARE

For more information about setting up user accounts and authentication, see Oracle® Linux 8: Setting Up System Users and Authentication.

4.6 Configuring User Authentication and Password Policies

If you follow traditional digital identity policies, the Pluggable Authentication Modules (PAM) feature enables you to enforce strong user authentication and password policies, including rules for password complexity, length, age, expiration and the reuse of previous passwords. You can configure PAM to block user access after too many failed login attempts, after normal working hours, or if too many concurrent sessions are opened. It is worth noting that some of these policies are no longer considered particularly helpful for security as they often lead users to implement poor security practice when storing passwords or when renewing. See for more information.

PAM is highly customizable by its use of different modules with customizable parameters. For example, the default password integrity checking module tests password strength. The PAM configuration file (/etc/pam.d/system-auth) contains the following default entries for testing a password's strength:

password  requisite try_first_pass local_users_only retry=3 authtok_type=
password  sufficient sha512 shadow nullok try_first_pass use_authtok
password  required

The line for defines that a user gets three attempts to choose a good password. From the module's default settings, the password length must a minimum of six characters, of which three characters cannot be the same as a previous password. The module only tests the quality of passwords for users who are defined in the /etc/passwd file.

The line for specifies that the module tests the password that was previously specified in the stack before prompting for a password; and, if necessary uses the SHA-512 password hashing and the /etc/shadow file to allow access. if the existing password is null. Note that pam_pwquality will already have performed such checks for users that are defined in the /etc/passwd file .

You can modify the control flags and module parameters to change the checks that are performed when a user changes his or her password, for example:

password  required retry=3 minlen=8 difok=5 minclass=-1
password  required use_authtok sha512 shadow remember=5
password  required

The line for specifies that a user is allowed three attempts to choose a good password, with a minimum of eight characters, of which five characters must be different from the previous password, and which must contain at least one upper-case letter, one lower-case letter, one numeric digit, and one non-alphanumeric character.

The line for specifies that the module does not perform password checking, uses SHA-512 password hashing and the /etc/shadow file, and saves information about the previous five passwords for each user in the /etc/security/opasswd file. As nullok is not specified, a user cannot change his or her password if the existing password is null.

The omission of the try_first_pass keyword means the user is always asked for their existing password, even if the user has entered it for the same module or for a previous module in the stack.

For more information, see the pam_deny(8), pam_pwquality(8), and pam_unix(8) manual pages.

4.7 Configuring File System Mounts, File Permissions, and File Ownerships

Use separate disk partitions for operating system and user data to prevent a file system full issue from impacting the operation of a server. For example, you might create separate partitions for /home, /tmp, /oracle, and so on.

Establish disk quotas to prevent a user from accidentally or intentionally filling up a file system and denying access to other users.

To prevent the operating system files and utilities from being altered during an attack, mount the /usr file system read-only. If you need to update any RPMs on the file system, use the -o remount,rw option with the mount command to remount /usr for both read and write access. After performing the update, use the -o remount,ro option to return the /usr file system to read-only mode.

To limit user access to non-root local file systems such as /tmp or removable storage partitions, specify the -o noexec, nosuid, nodev options to mount. These option prevent the execution of binaries (but not scripts), prevent the setuid bit from having any effect, and prevent the use of device files.

Use the find command to check for unowned files and directories on each file system, for example:

sudo find mount_point -mount -type f -nouser -o -nogroup -exec ls -l {} \;
sudo find mount_point -mount -type d -nouser -o -nogroup -exec ls -l {} \;

Unowned files and directories might be associated with a deleted user account, they might indicate an error with software installation or deleting, or they might a sign of an intrusion on the system. Correct the permissions and ownership of the files and directories that you find, or remove them. If possible, investigate and correct the problem that led to their creation.

Use the find command to check for world-writable directories on each file system, for example:

sudo find mount_point -mount -type d -perm /o+w -exec ls -l {} \;

Investigate any world-writable directory that is owned by a user other than a system user. The user can remove or change any file that other users write to the directory. Correct the permissions and ownership of the directories that you find, or remove them.

You can also use the find command to check for setuid and setgid executables.

sudo find path -type f \( -perm -4000 -o -perm -2000 \) -exec ls -l {} \;

If the setuid and setgid bits are set, an executable can perform a task that requires other rights, such as root privileges. However, buffer overrun attacks can exploit such executables to run unauthorized code with the rights of the exploited process.

4.8 Restricting Access to SSH Connections

The Secure Shell (SSH) allows protected, encrypted communication with other systems. As SSH is an entry point into the system, disable it if it is not required, or alternatively, edit the /etc/ssh/sshd_config file to restrict its use.

You can restrict access to the root user, as well as remote access to certain users and groups by specifying settings in this file. You can also configure settings in the /etc/ssh/sshd_config file so that the SSH client automatically times out after of period of inactivity.

It is common practice to also disable password-based authentication for SSH and to require public key authentication instead. By doing this, you can limit access to users who possess a private key. Often this can help to further limit SSH access on systems.

After making any changes to the configuration file, you must restart the sshd service for the changes to take effect.

For more information, see Oracle® Linux: Connecting to Remote Systems With OpenSSH and the sshd_config(5) manual page.

4.9 Configuring a System in FIPS Mode


Currently, there are no FIPS validated cryptographic modules available for Oracle Linux 8. However, you can configure FIPS mode on an Oracle Linux 8 system, which may be useful because FIPS mode imposes certain limitations when using cryptographic modules.

The following procedures describe how to enable and disable FIPS mode on an Oracle Linux 8 system. Note that the method for enabling and disabling FIPS mode in this release has changed significantly from the method that was used in previous Oracle Linux releases. In particular, the dracut-fips package no longer exists, so you do not need to install it to enable FIPS mode on Oracle Linux 8. Also, you no longer need to edit the GRUB configuration file. Instead, you use the fips-mode-setup utility to set up and configure FIPS mode, as described in the following procedure.

4.9.1 Enabling FIPS Mode

  1. To enable FIPS mode on the system, run the following command:

    sudo fips-mode-setup --enable

    The following output is displayed:

    Setting system policy to FIPS
    FIPS mode will be enabled.
    Please reboot the system for the setting to take effect.

    You must reboot the system for the setting to take effect.

    Running the previous command configures FIPS mode implicitly by setting the system-wide cryptographic policy to FIPS. Note that using the update-crypto-policies command to set FIPS mode is not sufficient, as shown in the following output:

    sudo update-crypto-policies --set FIPS

    The following output is displayed:

    Warning: Using 'update-crypto-policies --set FIPS' is not sufficient for FIPS compliance.
    Use 'fips-mode-setup --enable' command instead.
  2. Verify that FIPS is enabled by running any of the following commands:

    sudo fips-mode-setup --check
    sudo update-crypto-policies --show
    sudo cat /etc/system-fips
    sudo sysctl crypto.fips_enabled 
    crypto.fips_enabled = 1

    For the command output in the last example, a response of 1 indicates that FIPS is enabled.

4.9.2 Disabling FIPS Mode

If you need to disable FIPS mode for any reason, run the following command:

sudo fips-mode-setup --disable
Setting system policy to DEFAULT
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.
FIPS mode will be disabled.
Please reboot the system for the setting to take effect.

You must reboot the system for the setting to take effect.

4.10 Using System Auditing and Monitoring

Auditing collects data at the kernel level that you can analyze to identify unauthorized activity. Auditing collects more data in greater detail than system logging, but most audited events are uninteresting and insignificant. The process of examining audit trails to locate events of interest can be a significant challenge that you will probably need to automate.

The audit configuration file, /etc/audit/auditd.conf, defines the data retention policy, the maximum size of the audit volume, the action to take if the capacity of the audit volume is exceeded, and the locations of local and remote audit trail volumes. The default audit trail volume is /var/log/audit/audit.log.

For more detailed information about auditing and monitoring Oracle Linux systems, see Oracle® Linux 8: Monitoring and Tuning the System.

4.11 Using Advanced Intrusion Detection Environment

Advanced Intrusion Detection Environment (AIDE) is an application that uses tools to detect changes to particular files on a system and report on them so that you are able to maintain baseline file integrity that can help you detect unauthorized changes and potential tootkits.

This tool is installed as follows:

sudo dnf install aide

When installed, you can modify the configuration in /etc/aide.conf. The configuration controls which files and directories are monitored by AIDE and also how logging and output should be handled.

AIDE stores its current information about a system's configuration state in a database located at /var/lib/aide/aide.db. Ideally you should store a copy of this database file at an external location so that you can replace it with a known safe state when you want to peform an audit. If the file does not yet exist, you can create one for the currect system state by running:

sudo aide --init
sudo cp /var/lib/aide/ /var/lib/aide/aide.db.gz

Once you have created a database, you can check file integrity at any time by running:

sudo aide --check

If no differences are found, AIDE returns the results with the following message:

AIDE found NO differences between database and filesystem. Looks okay!!

For example, run the following command to determin whether a user was added to the system:

sudo aide --check

The output of the previous command indicates a user was added to the system:

Start timestamp: 2019-12-04 05:55:13 -0800 (AIDE 0.16)
AIDE found differences between database and filesystem!!

  Total number of entries:      122738
  Added entries:                2
  Removed entries:              0
  Changed entries:              6

Added entries:

f++++++++++++++++: /etc/subgid-
f++++++++++++++++: /etc/subuid-

Changed entries:

f   ...    .C... : /etc/group
f   ...    .C... : /etc/gshadow
f   ...    .C... : /etc/passwd
f   ...    .C... : /etc/shadow
f   ...    .C... : /etc/subgid
f   ...    .C... : /etc/subuid

Detailed information about changes:

File: /etc/group
  SHA512   : W5tzAJAAXppdWLhwTrfLbj1hybSHwyxL | eiDsbAMeN8+3RGBwbvzO9Z2cSCirA19N
             Dta+VSq1EJ5nGnji/nmcrT+a2BAhZBVj | /0qxQqnR00PpAQxV0o0PDWVmSpoVQZtt
             eD5aT3AONeqXFAmSEbjpeA==         | 4Kv7CJ2JY+xAEn1ZLJuA1w==

File: /etc/gshadow
  SHA512   : IkHK5bWCT+rvJD5nnjWqaMtSs9O1IK/1 | 2/dZW5sMeVNeEn6L2u3DMk7U9M6LSNUO
             cbDZ3KjxCQBnGiWZF71i96Z4lsiF6HhD | BVQgMWmDJ1owZgCg2kRRR35F1QscD9vi
             XtSIl15nnLPgrOOOI4m5aA==         | 9AdxB37el4n2mZefr5eyuw==

File: /etc/passwd
  SHA512   : IDuW4odlc9sTUheajcI4e7DUCKIy4IIN | utGe+XyYkQev2tb7C0N8hKrWvM98R/f+
             6SDvQ559VPt571F3Ufy9nezUbzAiyvEF | JT5XT0YJmUf6xLw1DdX6KgNuRAwQD3xW
             RTZOdvMDrzwg2XeC4eXFpQ==         | J5Otz/NqogLRNMQY5ID+HQ==

File: /etc/shadow
  SHA512   : moPRI01xc9NR6dq4hhu+X7eG7JlYs+sa | 7WTuSitxpbvli7SoRqwcj+9puKzYeXaI
             nkjYz+3WMqOD7fmb0D7HC3kyieJyxExB | M3G8ChKgkFIRk6ASA+jBhBP6Pb7yVScK
             b1tPATwN4Ehq2sNjM272tQ==         | fr08ajH2WrKaoc/+Y5dM0w==

File: /etc/subgid
  SHA512   : z4PhNX7vuL3xVChQ1m2AB9Yg5AULVxXc | 1ZlaLZw6se3D5tHuTLq1G1V1QLyyHq+S
             g/SpIdNs6c5H0NE8XYXysP+DGNKHfuwv | tACG1j0SmYle1z7NoHtJ8MgCo9He5P/2
             Y7kxvUdBeoGlODJ6+SfaPg==         | wEstUtZ5DAnriW9LTL1khQ==

File: /etc/subuid
  SHA512   : z4PhNX7vuL3xVChQ1m2AB9Yg5AULVxXc | 1ZlaLZw6se3D5tHuTLq1G1V1QLyyHq+S
             g/SpIdNs6c5H0NE8XYXysP+DGNKHfuwv | tACG1j0SmYle1z7NoHtJ8MgCo9He5P/2
             Y7kxvUdBeoGlODJ6+SfaPg==         | wEstUtZ5DAnriW9LTL1khQ==

The attributes of the (uncompressed) database(s):

  MD5      : /EcraAZYQoOY4MYKitwgqw==
  SHA1     : phqMw8phaa6SE8FevlkRmsXb3uU=
  RMD160   : DO63MxEGCVm3rWo6nRHePhtd/6o=
  TIGER    : G+z6vQRwH+QbTrRw3ottzUT9gTJvcD/A
  SHA256   : acDo9Rswl/pTdtwKiYEyzpb0sR1f655r
  SHA512   : insPGTVN8n966ccZWn2VvE21nLwJGnNt

End timestamp: 2019-12-04 05:55:54 -0800 (run time: 0m 41s)

If you configure this tool to run on a cron, it is possible to get regular reporting to indicate changes to system configuration and state that may help with early intrusion detection.

See the aide(1) and aide.conf(5) manual pages for more information.

4.12 Implementing System Process Accounting

The psacct package implements the process accounting service in addition to the following utilities that you can use to monitor process activities:


Displays connection times in hours for a user as recorded in the wtmp file (by default, /var/log/wtmp).


Turns on process accounting to the specified file. If you do not specify a file name argument, process accounting is stopped. The default system accounting file is /var/account/pacct.


Displays information about previously executed commands as recorded in the system accounting file.


Summarizes information about previously executed commands as recorded in the system accounting file.


As for any logging activity, ensure that the file system has enough space to store the system accounting and wtmp files. Monitor the size of the files and, if necessary, truncate them.

For more information, see the ac(1), accton(8), lastcomm(1), and sa(8) manual pages.

4.13 Protecting the Root Directory Using chroot Jails

A chroot operation changes the apparent root directory for a running process and its children. It allows you to run a program with a root directory other than /. The program cannot see or access files outside the designated directory tree. Such an artificial root directory is called a chroot jail, and its purpose is to limit the directory access of a potential attacker. The chroot jail locks down a given process and any user ID that it is using so that all they see is the directory in which the process is running. To the process, it appears that the directory in which it is running is the root directory.


The chroot mechanism cannot defend against intentional tampering or low-level access to system devices by privileged users. For example, a chroot root user could create device nodes and mount file systems on them. A program can also break out of a chroot jail if it can gain root privilege and use chroot() to change its current working directory to the real root directory. For this reason, you should ensure that a chroot jail does not contain any setuid or setgid executables that are owned by root.

For a chroot process to be able to start successfully, you must populate the chroot directory with all required program files, configuration files, device nodes, and shared libraries at their expected locations relative to the level of the chroot directory.

4.13.1 Running DNS and FTP Services in a Chroot Jail

If the DNS name service daemon (named) runs in a chroot jail, any hacker that enters your system via a BIND exploit is isolated to the files under the chroot jail directory. Installing the bind-chroot package creates the /var/named/chroot directory, which becomes the chroot jail for all BIND files.

You can configure the vsftpd FTP server to automatically start chroot jails for clients. By default, anonymous users are placed in a chroot jail. However, local users that access an vsftpd FTP server are placed in their home directory. Specify the chroot_local_user=YES option in the /etc/vsftpd/vsftpd.conf file to place local users in a chroot jail based on their home directory.

4.13.2 Creating a Chroot Jail

To create a chroot jail:

  1. Create the directory that will become the root directory of the chroot jail, for example:

    sudo mkdir /home/oracle/jail

  2. Use the ldd command to determine which libraries are required by the command that you intend to run in the chroot jail, for example /usr/bin/bash:

    sudo ldd /usr/bin/bash

    The following output is displayed: =>  (0x00007fffdedfe000) => /lib64/ (0x0000003877000000) => /lib64/ (0x0000003861c00000) => /lib64/ (0x0000003861800000)
    /lib64/ (0x0000003861000000)

    Although the path is displayed as /lib64, the actual path is /usr/lib64 because /lib64 is a symbolic link to /usr/lib64. Similarly, /bin is a symbolic link to /usr/bin. You need to recreate such symbolic links within the chroot jail.

  3. Create subdirectories of the chroot jail's root directory that have the same relative paths as the command binary and its required libraries have to the real root directory, for example:

    sudo mkdir -p /home/oracle/jail/usr/bin
    sudo mkdir -p /home/oracle/jail/usr/lib64

  4. Create the symbolic links that link to the binary and library directories in the same manner as the symbolic links that exists in the real root directory.

    sudo ln -s /home/oracle/jail/usr/bin /home/oracle/jail/bin
    sudo ln -s /home/oracle/jail/usr/lib64 /home/oracle/jail/lib64
  5. Copy the binary and the shared libraries to the directories under the chroot jail's root directory, for example:

    sudo cp /usr/bin/bash /home/oracle/jail/usr/bin
    sudo cp /usr/lib64/{,,,} /home/oracle/jail/usr/lib64

4.13.3 Using a Chroot Jail

To run a command in a chroot jail in an existing directory (chroot_jail), use the following command:

sudo chroot chroot_jail command

If you do not specify a command argument, chroot runs the value of the SHELL environment variable or /usr/bin/sh if SHELL is not set.

For example, you would run the /usr/bin/bash command in a chroot jail as follows:

sudo chroot /home/oracle/jail

Note that you can run built-in shell commands such as pwd in this shell, but not other commands unless you have copied their binaries and any required shared libraries to the chroot jail.

For more information, see the chroot(1) manual page.