Chapter 4 Implementing Oracle Linux Security

This chapter describes the various ways in which you can configure the security of an Oracle Linux system.

4.1 Configuring Access to Network Services

As networks are usually the primary point of entry point into IT systems, you can use network intrusion prevention and detection tools to help avert or uncover a security breach. You can then take steps such as disabling unused network services and configure a packet-filtering firewall and TCP wrappers.

There are several open-source tools for performing packet logging and analysis. For example, tcpdump and Snort capture TCP traffic and analyze it for suspicious usage patterns, such as those that typically occur with port scans or network DoS attacks. Sguil incorporates tcpdump, Snort, and the Wireshark protocol analyzer to provide a network intrusion and detection system that simplifies log analysis and reporting.

You can check what services are running on a system by using port scanning utilities. The following examples show the information that the netstat, lsof, and nmap commands return about open TCP ports and the associated services:

# netstat -tulp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 localhost:9003*               LISTEN      1776/osms-agent     
tcp        0      0*               LISTEN      1042/rpcbind        
tcp        0      0   *               LISTEN      2051/sshd           
tcp6       0      0 [::]:sunrpc             [::]:*                  LISTEN      1042/rpcbind        
tcp6       0      0 [::]:ssh                [::]:*                  LISTEN      2051/sshd           
udp        0      0*                           1465/dhclient       
udp        0      0*                           1042/rpcbind        
udp        0      0 localhost:323 *                           1062/chronyd        
udp        0      0   *                           1042/rpcbind        
udp6       0      0 [::]:sunrpc             [::]:*                              1042/rpcbind        
udp6       0      0 localhost:323           [::]:*                              1062/chronyd        
udp6       0      0 [::]:789                [::]:*                              1042/rpcbind

# lsof -iTCP -sTCP:LISTEN
rpcbind   1042  rpc    8u  IPv4  19998      0t0  TCP *:sunrpc (LISTEN)
rpcbind   1042  rpc   11u  IPv6  20001      0t0  TCP *:sunrpc (LISTEN)
osms-agen 1776 root   10u  IPv4  26707      0t0  TCP localhost:9003 (LISTEN)
sshd      2051 root    3u  IPv4  25784      0t0  TCP *:ssh (LISTEN)
sshd      2051 root    4u  IPv6  25786      0t0  TCP *:ssh (LISTEN)

# nmap -sTU

Starting Nmap 5.51 ( ) at 2012-12-10 09:37 GMT
Nmap scan report for
Host is up (0.0017s latency).
Not shown: 1993 closed ports
22/tcp   open          ssh
111/tcp  open          rpcbind
68/udp   open|filtered dhcpc
111/udp  open          rpcbind
123/udp  open          ntp
631/udp  open|filtered ipp
5353/udp open|filtered zeroconf

Nmap done: 1 IP address (1 host up) scanned in 12.66 seconds

For more information, see the lsof(8), netstat(8), and nmap(1) manual pages.


Before installing or using the nmap command, check the local legislation relating to port scanning software. In some jurisdictions, the possession or use of port scanning software is considered as unlawful criminal activity. Some ISPs might also have acceptable use policies that forbid using such software outside of your private networks.

The two sections in this chapter, Configuring Packet-Filtering Firewalls and Configuring TCP Wrappers, are specific methods to restrict access to network services.

4.2 Configuring Packet-filtering Firewalls

A packet filtering firewall filters incoming and outgoing network packets based on the packet header information. You can create packet filter rules that determine whether packets are accepted or rejected. For example, if you create a rule to block a port, any request is made to that port that is blocked by the firewall, and the request is ignored. Any service that is listening on a blocked port is effectively disabled.

The Oracle Linux kernel uses the Netfilter feature to provide packet filtering functionality for IPv4 and IPv6 packets.

Netfilter consists of two components:

  • A netfilter kernel component consisting of a set of tables in memory for the rules that the kernel uses to control network packet filtering.

  • Utilities to create, maintain, and display the rules that netfilter stores. In Oracle Linux 7, the default firewall utility is firewall-cmd, which is provided by the firewalld package.

    If you prefer, you can enable the iptables and iptables6 services and use the iptables and ip6tables utilities, provided by the iptables package. These were the default utilities for firewall configuration in Oracle Linux 6.

The firewalld-based firewall has the following advantages over an iptables-based firewall:

  • Unlike the iptables and ip6tables commands, using firewalld-cmd does not restart the firewall and disrupt established TCP connections.

  • firewalld supports dynamic zones, which allow you to implement different sets of firewall rules for systems such as laptops that can connect to networks with different levels of trust. You are unlikely to use this feature with server systems.

  • firewalld supports D-Bus for better integration with services that depend on firewall configuration.

To implement a general-purpose firewall, you can use the Firewall Configuration GUI (firewall-config), provided by the firewall-config package.

Figure 4.1 shows the Firewall Configuration GUI.

Figure 4.1 Firewall Configuration

To create or modify a firewall configuration from the command line, use the firewall-cmd utility (or, if you prefer, the iptables, or ip6tables utilities) to configure the packet filtering rules.

The packet filtering rules are recorded in the /etc/firewalld hierarchy for firewalld and in the /etc/sysconfig/iptables and /etc/sysconfig/ip6tables files for iptables and ip6tables.

4.2.1 Controlling the firewalld Firewall Service

The firewalld service is enabled by default in Oracle Linux 7. You can use the systemctl command to start, stop, or restart the service, and to query its status. Configuring the firewalld Zone

To check the zone for which your system's firewall is configured:

# firewall-cmd --get-active-zone

The command does not display any results if the system has not been assigned to a zone.

Use the following command to display all available zones:

# firewall-cmd --get-zones
block dmz drop external home internal public trusted work

To configure your system for the work zone on a local network connected via the em1 interface:

# firewall-cmd --zone=work --change-interface=em1

Querying the current zone now shows that the firewall is configured on the interface em1 for the work zone:

# firewall-cmd --get-active-zone
  interfaces: em1

To make the change permanent, you can change the default zone for the system, for example:

# firewall-cmd --get-default-zone
# firewall-cmd --set-default-zone=work
# firewall-cmd --get-default-zone
work Controlling Access to Services

You can permit or deny access to a service by specifying its name. The following command lists the services to which access is allowed on the local system for the work zone:

# firewall-cmd --zone=work --list-services
ssh samba 

In this example, the system allows access by SSH and Samba clients.

To permit access by NFS and HTTP clients when the work zone is active, use the --add-service option:

# firewall-cmd --zone=work --add-service=http --add-service=nfs
# firewall-cmd --zone=work --list-services
http nfs ssh samba 

If you do not specify the zone, the change is applied to the default zone, not the currently active zone.

To make rule changes persist across reboots, run the command again, additionally specifying the --permanent option:

# firewall-cmd --permanent --zone=work --add-service=http --add-service=nfs

To remove access to a service, use the --remove-service option, for example:

# firewall-cmd --zone=work --remove-service=samba
# firewall-cmd --permanent --zone=work --remove-service=samba
# firewall-cmd --zone=work --list-services
http nfs ssh Controlling Access to Ports

You can permit or deny access to a port by specifying the port number and the associated protocol. The --list-port option lists the ports and associated protocols to which you have explicitly allowed access, for example:

# firewall-cmd --zone=work --list-ports

You can use the --add-port option to permit access:

# firewall-cmd --zone=work --add-port=5353/udp
# firewall-cmd --permanent --zone=work --add-port=5353/udp
# firewall-cmd --zone=work --list-ports
5353/udp 3689/tcp

Similarly, the --remove-port option removes access to a port. Remember to re-run the command with the --permanant option if you want to make the change persist.

To display all the firewall rules that are defined for a zone, use the --list-all option:

# firewall-cmd --zone=work --list-all
work (default,active)
  interfaces: em1
  services: http nfs ssh
  ports: 5353/udp 3689/tcp
  masquerade: no
  rich rules:

For more information, see the firewall-cmd(1) manual page.

4.2.2 Controlling the iptables Firewall Service

If you want to use iptables instead of firewalld, first stop and disable the firewalld service before starting the iptables firewall service and enabling it to start when the system boots:

# systemctl stop firewalld
# systemctl disable firewalld
# systemctl start iptables
# systemctl enable iptables

To save any changes that you have made to the firewall rules to /etc/sysconfig/iptables, so that the service loads them when it next starts:

# /sbin/iptables-save > /etc/sysconfig/iptables

To restart the service so that it re-reads its rules from /etc/sysconfig/iptables:

# systemctl restart iptables

To stop the service:

# systemctl stop iptables

To control IPv6 filtering, use ip6tables instead of iptables.

For more information, see the iptables(8), and ip6tables(8) manual pages. About netfilter Tables Used by iptables and ip6tables

The netfilter tables used by iptables and ip6tables include:


The default table, which is mainly used to drop or accept packets based on their content.


This table is used to alter certain fields in a packet.


The Network Address Translation table is used to route packets that create new connections.

The kernel uses the rules stored in these tables to make decisions about network packet filtering. Each rule consists of one or more criteria and a single action. If a criterion in a rule matches the information in a network packet header, the kernel applies the action to the packet. Examples of actions include:


Continue processing the packet.


End the packet’s life without notice.


As DROP, and additionally notify the sending system that the packet was blocked.

Rules are stored in chains, where each chain is composed of a default policy plus zero or more rules. The kernel applies each rule in a chain to a packet until a match is found. If there is no matching rule, the kernel applies the chain’s default action (policy) to the packet.

Each netfilter table has several predefined chains. The filter table contains the following chains:


Packets that are not addressed to the local system pass through this chain.


Inbound packets to the local system pass through this chain.


Locally created packets pass through this chain.

The chains are permanent and you cannot delete them. However, you can create additional chains in the filter table. Listing Firewall Rules

Use the iptables -L command to list firewall rules for the chains of the filter table. The following example shows the default rules for a newly installed system:

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source       destination         
ACCEPT     all  --  anywhere     anywhere        state RELATED,ESTABLISHED 
ACCEPT     icmp --  anywhere     anywhere            
ACCEPT     all  --  anywhere     anywhere            
ACCEPT     tcp  --  anywhere     anywhere        state NEW tcp dpt:ssh 
ACCEPT     udp  --  anywhere     anywhere        state NEW udp dpt:ipp 
ACCEPT     udp  --  anywhere     state NEW udp dpt:mdns 
ACCEPT     tcp  --  anywhere     anywhere        state NEW tcp dpt:ipp 
ACCEPT     udp  --  anywhere     anywhere        state NEW udp dpt:ipp 
REJECT     all  --  anywhere     anywhere        reject-with icmp-host-prohibited 

Chain FORWARD (policy ACCEPT)
target     prot opt source       destination         
REJECT     all  --  anywhere     anywhere        reject-with icmp-host-prohibited 

Chain OUTPUT (policy ACCEPT)
target     prot opt source       destination

In this example, the default policy for each chain is ACCEPT. A more secure system could have a default policy of DROP, and the additional rules would only allow specific packets on a case-by-case basis.

If you want to modify the chains, specify the --line-numbers option to see how the rules are numbered.

# iptables -L --line-numbers
Chain INPUT (policy ACCEPT)
num  target     prot opt source           destination         
1    ACCEPT     all  --  anywhere         anywhere        state RELATED,ESTABLISHED 
2    ACCEPT     icmp --  anywhere         anywhere            
3    ACCEPT     all  --  anywhere         anywhere            
4    ACCEPT     tcp  --  anywhere         anywhere        state NEW tcp dpt:ssh 
5    ACCEPT     udp  --  anywhere         anywhere        state NEW udp dpt:ipp 
6    ACCEPT     udp  --  anywhere     state NEW udp dpt:mdns 
7    ACCEPT     tcp  --  anywhere         anywhere        state NEW tcp dpt:ipp 
8    ACCEPT     udp  --  anywhere         anywhere        state NEW udp dpt:ipp 
9    REJECT     all  --  anywhere         anywhere        reject-with icmp-host-prohibited 

Chain FORWARD (policy ACCEPT)
num  target     prot opt source           destination         
1    REJECT     all  --  anywhere         anywhere        reject-with icmp-host-prohibited 

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source           destination Inserting and Replacing Rules in a Chain

Use the iptables -I command to insert a rule in a chain. For example, the following command inserts a rule in the INPUT chain to allow access by TCP on port 80:

# iptables -I INPUT 4 -p tcp -m tcp --dport 80 -j ACCEPT
# iptables -L --line-numbers
Chain INPUT (policy ACCEPT)
num  target     prot opt source           destination         
1    ACCEPT     all  --  anywhere         anywhere        state RELATED,ESTABLISHED 
2    ACCEPT     icmp --  anywhere         anywhere            
3    ACCEPT     all  --  anywhere         anywhere            
4    ACCEPT     tcp  --  anywhere         anywhere        tcp dpt:http 
5    ACCEPT     tcp  --  anywhere         anywhere        state NEW tcp dpt:ssh 
6    ACCEPT     udp  --  anywhere         anywhere        state NEW udp dpt:ipp 
7    ACCEPT     udp  --  anywhere     state NEW udp dpt:mdns 
8    ACCEPT     tcp  --  anywhere         anywhere        state NEW tcp dpt:ipp 
9    ACCEPT     udp  --  anywhere         anywhere        state NEW udp dpt:ipp 
10   REJECT     all  --  anywhere         anywhere        reject-with icmp-host-prohibited 

Chain FORWARD (policy ACCEPT)
num  target     prot opt source           destination         
1    REJECT     all  --  anywhere         anywhere        reject-with icmp-host-prohibited 

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source           destination

The output from iptables -L shows that the new entry has been inserted as rule 4, and the old rules 4 through 9 are pushed down to positions 5 through 10. The TCP destination port of 80 is represented as http, which corresponds to the following definition in the /etc/services file (the HTTP daemon listens for client requests on port 80):

http            80/tcp          www www-http    # WorldWideWeb HTTP

To replace the rule in a chain, use the iptables -R command. For example, the following command replaces rule 4 in the INPUT chain to allow access by TCP on port 443:

# iptables -I INPUT 4 -p tcp -m tcp --dport 443 -j ACCEPT
# iptables -L --line-numbers
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination         
1    ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED 
2    ACCEPT     icmp --  anywhere             anywhere            
3    ACCEPT     all  --  anywhere             anywhere            
4    ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:https

The TCP destination port of 443 is represented as https, which corresponds to the following definition in the /etc/services file for secure HTTP on port 443:

https           443/tcp                         # http protocol over TLS/SSL Deleting Rules in a Chain

Use the iptables -D command to delete a rule in a chain. For example, the following command deletes rule 4 from the INPUT chain:

# iptables -D INPUT 4

To delete all rules in a chain, enter:

# iptables -F chain

To delete all rules in all chains, enter:

# iptables -F Saving Rules

To save your changes to the firewall rules so that they are loaded when the iptables service next starts, use the following command:

# /sbin/iptables-save /etc/sysconfig/iptables

The command saves the rules to /etc/sysconfig/iptables. For IPv6, you can use /sbin/ip6tables-save > /etc/sysconfig/ip6tables to save the rules to /etc/sysconfig/ip6tables.

4.3 Configuring OpenSSH

OpenSSH is suite of network connectivity tools that provides secure communications between systems. OpenSSH provides another layer of protection to your organization by ensuring that network traffic is safe from external threats. For more information, see Oracle® Linux: Connecting to Remote Systems With OpenSSH.

4.4 Configuring TCP Wrappers

TCP wrappers provide basic filtering of incoming network traffic. You can allow or deny access from other systems to certain wrapped network services running on a Linux server. A wrapped network service is one that has been compiled against the libwrap.a library. You can use the ldd command to determine if a network service has been wrapped as shown in the following example for the sshd daemon:

# ldd /usr/sbin/sshd | grep libwrap => /lib64/ (0x00007f877de07000)

When a remote client attempts to connect to a network service on the system, the wrapper consults the rules in the configuration files /etc/hosts.allow and /etc/hosts.deny files to determine if access is permitted.

The wrapper for a service first reads /etc/hosts.allow from top to bottom. If the daemon and client combination matches an entry in the file, access is allowed. If the wrapper does not find a match in /etc/hosts.allow, it reads /etc/hosts.deny from top to bottom. If the daemon and client combination matches and entry in the file, access is denied. If no rules for the daemon and client combination are found in either file, or if neither file exists, access to the service is allowed.

The wrapper first applies the rules specified in /etc/hosts.allow, so these rules take precedence over the rules specified in /etc/hosts.deny. If a rule defined in /etc/hosts.allow permits access to a service, any rule in /etc/hosts.deny that forbids access to the same service is ignored.

The rules take the following form:

daemon_list : client_list [: command] [: deny]

In the previous example, daemon_list and client_list are comma-separated lists of daemons and clients, and the optional command is run when a client tries to access a daemon. You can use the keyword ALL to represent all daemons or all clients. Subnets can be represented by using the * wildcard, for example 192.168.2.*. Domains can be represented by prefixing the domain name with a period (.), for example The optional deny keyword causes a connection to be denied even for rules specified in the /etc/hosts.allow file.

The following are some sample rules.

Match all clients for scp, sftp, and ssh access (sshd).

sshd : ALL

Match all clients on the 192.168.2 subnet for FTP access (vsftpd).

vsftpd : 192.168.2.*

Match all of the clients in the domain to gain access to all wrapped services.


Match all clients for FTP access, and displays the contents of the banner file /etc/banners/vsftpd. The banner file must have the same name as the daemon.

vsftpd : ALL : banners /etc/banners/

Match all of the clients on the 200.182.68 subnet for all wrapped services, and logs all such events. The %c and %d tokens are expanded to the names of the client and the daemon.

ALL : 200.182.68.* : spawn /usr/bin/echo `date` “Attempt by %c to connect to %d" >> /var/log/tcpwr.log

Match all of the clients for scp, sftp, and ssh access, and log the event as an emerg message, which is displayed on the console.

sshd : ALL : severity emerg

Match all of the clients in the domain for scp, sftp, and ssh access, log the event, and deny access (even if the rule appears in /etc/hosts.allow).

sshd : : spawn /usr/bin/echo `date` "sshd access denied for %c" >>/var/log/sshd.log : deny

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

4.5 Using chroot Jails to Protect the Root (/) Directory

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.5.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.5.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:

    # mkdir /home/oracle/jail

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

    # ldd /usr/bin/bash =>  (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:

    # mkdir -p /home/oracle/jail/usr/bin
    # 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.

    # ln -s /home/oracle/jail/usr/bin /home/oracle/jail/bin
    # 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:

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

4.5.3 Using a Chroot Jail

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

# 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, to run /usr/bin/bash in a chroot jail (having previously set it up as described in Section 4.5.2, “Creating a Chroot Jail”):

# chroot /home/oracle/jail
bash-4.2# pwd
bash-4.2# ls
bash: ls: command not found
bash-4.2# exit

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.

4.6 Configuring and Using Software Management

Oracle Linux provides the yum command that you can use to install or upgrade RPM packages. The main benefit of using yum is that it also installs or upgrades any package dependencies. The yum command downloads packages from repositories such as those that are available on the Oracle Linux yum server and the Unbreakable Linux Network (ULN), but you can also set up your own repositories on systems that do not have Internet access.

For more information about managing software with the yum utility, see Oracle® Linux 7: Managing Software.

The Oracle Linux yum server is a convenient way to install Oracle Linux packages rather than installing them from installation media. You can also subscribe to the Oracle Linux errata mailing list, and obtain bug fixes, security fixes and enhancements. You can access the server at

If you have registered your system with ULN, you can use yum with the ULN channels to maintain the software on your system

You can use the RPM package manager to verify the integrity of installed system files. The rpm -V package and rpm -Vf filename commands verify packages and files respectively by comparing them with package metadata in the RPM database. The verify operation compares file size, MD5 sum, permissions, type, owner, and group and displays any discrepancies. To see more verbose information, specify the -v option. You can use the rpm -qa command to verify the integrity of all the packages that are installed on a system, for example:

# for i in `rpm -qa`
> do
> rpm -V $i > .tmp || echo -e "\nDiscepancies for package $i" && cat .tmp
> rm -f .tmp
> done

Discepancies for package gdm-2.30.4-33.0.1.el6_2.x86_64
.M....G..    /var/log/gdm
.M.......    /var/run/gdm
missing     /var/run/gdm/greeter

Discepancies for package libgcj-4.4.6-4.el6.x86_64
..5....T.  c /usr/lib64/security/

Discepancies for package sudo-1.7.4p5-12.el6_3.x86_64
S.5....T.  c /etc/sudoers

Discepancies for package libcgroup-0.37-4.el6.x86_64
S.5....T.  c /etc/cgconfig.conf

Discepancies for package yum-3.2.29-30.0.1.el6.noarch
.......T.  c /etc/yum.conf

Discepancies for package kernel-2.6.32-279.el6.x86_64
.......T.    /etc/

A string of character codes indicates the discrepancies between an installed file and the metadata for that file. The following table describes the meanings of the character codes in the output of the rpm -V command.


Description of Difference


MD5 sum.


Device major or minor number.


Group ownership.


Symbolic link path.


Mode including permissions or file type.




File size.


Modification time.


User ownership.


None (test passed).


Unknown (test could not be performed).

If displayed, a single character code preceding the affected file denotes the file type, and can take the values that are shown in the following table.




Configuration file.


Documentation file.


Ghost file, whose file contents are not included in the package payload.


License file.


Readme file.

Most discrepancies are caused by editing the configuration files of subsystems. To see which files change over time, create a baseline file of discrepancies immediately after installation, and diff this file against the results found by rpm -V at a later date.

You can also use a file integrity checker to test whether a system has been compromised. There are several available open source and commercial file integrity checking tools, including AIDE (Advanced Intrusion Detection Environment) and Tripwire. AIDE and Tripwire are intrusion detection systems that scan file systems and record cryptographic hashes of each file in a database. After creating the database, you should then move it to a read-only medium to avoid tampering. On subsequent file system checks, the tool alerts you if the stored checksums do not match those for the current files. For more information, see the AIDE or Tripwire websites.

For more information, see the yum(8) manual page.

4.6.1 Configuring Update and Patch Management

Effective security practice relies on keeping system software up to date. It is therefore essential to apply system security updates as soon as they are published. It is strongly recommended that you register every IT system with an update management infrastructure. For Oracle Linux systems, the Unbreakable Linux Network (ULN) tracks system software release levels, and advises you as soon as critical updates become available. Updates and errata are also available at no charge from the Oracle Linux yum server.

Updating the kernel or core system libraries typically requires a system reboot. In mission-critical enterprise and cloud environments, crucial updates might not get installed until you reboot the systems during a scheduled maintenance window. As a result, systems that support critical business applications could be running while they are not protected from known vulnerabilities. To tackle this problem, Oracle Linux Premier Support includes access to Oracle Ksplice, an innovative technology that enables you to apply security updates, patches, and critical bug fixes to the running kernel without requiring a reboot. Ksplice improves the security, reliability, and availability of Oracle Linux systems by enabling zero downtime updates, helping to keep systems up to date without downtime or service disruption.

For more information about Ksplice, see

4.6.2 Installing and Using the Yum Security Plugin

The yum-plugin-security package enables you to use the yum command to obtain a list of all of the errata that are available for your system, including security updates. You can also use Oracle Enterprise Manager 12c Cloud Control or management tools such as Katello, Pulp, Red Hat Satellite, Spacewalk, and SUSE Manager to extract and display information about errata.

To install the yum-plugin-security package, enter the following command:

# yum install yum-plugin-security

To list the errata that are available for your system, enter:

# yum updateinfo list
Loaded plugins: refresh-packagekit, rhnplugin, security
ELBA-2012-1518 bugfix         NetworkManager-1:0.8.1-34.el6_3.x86_64
ELBA-2012-1518 bugfix         NetworkManager-glib-1:0.8.1-34.el6_3.x86_64
ELBA-2012-1518 bugfix         NetworkManager-gnome-1:0.8.1-34.el6_3.x86_64
ELBA-2012-1457 bugfix         ORBit2-2.14.17-3.2.el6_3.x86_64
ELBA-2012-1457 bugfix         ORBit2-devel-2.14.17-3.2.el6_3.x86_64
ELSA-2013-0215 Important/Sec. abrt-2.0.8-6.0.1.el6_3.2.x86_64
ELSA-2013-0215 Important/Sec. abrt-addon-ccpp-2.0.8-6.0.1.el6_3.2.x86_64
ELSA-2013-0215 Important/Sec. abrt-addon-kerneloops-2.0.8-6.0.1.el6_3.2.x86_64
ELSA-2013-0215 Important/Sec. abrt-addon-python-2.0.8-6.0.1.el6_3.2.x86_64
ELSA-2013-0215 Important/Sec. abrt-cli-2.0.8-6.0.1.el6_3.2.x86_64
ELSA-2013-0215 Important/Sec. abrt-desktop-2.0.8-6.0.1.el6_3.2.x86_64

The output from the command sorts the available errata in order of their IDs, and it also specifies whether each erratum is a security patch (severity/Sec.), a bug fix (bugfix), or a feature enhancement (enhancement). Security patches are listed by their severity: Important, Moderate, or Low.

You can use the --sec-severity option to filter the security errata by severity, for example:

# yum updateinfo list --sec-severity=Moderate
Loaded plugins: refresh-packagekit, rhnplugin, security
ELSA-2013-0269 Moderate/Sec. axis-1.2.1-7.3.el6_3.noarch
ELSA-2013-0668 Moderate/Sec. boost-1.41.0-15.el6_4.x86_64
ELSA-2013-0668 Moderate/Sec. boost-date-time-1.41.0-15.el6_4.x86_64
ELSA-2013-0668 Moderate/Sec. boost-devel-1.41.0-15.el6_4.x86_64
ELSA-2013-0668 Moderate/Sec. boost-filesystem-1.41.0-15.el6_4.x86_64
ELSA-2013-0668 Moderate/Sec. boost-graph-1.41.0-15.el6_4.x86_64
ELSA-2013-0668 Moderate/Sec. boost-iostreams-1.41.0-15.el6_4.x86_64
ELSA-2013-0668 Moderate/Sec. boost-program-options-1.41.0-15.el6_4.x86_64
ELSA-2013-0668 Moderate/Sec. boost-python-1.41.0-15.el6_4.x86_64

To list the security errata by their Common Vulnerabilities and Exposures (CVE) IDs instead of their errata IDs, specify the keyword cves as an argument:

# yum updateinfo list cves
Loaded plugins: refresh-packagekit, rhnplugin, security
 CVE-2012-5659 Important/Sec. abrt-2.0.8-6.0.1.el6_3.2.x86_64
 CVE-2012-5660 Important/Sec. abrt-2.0.8-6.0.1.el6_3.2.x86_64
 CVE-2012-5659 Important/Sec. abrt-addon-ccpp-2.0.8-6.0.1.el6_3.2.x86_64
 CVE-2012-5660 Important/Sec. abrt-addon-ccpp-2.0.8-6.0.1.el6_3.2.x86_64
 CVE-2012-5659 Important/Sec. abrt-addon-kerneloops-2.0.8-6.0.1.el6_3.2.x86_64
 CVE-2012-5660 Important/Sec. abrt-addon-kerneloops-2.0.8-6.0.1.el6_3.2.x86_64
 CVE-2012-5659 Important/Sec. abrt-addon-python-2.0.8-6.0.1.el6_3.2.x86_64
 CVE-2012-5660 Important/Sec. abrt-addon-python-2.0.8-6.0.1.el6_3.2.x86_64

Similarly, the keywords bugfix, enhancement, and security filter the list for all bug fixes, enhancements, and security errata.

You can use the --cve option to display the errata that correspond to a specified CVE, for example:

# yum updateinfo list --cve CVE-2012-2677
Loaded plugins: refresh-packagekit, rhnplugin, security
ELSA-2013-0668 Moderate/Sec. boost-1.41.0-15.el6_4.x86_64
ELSA-2013-0668 Moderate/Sec. boost-date-time-1.41.0-15.el6_4.x86_64
ELSA-2013-0668 Moderate/Sec. boost-devel-1.41.0-15.el6_4.x86_64
ELSA-2013-0668 Moderate/Sec. boost-filesystem-1.41.0-15.el6_4.x86_64
ELSA-2013-0668 Moderate/Sec. boost-graph-1.41.0-15.el6_4.x86_64
ELSA-2013-0668 Moderate/Sec. boost-iostreams-1.41.0-15.el6_4.x86_64
ELSA-2013-0668 Moderate/Sec. boost-program-options-1.41.0-15.el6_4.x86_64
ELSA-2013-0668 Moderate/Sec. boost-python-1.41.0-15.el6_4.x86_64
ELSA-2013-0668 Moderate/Sec. boost-regex-1.41.0-15.el6_4.x86_64
ELSA-2013-0668 Moderate/Sec. boost-serialization-1.41.0-15.el6_4.x86_64
ELSA-2013-0668 Moderate/Sec. boost-signals-1.41.0-15.el6_4.x86_64
ELSA-2013-0668 Moderate/Sec. boost-system-1.41.0-15.el6_4.x86_64
ELSA-2013-0668 Moderate/Sec. boost-test-1.41.0-15.el6_4.x86_64
ELSA-2013-0668 Moderate/Sec. boost-thread-1.41.0-15.el6_4.x86_64
ELSA-2013-0668 Moderate/Sec. boost-wave-1.41.0-15.el6_4.x86_64
updateinfo list done

To display more information, specify info instead of list, for example:

# yum updateinfo info --cve CVE-2012-2677
Loaded plugins: refresh-packagekit, rhnplugin, security
   boost security update
  Update ID : ELSA-2013-0668
    Release : Oracle Linux 6
       Type : security
     Status : final
     Issued : 2013-03-21
       CVEs : CVE-2012-2677
Description : [1.41.0-15]
            : - Add in explicit dependences between some boost
            :   subpackages
            : [1.41.0-14]
            : - Build with -fno-strict-aliasing
            : [1.41.0-13]
            : - In Boost.Pool, be careful not to overflow
            :   allocated chunk size (boost-1.41.0-pool.patch)
            : [1.41.0-12]
            : - Add an upstream patch that fixes computation of
            :   CRC in zlib streams.
            : - Resolves: #707624
   Severity : Moderate
updateinfo info done

To update all packages for which security-related errata are available to the latest versions of the packages, even if those packages include bug fixes or new features but not security errata, enter:

# yum --security update

To update all packages to the latest versions that contain security errata, ignoring any newer packages that do not contain security errata, enter:

# yum --security update-minimal

To update all kernel packages to the latest versions that contain security errata, enter:

# yum --security update-minimal kernel*

You can also update only those packages that correspond to a CVE or erratum, for example:

# yum update --cve CVE-2012-3954

# yum update --advisory ELSA-2012-1141

Some updates might require you to reboot the system. By default, the boot manager will automatically enable the most recent kernel version.

For more information, see the yum-security(8) manual page.

4.7 Configuring and Using Data Encryption

You can use data encryption to protect data that is stored or that is being transmitted. Data on storage devices and media can be at risk of theft or device loss. Data being transmitted over local area networks and the Internet can be intercepted or altered. In addition, data encryption to protect privacy and personal data is increasingly being made a mandatory requirement of corporate security policy and by governmental regulations (for example, HIPAA, GLBA, SOX, and PCI DSS).

Oracle Linux systems provide the following strategies for protecting data:

  • When installing systems and application software, only accept RPM packages that have been digitally signed. To ensure that downloaded software packages are signed, set gpgcheck=1 in the repository configuration file and import the GPG key provided by the software supplier. You can also install RPMs using the Secure Sockets Layer (SSL) protocol, which uses encryption to protect the communications channel.

  • To protect against data theft, consider using full-disk encryption, especially on laptops, external hard drives, or removable devices such as USB memory sticks. Oracle Linux supports block device encryption using the dm-crypt kernel module and the Linux Unified Key Setup (LUKS) format. The cryptsetup administration command is available in the cryptsetup package. These technologies encrypt device partitions so that the data is inaccessible when a system is turned off. When the system boots and you supply the appropriate passphrase, the device is decrypted and its data is accessible. For more infomation, see the cryptsetup(8) manual page.

  • Oracle Linux uses encryption to support Virtual Private Networks (VPN), Secure Shell (ssh), and password protection. By default, Oracle Linux uses a strong password hashing algorithm (SHA-512) and stores hashed passwords in the /etc/shadow file.

  • Oracle Linux takes advantage of hardware-accelerated encryption on Intel CPUs that support the Advanced Encryption Standard New Instructions (AES-NI) instruction set, which speeds up the execution of AES algorithms as well as SHA-1 and RC4 algorithms on x86 and x86_64 architectures.

4.8 Configuring and Using Certificate Management

Public Key Infrastructure (PKI) provides the tools and framework to encrypt and validate network connections. It also provides an authentication mechanism in the form of signed certificates. Managing your certificates and implementing strong public key infrastructure is an important part of maintaining good security within your organization. For more information, see Oracle® Linux: Managing Certificates and Public Key Infrastructure

4.9 Configuring and Using Authentication

Authentication is a method of verifying the identity of users. The operating system authenticates user names and passwords by comparing this information to data stored on the system. If the login credentials match the data, then access to the system is opened. For more information, see Oracle® Linux 7: Setting Up System Accounts and Authentication.

4.10 Configuring and Using Pluggable Authentication Modules

The Pluggable Authentication Modules (PAM) feature is an authentication mechanism for applications to verify user credentials. For more information, see Oracle® Linux 7: Setting Up System Accounts and Authentication.

4.11 Configuring and Using Access Control Lists

POSIX Access Control Lists (ACLs) provide a richer access control model than traditional UNIX Discretionary Access Control (DAC) that sets read, write, and execute permissions for the owner, group, and all other system users. You can configure ACLs that define access rights for more than just a single user or group, and specify rights for programs, processes, files, and directories. If you set a default ACL on a directory, its descendents inherit the same rights automatically. The kernel provides ACL support for ext3, ext4, and NFS-exported file systems.

The following are examples of setting and displaying ACLs for directories and files.

Grant read access to a file or directory by a user.

# setfacl -m u:user:r file

Display the name, owner, group, and ACL for a file or directory.

# getfacl file

Remove write access to a file for all groups and users by modifying the effective rights mask rather than the ACL.

# setfacl -m m::rx file

Remove the entry for a group from the ACL of a file.

# setfacl -x g:group file

Copy the ACL of file f1 to file f2.

# getfacl f1 | setfacl --set-file=- f2

Promote the ACL settings of a directory to default ACL settings that can be inherited.

# getfacl --access dir | setfacl -d -M- dir

For more information about how to manage ACLs, see the setfacl(1) and getfacl(1) manual pages.

4.12 Configuring and Using SELinux

SELinux is a kernel module that enforces and implements access control policies on Oracle Linux systems to protect services and files from malicious or unauthorized access. Use the SELinux user space tools to manage policies and to resolve access issues. For more information, see Oracle® Linux: Administering SELinux for more info

4.13 Configuring and Using Auditing

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 information, see the auditd.conf(5) manual page.

By default, auditing captures specific events such as system logins, modifications to accounts, and sudo actions. You can also configure auditing to capture detailed system call activity or modifications to certain files. The kernel audit daemon (auditd) records the events that you configure, including the event type, a time stamp, the associated user ID, and success or failure of the system call.

The entries in the audit rules file, /etc/audit/audit.rules, determine which events are audited. Each rule is a command-line option that is passed to the auditctl command. You should typically configure this file to match your site's security policy.

The following are examples of rules that you might set in the /etc/audit/audit.rules file.

Record all unsuccessful exits from open and truncate system calls for files in the /etc directory hierarchy.

-a exit,always -S open -S truncate -F /etc -F success=0

Record all files opened by a user with UID 10.

-a exit,always -S open -F uid=10

Record all files that have been written to or that have their attributes changed by any user who originally logged in with a UID of 500 or greater.

-a exit,always -S open -F auid>=500 -F perm=wa

Record requests for write or file attribute change access to /etc/sudoers, and tag such record with the string sudoers-change.

-w /etc/sudoers -p wa -k sudoers-change

Record requests for write and file attribute change access to the /etc directory hierarchy.

-w /etc/ -p wa

Require a reboot after changing the audit configuration. If specified, this rule should appear at the end of the /etc/audit/audit.rules file.

-e 2

You can find more examples of audit rules in /usr/share/doc/audit-version/stig.rules, and in the auditctl(8) and audit.rules(7) manual pages.

Stringent auditing requirements can impose a significant performance overhead and generate large amounts of audit data. Some site security policies stipulate that a system must shut down if events cannot be recorded because the audit volumes have exceeded their capacity. As a general rule, you should direct audit data to separate file systems in rotation to prevent overspill and to facilitate backups.

You can use the -k option to tag audit records so that you can locate them more easily in an audit volume with the ausearch command. For example, to examine records tagged with the string sudoers-change, you would enter:

# ausearch -k sudoers-change

The aureport command generates summaries of audit data. You can set up cron jobs that run aureport periodically to generate reports of interest. For example, the following command generates a reports that shows every login event from 1 second after midnight on the previous day until the current time:

# aureport -l -i -ts yesterday -te now 

For more information, see the ausearch(8) and aureport(8) manual pages.

4.14 Configuring and Using System Logging

The log files contain messages about the system, kernel, services, and applications. The journald logging daemon, which is part of systemd, records system messages in non-persistent journal files in memory and in the /run/log/journal directory. journald forwards messages to the system logging daemon, rsyslog. As files in /run are volatile, the log data is lost after a reboot unless you create the directory /var/log/journal. You can use the journalctl command to query the journal logs.

For more information, see the journalctl(1) and systemd-journald.service(8) manual pages.

The configuration file for rsyslogd is /etc/rsyslog.conf, which contains global directives, module directives, and rules. By default, rsyslog processes and archives only syslog messages. If required, you can configure rsyslog to archive any other messages that journald forwards, including kernel, boot, initrd, stdout, and stderr messages.

Global directives specify configuration options that apply to the rsyslogd daemon. All configuration directives must start with a dollar sign ($) and only one directive can be specified on each line. The following example specifies the maximum size of the rsyslog message queue:

$MainMsgQueueSize 50000

The available configuration directives are described in the file /usr/share/doc/rsyslog-version-number/rsyslog_conf_global.html.

The design of rsyslog allows its functionality to be dynamically loaded from modules, which provide configuration directives. To load a module, specify the following directive:

$ModLoad MODULE_name

Modules have the following main categories:

  • Input modules gather messages from various sources. Input module names always start with the im prefix (examples include imfile and imrelp).

  • Filter modules allow rsyslogd to filter messages according to specified rules. The name of a filter module always starts with the fm prefix.

  • Library modules provide functionality for other loadable modules. rsyslogd loads library modules automatically when required. You cannot configure the loading of library modules.

  • Output modules provide the facility to store messages in a database or on other servers in a network, or to encrypt them. Output module names always starts with the om prefix (examples include omsnmp and omrelp).

  • Message modification modules change the content of an rsyslog message.

  • Parser modules allow rsyslogd to parse the message content of messages that it receives. The name of a parser module always starts with the pm prefix.

  • String generator modules generate strings based on the content of messages in cooperation with rsyslog's template feature. The name of a string generator module always starts with the sm prefix.

Input modules receive messages, which pass them to one or more parser modules. A parser module creates a representation of a message in memory, possibly modifying the message, and passes the internal representation to output modules, which can also modify the content before outputting the message.

A description of the available modules can be found in RSyslog documentation at

An rsyslog rule consists of a filter part, which selects a subset of messages, and an action part, which specifies what to do with the selected messages. To define a rule in the /etc/rsyslog.conf configuration file, specify a filter and an action on a single line, separated by one or more tabs or spaces.

You can configure rsyslog to filter messages according to various properties. The most commonly used filters are:

  • Expression-based filters, written in the rsyslog scripting language, select messages according to arithmetic, boolean, or string values.

  • Facility/priority-based filters filter messages based on facility and priority values that take the form facility.priority.

  • Property-based filters filter messages by properties such as timegenerated or syslogtag.

The following table lists the available facility keywords for facility/priority-based filters:

Facility Keyword


auth, authpriv

Security, authentication, or authorization messages.


crond messages.


Messages from system daemons other than crond and rsyslogd.


Kernel messages.


Line printer subsystem.


Mail system.


Network news subsystem.


Messages generated internally by rsyslogd.


User-level messages.


UUCP subsystem.

local0 - local7

Local use.

The following table lists the available priority keywords for facility/priority-based filters, in ascending order of importance:

Priority Keyword



Debug-level messages.


Informational messages.


Normal but significant condition.


Warning conditions.


Error conditions.


Critical conditions.


Immediate action required.


System is unstable.

All messages of the specified priority and higher are logged according to the specified action. An asterisk (*) wildcard specifies all facilities or priorities. Separate the names of multiple facilities and priorities on a line with commas (,). Separate multiple filters on one line with semicolons (;). Precede a priority with an exclamation mark (!) to select all messages except those with that priority.

The following are examples of facility/priority-based filters.

Select all kernel messages with any priority.


Select all mail messages with crit or higher priority.


Select all daemon and kern messages with warning or err priority.


Select all cron messages except those with info or debug priority.


By default, /etc/rsyslog.conf includes the following rules:

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.*                                                 /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none                /var/log/messages

# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure

# Log all the mail messages in one place.
mail.*                                                  -/var/log/maillog

# Log cron stuff
cron.*                                                  /var/log/cron

# Everybody gets emergency messages
*.emerg                                                 *

# Save news errors of level crit and higher in a special file.
uucp,news.crit                                          /var/log/spooler

# Save boot messages also to boot.log
local7.*                                                /var/log/boot.log

You can send the logs to a central log server over TCP by adding the following entry to the forwarding rules section of /etc/rsyslog.conf on each log client:

*.*        @@logsvr:port

In the previous example, logsvr is the domain name or IP address of the log server and port is the port number (usually, 514).

On the log server, add the following entry to the MODULES section of /etc/rsyslog.conf:

$ModLoad imtcp
$InputTCPServerRun port

In the previous example, port corresponds to the port number that you set on the log clients.

To manage the rotation and archival of the correct logs, edit /etc/logrotate.d/syslog so that it references each of the log files that are defined in the RULES section of /etc/rsyslog.conf. You can configure how often the logs are rotated and how many past copies of the logs are archived by editing /etc/logrotate.conf.

It is recommended that you configure Logwatch on your log server to monitor the logs for suspicious messages, and disable Logwatch on log clients. However, if you do use Logwatch, disable high precision timestamps by adding the following entry to the GLOBAL DIRECTIVES section of /etc/rsyslog.conf on each system:

$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

For more information, see the logrotate(8), logwatch(8), rsyslogd(8) and rsyslog.conf(5) manual pages, the HTML documentation in the /usr/share/doc/rsyslog-5.8.10 directory, and the documentation at

4.14.1 Configuring Logwatch

Logwatch is a monitoring system that you can configure to report on areas of interest in the system logs. After you install the logwatch package, the /etc/cron.daily/0logwatch script runs every night and sends an email report to root. You can set local configuration options in /etc/logwatch/conf/logwatch.conf that override the main configuration file /usr/share/logwatch/default.conf/logwatch.conf, including:

  • Log files to monitor, including log files that are stored for other hosts.

  • Names of services to monitor, or to be excluded from monitoring.

  • Level of detail to report.

  • User to be sent an emailed report.

You can also run logwatch directly from the command line.

For more information, see the logwatch(8) manual page.

4.15 Configuring and Using 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.16 Configuring and Using Linux Containers

The Linux Containers (LXC) feature provides a way to isolate a group of processes from other processes that are running on an Oracle Linux system. LXC is a lightweight operating system virtualization technology that uses the control group (cgroup) feature to provide resource management and namespace isolation in a similar manner to chroot. Within a container, processes can have their own private view of the operating system with its own process ID space, file system structure, and network interfaces.

See the following documentation:

4.17 Configuring and Using Kernel Security Mechanisms

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

4.17.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:

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

To change the value permanently, add the 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.17.2 Data Execution Prevention

The Data Execution Prevention (DEP) feature prevents an application or service from executing code in a non-executable memory region. Hardware-enforced DEP works in conjunction with the NX (Never eXecute) bit on compatible CPUs. Oracle Linux does not emulate the NX bit in software for CPUs that do not implement the NX bit in hardware.


You cannot disable the DEP feature.

4.17.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. 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 is relocatable, use the following command:

# readelf -d elfname | grep TEXTREL