Implementing Extra Security Features and Best Practices

Working with Core Dumps

A core dump is a file that's produced when a process malfunctions and ends prematurely. 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 ended. You can produce core dumps on-demand or they can be created automatically on termination.

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

Core dumps can contain information that an attacker could exploit. Core dumps can also take up a lot of disk space. Therefore Oracle Linux, by default, disables the core dump function. It does so by limiting the maximum size of a core dump file to 0. You can find the current core size for a system using the following ulimit command. For example, this command shows that the ulimit size for the current terminal user session is set to the default 0 value:

ulimit -c

If you experience problems with an application running in the current terminal session, you can enable core dumps for the session by changing the ulimit -c value to any integer number larger than 0. For example:

ulimit -c 1000

To make changes persist between reboots you can limit or restrict access to core dumps to various 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 don't have read permission from dumping core. To ensure that this setting is still disabled, run the following command:

sysctl fs.suid_dumpable

A value of fs.suid_dumpable = 0 indicates that the setting is still disabled.

Note:

Enabling dump files for these programs isn't recommended. If, for some reason, you need to enable dump files for these programs, you can enable this dump file by setting the fs.suid_dumpable value to 1 or 2. A value of 1 creates core dumps that are readable by the owner of the dumping process. A value of 2 creates core dumps that are only readable by root for debugging purposes.

For more information about temporarily enabling core dumps to troubleshoot a malfunctioning system, see Oracle Linux 8: Monitoring and Tuning the System.

Working with the Automatic Bug Reporting Tool

If the Automatic Bug Reporting Tool, abrt, is running then core dumps continue to be generated for a system, even if you have disabled the core dump facility. On a production system, it can optionally be disabled or uninstalled entirely.

Note:

The Automatic Bug Reporting Tool has been deprecated. Consider using systemd-coredump feature instead. For more information about using the coredumpctl command, see Oracle Linux 8: Monitoring and Tuning the System and the systemd-coredump manual pages.

To stop and disable the abrtd service entirely, run:

sudo systemctl disable --now abrtd

When running the service, you can restrict the service so that it only analyzes core dumps for binaries installed using signed packages. You can also prevent the service from analyzing particular binaries that reveal sensitive information in a dump by adding them to a denylist.

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, \
     /usr/lib*/firefox/plugin-container

Note that although the BlackList and BlackListedPaths options can be used to prevent the service from storing dump data, the dumps are still generated and written to disk for a short time before being removed, so that abrtd can notify system administrators about a crash without using up disk space.

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

IgnoredPaths = /path/to/binary

Configuring and Using Kernel Security Mechanisms

The Linux kernel features some extra 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 run in non-executable memory.

Address Space Layout Randomization

Address Space Layout Randomization (ASLR) can help defeat certain types of buffer overflow attacks. ASLR can find 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:

0: Disable ASLR. This setting is applied if the kernel is booted with the norandmaps boot parameter.
1: Randomize the positions of the stack, virtual dynamic shared object (VDSO) page, and shared memory regions. The base address of the data segment is immediately after the end of the executable code segment.
2: 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:

echo value | sudo tee /proc/sys/kernel/randomize_va_space

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

kernel.randomize_va_space = value

Then, run the sysctl -p command.

If you change the value of randomize_va_space, it's considered good practice to test the application stack to ensure that it's compatible with the new setting.

You can optionally disable ASLR for a specific program and its child processes:

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

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 uses hardware capabilities to protect the system, so it's enabled by default and can't be disabled.

Oracle Linux doesn't emulate the NX bit in software for CPUs that don't implement the NX bit in hardware.

Position Independent Executables

The Position Independent Executables (PIE) feature loads executable binaries at random memory addresses so that the kernel can disallow text relocation. Developers can use this feature 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 stored 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 often indicates whether the PIE flag is set. By default, on Oracle Linux 8 binaries are typically built with this flag set, unless there's a specific reason not to do so, such as a compile issue resulting from setting this option.

Configuring System Cryptograpic Policies

From Oracle Linux 8 onward, Oracle Linux provides a facility to set a system-wide cryptographic policy. Many applications implement cryptographic protocols to secure communications or to encrypt data. Historically, applications have maintained their own configuration of cryptographic policies in various ways, which meant that changing cryptographic policy across an entire system needed to be performed for each application and often the configuration method differed from application to application.

The ability to define a system-wide cryptographic policy that applications can hook into often reduces administrative overhead and simplifies the process. An administrator can configure the system-wide cryptographic policy and have confidence that most applications can use the same policy, by default.

Policies enable an administrator to configure:

TLS/SSL (and DTLS) versions that are accepted
Ciphersuites that are accepted and the preferred order
Parameters that are accepted for certificates and key exchange, including:
- the minimum acceptable size of parameters (DH,ECDH,RSA,DSA,ECDSA),
- the acceptable elliptic curves (ECDH,ECDSA),
- the acceptable signature hash functions.
Other TLS options including safe-renegotiation

Most of the major cryptographic software on Oracle Linux is already configured to use the system-wide cryptographic policy by default. Applications that are configured to behave in this manner include important applications such as OpenSSH and bind, in addition to any applications that use the OpenSSL, GnuTLS, NSS, libkrb5 libraries and

Configuring system-wide policy doesn't enforce behavior across the system. That policy provides a common configuration across a wide variety of applications. Any application that's not designed to use the system-wide policy continues to function according to the different policy configuration that it uses. Many applications also provide options to override the system-wide cryptographic policy if required. For example, OpenSSH provides options to set different cryptographic policies on the server and client applications, and commands such as wget and curl provide options to define a custom cipher selection and order by using the --ciphers option, effectively overriding the system-wide policy.

The system-wide policy defines the default cryptographic behavior within applications so that you can harden a system and remove insecure protocols to match your security requirements.

Oracle Linux 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. That command can be used to either relax policy or to harden it further.

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.

About Predefined Policies

Oracle Linux provides four different built-in predefined cryptographic policies:

LEGACY: Configures certain legacy protocols to maximize compatibility with legacy systems. It includes enabling 3DES, RC1, DSA, TLSv1.0 and TLSv1.1. It also sets a 1024 bit minimum parameter size for DH and RSA. Protocols and values specified in this policy aren't considered highly secure but aren't easily exploitable.
DEFAULT: Configures standard modern protocols including TLSv1.2 and TLSv1.3 , IKEv2 and SSH2. It sets a 2048 bit minimum parameter size for DH and RSA.
FIPS: Configures the system to meet FIPS 140-2 requirements for cryptographic policies. This policy is enabled by the fips-mode-setup command used to enable FIPS mode on an Oracle Linux system. See Configuring a System in FIPS Mode for more information on using this policy.
FUTURE: A conservative policy level that disables SHA-1 and CBC and sets a 3072 bit minimum parameter size for DH and RSA. This policy can disable communications with many older systems but is worth exploring to decide what actions you can perform in future to ensure that applications continue to function securely.

Restrictions in these policies can change over time as new secure default values are decided.

You can use the update-crypto-policies tool to view the current system policy and to change which policy is applied to the system.

Reviewing the Current System-Wide Policy

Any user can review the current system-wide cryptographic policy by running:

update-crypto-policies --show

Setting the System-Wide Policy

Switching between cryptographic policies on Oracle Linux can be achieved using the update-crypto-policies --set command with the name of the policy. For example, to switch to the LEGACY policy, run:

sudo update-crypto-policies --set LEGACY

The policy is updated immediately and any applications that are enabled to use the system-wide cryptographic policy work with the new policy immediately when they're run or restarted. Because some applications might already be running using a custom policy it's good practice to reboot the system after changing policy to ensure that all applications are using the correct policy.

To switch back to the DEFAULT policy, run:

sudo update-crypto-policies --set DEFAULT

Extending a Policy By Using Modules

You can customize the system-wide policy by creating a policy module or a subpolicy. You can fine-tune a policy without needing to create an entire policy from scratch by creating a module. For example, if you intended to use the DEFAULT system policy and also disable the weaker SHA-1 hash functionality in all applications, rather than rewriting the entire DEFAULT system policy, you can apply a module by setting the DEFAULT policy with an appended module for example:

sudo update-crypto-policies --set DEFAULT:NO-SHA1

Oracle Linux provides some extra modules that have already been configured and can be used immediately in the /usr/share/crypto-policies/policies/modules/ directory.

You can create custom modules in the /etc/crypto-policies/policies/modules/ directory. Modules must be named in uppercase and have a lowercase .pmod extension. For example, you can create a module named /etc/crypto-policies/policies/modules/NO-AES-128.pmod to add this content to the file to disable the AES-128 cipher entirely:

# Disable the AES-128 cipher
cipher = -AES-128-*

Note that to disable the cipher, you must prefixed it with a - character. To enable a functionality, specify it without a prefix. In the example, the * character is also used to specify a wildcard so that the rule matches all modes of the AES-128 cipher.

You can also chain modules together when you set the system-wide cryptograpic policy:

sudo update-crypto-policies --set DEFAULT:NO-SHA1:NO-AES-128

For more information about the syntax for policy definition files, see the crypto-policies(7) manual pages.

Creating a New System-Wide Cryptographic Policy

You can create a custom cryptographic policy from scratch instead of using any of the predefined policies provided with Oracle Linux. Policies can be defined in the /etc/crypto-policies/policies/ directory. Policy file names must be uppercase and end in the lowercase suffix .pol. Policy files use the INI file format with standard key = value entries.

The predefined policies provided with Oracle Linux are stored in the /usr/share/crypto-policies/policies/ directory. To define a custom policy, you can copy an existing policy and then configure it as you need. For example:

sudo cp /usr/share/crypto-policies/policies/DEFAULT.pol /etc/crypto-policies/policies/MYPOLICY.pol

See the section titled "CRYPTO POLICY DEFINITON FORMAT" in the crypto-policies(7) manual page for more information about the file format and structure.

When you have finished editing the custom policy, you can enable it with this command:

sudo update-crypto-policies --set MYPOLICY

Remember to reboot the system after enabling a custom system-wide policy so that it's enabled for all running services.

Note:

Consider whether you can achieve what you need to do by extending an existing policy using a module. Maintaining a custom system-wide cryptographic policy requires that you consistently monitor new security standards and research, so by extending the predefined policies to meet security requirements you can avoid needing to maintaining an entire policy by yourself.

Checking User Accounts and Privileges

Checking the system for unlocked user accounts often is considered good security practice, for example by using this command:

for u in $(awk -F: '{print $1}' /etc/passwd;); do sudo passwd -S "$u"; done | sort

The following output is displayed:

adm LK 2023-03-31 0 99999 7 -1 (Alternate authentication scheme in use.)
bin LK 2023-03-31 0 99999 7 -1 (Alternate authentication scheme in use.)
chrony LK 2023-06-20 -1 -1 -1 -1 (Password locked.)
clevis LK 2023-06-20 -1 -1 -1 -1 (Password locked.)
cockpit-wsinstance LK 2023-06-20 -1 -1 -1 -1 (Password locked.)
cockpit-ws LK 2023-06-20 -1 -1 -1 -1 (Password locked.)
...

In the output from this command, the second field shows if a user account is locked (LK), doesn't 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 extra information about the password's status. The unit of time is days.

You can use the passwd command to set passwords on any accounts that aren't protected.

To lock unused accounts, use the passwd -l command. You can also use the userdel command to remove the accounts entirely.

Caution:

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.

Setting	Description
`PASS_MAX_DAYS`	Maximum number of days for which a password can be used before it must be changed. The default value is 99,999 days.
`PASS_MIN_DAYS`	Minimum number of days that's allowed between password changes. The default value is 0 days.
`PASS_WARN_AGE`	Number of days' warning that's provided 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's 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 never locked because of 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:

root

If you install software that creates a default user account and password, it's considered good security practice to change the vendor's default password immediately. Centralized user authentication using an LDAP implementation such as OpenLDAP can centralize user authentication and management tasks, and also reduce the risks arising from unused accounts or accounts without a password.

By default, an Oracle Linux 8 system is configured to prevent users from logging 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 so that system accounting can trace the original username of any user who performs a privileged administrative action. To grant certain users authority to perform specific administrative tasks by using the sudo command, use the visudo command to configure 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 they 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.

Configuring User Authentication and Password Policies

If you follow traditional digital identity policies, the Pluggable Authentication Modules (PAM) feature can be used to enforce strong user authentication and password policies, including rules that decide 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 open. Note that some of these policies are no longer considered helpful for security as they can lead users to implement their own poor security practices when storing passwords or when renewing. See https://pages.nist.gov/800-63-3/sp800-63-3.html for more information.

PAM is highly customizable by its use of different modules with customizable parameters. For example, the default password integrity checking module pam_pwquality.so 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    pam_pwquality.so local_users_only retry=3 authtok_type= enforce_for_root
password    requisite    pam_pwhistory.so use_authtok enforce_for_root remember=4
password    sufficient   pam_unix.so sha512 shadow use_authtok enforce_for_root remember=4
password    sufficient   pam_sss.so use_authtok
password    required     pam_deny.so

The line for pam_pwquality.so defines that a user gets three tries to choose a good password. From the module's default settings, the password length must a minimum of six characters, of which three characters can't 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 pam_unix.so specifies that the module tests the old password that was specified in the stack before prompting for a new password and uses the SHA-512 password hashing and the /etc/shadow file to decide access. Note that pam_pwquality will have performed such checks for users that have been defined in the /etc/passwd file.

You can configure the control flags and module parameters to change the checks that are performed when a user changes their password:

password  required  pam_pwquality.so retry=3 minlen=8 difok=5 minclass=-1
password  required  pam_unix.so use_authtok sha512 shadow remember=5
password  required  pam_deny.so

The line for pam_pwquality.so specifies that a user is allowed three tries 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 uppercase letter, one lowercase letter, one numeric digit, and one special character.

The line for pam_unix.so specifies that the module doesn't 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.

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

Configuring File System Mounts, File Permissions, and File Ownerships

Using separate disk partitions for OS and user data can prevent a "file system full" error from impacting the operation of a server. For example, you can create separate partitions for /home, /tmp, /oracle, and so on.

Establishing disk quotas can prevent a user from filling up a file system (intentionally or not) and therefore denying access to other users.

To prevent the OS files and utilities from being altered during an intrusion, you can mount the /usr file system with read-only permissions. 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, you can 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, you can specify the -o noexec, nosuid, nodev options to mount. These options prevent the execution of binaries (but not scripts), prevent the setuid bit from having any effect, and prevent the use of device files.

To check for unowned files and directories on each file system, use the find command:

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

Unowned files and directories can be associated with a deleted user account, and that might indicate an error with software installation or removal, or they might a sign of an intrusion on the system. You can correct the permissions and ownership of the files and directories that you find, or remove them. Investigating and correcting the problem that led to their creation is considered good security practice.

To check for world-writable directories on each file system, use the find command:

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

Investigating any world-writable directory that's owned by a user other than a system user is considered good security practice. If the user can remove or change any file that other users write to the directory, you can correct the permissions and ownership of any 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 still exploit those executables to run unauthorized code with the rights of the exploited process.

Restricting Access to SSH Connections

The Secure Shell (SSH) provides protected, encrypted communication with other systems. As SSH is an entry point into the system, it's considered good security practice to disable it if it's not required.

You can edit the /etc/ssh/sshd_config file to restrict local access to the root user and remote access to certain users and groups by configuring the settings. 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.

Disabling password-based authentication for SSH and to requiring public key authentication instead is considered good security practice. By doing this, you can limit access to users who own an authorized private key.

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.

Using System Auditing and Monitoring

The Auditing service on Oracle Linux 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 find events of interest can be a significant challenge that you can 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.

Using Advanced Intrusion Detection Environment

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

This tool is installed as follows:

sudo dnf install -y aide

When AIDE is installed, you can change the configuration in /etc/aide.conf. The configuration file is used to decide which files and directories are monitored by AIDE and also how logging and output are handled.

AIDE stores its current information about a system's configuration state in a database stored in the /var/lib/aide/aide.db. If you store a copy of this database file at an external location then you can replace it with a known safe state for AIDE when you perform an audit. If the file doesn't yet exist, you can create one for the current system state by running:

sudo aide --init

sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

When 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!!

If you configure this tool to run as an automated cron job, then you can get regular reports to indicate changes to system configuration and state that could help with early intrusion detection.

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

Implementing System Process Accounting

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

ac: Displays connection times in hours for a user as recorded in the wtmp file (by default, /var/log/wtmp).
accton: Turns on process accounting to the specified file. If you don't specify a file name argument, process accounting is stopped. The default system accounting file is /var/account/pacct.
lastcomm: Displays information about any commands recorded in the system accounting file.
sa: Summarizes information about any commands recorded in the system accounting file.

Note:

Ensure that the file system has enough space to store the system accounting and wtmp files to monitor process activity. Monitoring the size of the log files and truncating them if needed is considered good security practice.

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

Protecting the Root Directory by Using chroot Jails

A chroot command changes the visible root directory for running processes and their children, so it can be used to run a program with a root directory other than /. The program can't see or access files outside of the configured directory tree. Such an artificial root directory is called a "chroot jail", and its purpose is to limit the directory access of malicious processes and hackers. The chroot jail locks down each process and any user ID that's using it so that all they can access is the directory in which the process is running. The process is also tricked into thinking that the directory in which it's running is the root directory.

Note:

The chroot mechanism can't 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 gain access to resources outside 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, it's considered good security practice to ensure that a chroot jail doesn't contain any setuid or setgid executables inside it that are owned by root.

For a chroot process 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.

Running DNS and FTP Services in a Chroot Jail

If the DNS name service daemon (named) runs in a chroot jail, any hacker that accesses a system by using 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.

Creating a Chroot Jail

To create a chroot jail:

Create the directory that becomes the root directory of the chroot jail, for example:
```
sudo mkdir /home/oracle/jail
```
Use the ldd command to decide 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:
```
linux-vdso.so.1 (0x00007fffa5726000)
libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007f29127fa000)
libc.so.6 => /lib64/libc.so.6 (0x00007f29125f1000)
/lib64/ld-linux-x86-64.so.2 (0x00007f291298c000)
```
Note:

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 re-create such symbolic links within the chroot jail.
Create subdirectories of the chroot jail's root directory that have the same relative paths as the command binary and its required libraries in the real root directory, for example:
```
sudo mkdir -p /home/oracle/jail/usr/bin
```
```
sudo mkdir -p /home/oracle/jail/usr/lib64
```
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, for example:
```
sudo ln -s /home/oracle/jail/usr/bin /home/oracle/jail/bin
```
```
sudo ln -s /home/oracle/jail/usr/lib64 /home/oracle/jail/lib64
```

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/{libtinfo.so.5,libdl.so.2,libc.so.6,ld-linux-x86-64.so.2} /home/oracle/jail/usr/lib64

Using a Chroot Jail

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

sudo chroot chroot_jail command

If you don't specify a command argument, chroot runs with the value of the SHELL environment variable, or /usr/bin/sh if SHELL isn't set.

For example, you could 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.