4 Implementing Oracle Linux Security
WARNING:
Oracle Linux 7 is now in Extended Support. See Oracle Linux Extended Support and Oracle Open Source Support Policies for more information.
Migrate applications and data to Oracle Linux 8 or Oracle Linux 9 as soon as possible.
This chapter describes the various ways in which you can configure the security of an Oracle Linux system.
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.
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 0.0.0.0:* LISTEN 1776/osms-agent tcp 0 0 0.0.0.0:sunrpc 0.0.0.0:* LISTEN 1042/rpcbind tcp 0 0 0.0.0.0:ssh 0.0.0.0:* LISTEN 2051/sshd tcp6 0 0 [::]:sunrpc [::]:* LISTEN 1042/rpcbind tcp6 0 0 [::]:ssh [::]:* LISTEN 2051/sshd udp 0 0 0.0.0.0:bootpc 0.0.0.0:* 1465/dhclient udp 0 0 0.0.0.0:sunrpc 0.0.0.0:* 1042/rpcbind udp 0 0 localhost:323 0.0.0.0:* 1062/chronyd udp 0 0 0.0.0.0:789 0.0.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
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME 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 10.0.2.15
Starting Nmap 5.51 ( http://nmap.org ) at 2012-12-10 09:37 GMT Nmap scan report for 10.0.2.15 Host is up (0.0017s latency). Not shown: 1993 closed ports PORT STATE SERVICE 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.
Caution:
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.
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 that 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.
-
A
netfilterkernel 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
netfilterstores. In Oracle Linux 7, the default firewall utility is firewall-cmd, which is provided by thefirewalldpackage.If you prefer, you can enable the
iptablesandiptables6services and use the iptables and ip6tables utilities, provided by theiptablespackage. 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.
-
firewalldsupports 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. -
firewalldsupports 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.
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:
sudo 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:
sudo 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:
sudo firewall-cmd --zone=work --change-interface=em1
success
Querying the current zone now shows that the firewall is
configured on the interface em1 for the
work zone:
sudo firewall-cmd --get-active-zone
work interfaces: em1
To make the change permanent, you can change the default zone for the system, for example:
sudo firewall-cmd --get-default-zone
public
sudo firewall-cmd --set-default-zone=work
success
sudo 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:
sudo 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:
sudo firewall-cmd --zone=work --add-service=http --add-service=nfs
success
sudo firewall-cmd --zone=work --list-services
http nfs ssh samba
Note:
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:
sudo firewall-cmd --permanent --zone=work --add-service=http --add-service=nfs
success
To remove access to a service, use the --remove-service option, for example:
sudo firewall-cmd --zone=work --remove-service=samba
success
sudo 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:
sudo firewall-cmd --zone=work --list-ports
3689/tcp
You can use the --add-port option to permit access:
sudo firewall-cmd --zone=work --add-port=5353/udp
success
sudo 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 --permanent 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:
sudo firewall-cmd --zone=work --list-all
work (default,active) interfaces: em1 sources: services: http nfs ssh ports: 5353/udp 3689/tcp masquerade: no forward-ports: icmp-blocks: rich rules:
For more information, see the
firewall-cmd(1) manual page.
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:
sudo systemctl stop firewalld sudo systemctl disable firewalld sudo systemctl start iptables sudo 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:
sudo /sbin/iptables-save > /etc/sysconfig/iptables
To restart the service so that it re-reads its rules from
/etc/sysconfig/iptables:
sudo systemctl restart iptables
To stop the service:
sudo 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 following:
-
Filter -
The default table, which is mainly used to drop or accept packets based on their content.
-
Mangle -
This table is used to alter certain fields in a packet.
-
NAT -
The Network Address Translation table is used to route packets that create new connections.
ACCEPT-
Continue processing the packet.
DROP-
End the packet’s life without notice.
REJECT-
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.
netfilter table has several predefined
chains. The filter table contains the
following chains:
FORWARD-
Packets that are not addressed to the local system pass through this chain.
INPUT-
Inbound packets to the local system pass through this chain.
OUTPUT-
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
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 224.0.0.251 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.
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 224.0.0.251 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
INPUT chain to allow access by
TCP on port 80: sudo iptables -I INPUT 4 -p tcp -m tcp --dport 80 -j ACCEPT sudo 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 224.0.0.251 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
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:
sudo iptables -I INPUT 4 -p tcp -m tcp --dport 443 -j ACCEPT sudo 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
INPUT chain:
sudo iptables -D INPUT 4
To delete all rules in a chain, enter:
sudo iptables -F chainTo delete all rules in all chains, enter:
sudo 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:
sudo /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.
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.
Configuring TCP Wrappers
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:
sudo ldd /usr/sbin/sshd | grep libwrap
libwrap.so.0 => /lib64/libwrap.so.0 (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 an 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 .example.com. 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 example.com
domain to gain access to all wrapped services.
ALL : .example.com
Match all clients for FTP access, and display 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 log 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
emerg message,
which is displayed on the console. sshd : ALL : severity emerg
forbid.com domain for
scp, sftp, and ssh
access, log the event, and deny access (even if the rule appears in
/etc/hosts.allow).
sshd : .forbid.com : 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.
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.
Note:
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.
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.
Creating a Chroot Jail
-
Create the directory that will become the root directory of the chroot jail, for example:
mkdir /home/oracle/jail
-
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
linux-vdso.so.1 => (0x00007fffdedfe000) libtinfo.so.5 => /lib64/libtinfo.so.5 (0x0000003877000000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003861c00000) libc.so.6 => /lib64/libc.so.6 (0x0000003861800000) /lib64/ld-linux-x86-64.so.2 (0x0000003861000000)
Note:
Although the path is displayed as
/lib64, the actual path is/usr/lib64because/lib64is a symbolic link to/usr/lib64. Similarly,/binis a symbolic link to/usr/bin. You need to recreate 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 have to the real root directory, for example:
mkdir -p /home/oracle/jail/usr/bin 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.
ln -s /home/oracle/jail/usr/bin /home/oracle/jail/bin 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:
cp /usr/bin/bash /home/oracle/jail/usr/bin 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 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 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.
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 https://yum.oracle.com/.
If you have registered your system with ULN, you can use yum with the ULN channels to maintain the software on your system
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/classpath.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/ld.so.conf.d/kernel-2.6.32-279.el6.x86_64.conf ...
A string of character codes indicates the discrepancies between an installed file and the metadata for that file. The following list describes the meanings of the character codes in the output of the rpm -V command.
-
5: MD5 sum -
D: Device major or minor number. -
G: Group ownership. -
L: Symbolic link path. -
M: Mode including permissions or file type. -
P: Capabilities. -
S: File size. -
T: Modification time. -
U: 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 list.
-
c: Configuration file. -
d: Documentation file. -
g: Ghost file, whose file contents are not included in the package payload. -
l: License file. -
r: 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.
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 https://oss.oracle.com/ksplice/docs/ksplice-quickstart.pdf.
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.
yum-plugin-security package, enter the following command:
sudo yum install yum-plugin-security
To list the errata that are available for your system, enter:
sudo 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:
sudo 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:
sudo 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:
sudo 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
sudo 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
sudo yum --security update
sudo yum --security update-minimal
To update all kernel packages to the latest versions that contain security errata, enter:
sudo 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 sudo yum update --advisory ELSA-2012-1141
Note:
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.
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).
-
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=1in 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-cryptkernel module and the Linux Unified Key Setup (LUKS) format. The cryptsetup administration command is available in thecryptsetuppackage. 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 thecryptsetup(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/shadowfile. -
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.
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
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 granted. For more information, see Oracle® Linux 7: Setting Up System Accounts and Authentication.
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.
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.
sudo setfacl -m u:user:r file
sudo getfacl file
sudo setfacl -m m::rx file
sudo setfacl -x g:group file
sudo getfacl f1 | setfacl --set-file=- f2
sudo getfacl --access dir | setfacl -d -M- dir
For more information about how to manage ACLs, see the
setfacl(1) and getfacl(1)
manual pages.
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
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.
open and truncate
system calls for files in the /etc directory hierarchy.
-a exit,always -S open -S truncate -F /etc -F success=0
-a exit,always -S open -F uid=10
-a exit,always -S open -F auid>=500 -F perm=wa
/etc/sudoers,
and tag each record with the string sudoers-change.
-w /etc/sudoers -p wa -k sudoers-change
/etc
directory hierarchy. -w /etc/ -p wa
/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:
sudo 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:
sudo aureport -l -i -ts yesterday -te now
For more information, see the ausearch(8) and
aureport(8) manual pages.
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.
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.
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
-
Input modules gather messages from various sources. Input module names always start with the
imprefix (examples includeimfileandimrelp). -
Filter modules allow
rsyslogdto filter messages according to specified rules. The name of a filter module always starts with thefmprefix. -
Library modules provide functionality for other loadable modules.
rsyslogdloads 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 start with the
omprefix (examples includeomsnmpandomrelp). -
Message modification modules change the content of an
rsyslogmessage. -
Parser modules allow
rsyslogdto parse the message content of messages that it receives. The name of a parser module always starts with thepmprefix. -
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 thesmprefix.
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 https://www.rsyslog.com/doc/.
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.
rsyslog to filter messages
according to various properties. The most commonly used filters
are:
-
Expression-based filters, written in the
rsyslogscripting 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
timegeneratedorsyslogtag.
The following list identifies the available facility keywords for facility/priority-based filters:
-
auth,authpriv: Security, authentication, or authorization messages. -
cron:crondmessages. -
daemon: Messages from system daemons other thancrondandrsyslogd. -
kern: Kernel messages. -
lpr: Line printer subsystem. -
mail: Mail system. -
news: Network news subsystem. -
syslog: Messages generated internally byrsyslogd. -
user: User-level messages. -
UUCP: UUCP subsystem. -
local0-local7: Local use.
The following list identifies the available priority keywords for facility/priority-based filters, in ascending order of importance:
-
debug: Debug-level messages. -
info: Informational messages. -
notice: Normal but significant condition. -
warning: Warning conditions. -
err: Error conditions. -
crit: Critical conditions. -
alert: Immediate action required. -
emerg: 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.
kern.*Select all mail messages with
crit or higher priority. mail.crit
daemon and kern messages with
warning or err priority.
daemon,kern.warning,errSelect all
cron messages except those with
info or debug priority. cron.!info,!debug
/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
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).
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.
/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
https://www.rsyslog.com/doc/.
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.
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:
- ac
-
Displays connection times in hours for a user as recorded in the
wtmpfile (by default,/var/log/wtmp). - accton
-
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. - lastcomm
-
Displays information about previously executed commands as recorded in the system accounting file.
- sa
-
Summarizes information about previously executed commands as recorded in the system accounting file.
Note:
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.
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:
-
See Oracle® Linux 7: Working With LXC for more information about how to configure and use Linux Containers.
-
Oracle Cloud Native Environment documentation at https://docs.oracle.com/en/operating-systems/olcne/.
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.
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:
-
0: Disable ASLR. This setting is applied if the kernel is booted with the
norandmapsboot 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 located 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 > /proc/sys/kernel/randomize_va_space
To change the value permanently, add the setting to
/etc/sysctl.conf, for example:
kernel.randomize_va_space = valueThen, 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 ...]
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.
Note:
You cannot disable the DEP feature.
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:
sudo readelf -d elfname | grep TEXTREL