About System Security

Overview of System Security in Oracle Linux

Oracle Linux provides a complete security stack, from network firewall control to access control security policies, and is designed to be secure by default.

Traditional Linux security is based on a Discretionary Access Control (DAC) policy, which provides minimal protection from broken software or from malware that is running as a normal user or as root. The SELinux enhancement to the Linux kernel implements the Mandatory Access Control (MAC) policy, which allows you to define a security policy that provides granular permissions for all users, programs, processes, files, and devices. The kernel's access control decisions are based on all the security relevant information available, and not solely on the authenticated user identity. By default, SELinux is enabled when you install an Oracle Linux system.

Oracle Linux has evolved into a secure enterprise-class operating system that can provide the performance, data integrity, and application uptime necessary for business-critical production environments.

Thousands of production systems at Oracle run Oracle Linux and numerous internal developers use it as their development platform. Oracle Linux is also at the heart of several Oracle engineered systems, including the Oracle Exadata Database Machine, Oracle Exalytics In-Memory Machine, Oracle Exalogic Elastic Cloud, and Oracle Database Appliance.

Oracle On Demand services, which deliver software as a service (SaaS) at a customer's site, via an Oracle data center, or at a partner site, use Oracle Linux at the foundation of their solution architectures. Backed by Oracle support, these mission-critical systems and deployments depend fundamentally on the built-in security and reliability features of the Oracle Linux operating system.

Released under an open-source license, Oracle Linux includes the Unbreakable Enterprise Kernel that provides the latest Linux innovations while offering tested performance and stability. Oracle has been a key participant in the Linux community, contributing code enhancements such as Oracle Cluster File System and the Btrfs file system. From a security perspective, having roots in open source is a significant advantage. The Linux community, which includes many experienced developers and security experts, reviews posted Linux code extensively prior to its testing and release. The open-source Linux community has supplied many security improvements over time, including access control lists (ACLs), cryptographic libraries, and trusted utilities.

Understanding the Oracle Linux Environment

To better understand your security needs, ask yourself the following questions:

Which resources am I protecting?: Many resources in the production environment can be protected, including information in databases accessed by WebLogic Server and the availability, performance, applications, and the integrity of the Web site. Consider the resources you want to protect when deciding the level of security you must provide.
From whom am I protecting the resources?: For most Web sites, resources must be protected from everyone on the Internet. But should the Web site be protected from the employees on the intranet in your enterprise? Should your employees have access to all resources within the WebLogic Server environment? Should the system administrators have access to all WebLogic resources? Should the system administrators be able to access all data? You might consider giving access to highly confidential data or strategic resources to only a few well trusted system administrators. Perhaps it would be best to allow no system administrators access to the data or resources.
What will happen if the protections on strategic resources fail?: In some cases, a fault in your security scheme is easily detected and considered nothing more than an inconvenience. In other cases, a fault might cause great damage to companies or individual clients that use the Web site. Understanding the security ramifications of each resource will help you protect it properly.

Recommended Deployment Configurations

This section describes recommended architectures for deploying Oracle products with secure Internet access.

Figure 1-1 shows a simple deployment architecture.

Figure 1-1 Simple Firewall Deployment Configuration

The diagram shows a single system that is isolated from the Internet by a single firewall. An arrow shows the direction of connection from the external browser through the firewall to the target system.

This single-computer deployment may be cost effective for small organizations. However, it cannot provide high availability because all components are stored on the same computer.

Figure 1-2 shows the recommended configuration, which uses the well-known and generally accepted Internet-Firewall-DMZ-Firewall-Intranet architecture.

Figure 1-2 DMZ Deployment Configuration

In this diagram, the connection direction from the external browser to the target systems is the same. However, the connection passes through a demilitarized zone (DMZ) that is isolated by firewalls from both the Internet and the intranet, and which acts a buffer between them.

A demilitarized zone (DMZ) refers to a server that is isolated by firewalls from both the Internet and the intranet, and which acts a buffer between them. The firewalls that separate DMZ zones provide two essential functions:

Block any traffic types that are not permitted.
Provide intrusion containment in the event that successful intrusions take over processes or processors.

Component Security

Each application software component usually has its own security considerations that you should take into account independently of those that apply to the operating system. Refer to the security guidelines for each component to determine how best to configure it for the requirements of security at your site.

Basic Security Considerations

The following are fundamental principles for using Oracle Linux securely.

Keep Software Up to Date

One of the principles of good security practice is to keep all software versions and patches up to date. Throughout this document, we assume a maintenance level of Oracle Linux Release 7 or later.

For more information, see Configuring and Using Software Management

Restrict Network Access to Critical Services

Keep both middle-tier applications and databases behind a firewall. In addition, place a firewall between middle-tier applications and databases if these are hosted on separate servers. The firewalls provide assurance that access to these systems is restricted to a known network route, which can be monitored and restricted, if necessary. As an alternative, a firewall router substitutes for multiple, independent firewalls.

If firewalls cannot be used, restrict access based upon IP address. Restricting database access by IP address often causes application client/server programs to fail for DHCP clients. To resolve this, consider using static IP addresses, a software/hardware VPN or Windows Terminal Services or its equivalent.

For more information, see Configuring Access to Network Services.

Follow the Principle of Least Privilege

The principle of least privilege states that users should be given the least amount of privilege to perform their jobs. Over ambitious granting of responsibilities, roles, grants, and so on, especially early on in an organization’s life cycle when people are few and work needs to be done quickly, often leaves a system wide open for abuse. User privileges should be reviewed periodically to determine relevance to current job responsibilities.

For more information, see Checking User Accounts and Privileges.

Monitor System Activity

System security stands on three legs: good security protocols, proper system configuration, and system monitoring. Auditing and reviewing audit records address the third requirement. Each component within a system has some degree of monitoring capability. Follow audit advice in this document and regularly monitor audit records.

For more information, see Configuring and Using Auditing.

Keep Up to Date on the Latest Security Information

Oracle continually improves its software and documentation. Check regularly on the Oracle Technology Network at https://www.oracle.com/technetwork/server-storage/linux for revisions. For information about common vulnerabilities and exposures (CVE) and errata that are available on the Unbreakable Linux Network, see https://linux.oracle.com/cve and https://linux.oracle.com/errata.

Security Considerations for Developers

This chapter discusses principles and guidelines that developers need to follow towards writing secure code.

Design Principles for Secure Coding

The following well-established design principles are recommended for secure coding:

Least privilege: A process or user should be given only those privileges that are necessary to complete a task. User privileges should be assigned according to their role, but not otherwise. To create a minimal protection domain, assign rights when a process or thread requires them and remove them afterwards. This principle limits the potential damage that can result from attacks and user errors.
Economy of mechanism: Keep the design simple. There is less to go wrong, fewer inconsistencies are possible, and the code is easier to understand and debug.
Complete mediation: Check every attempt to access to a resource, not just the first. For example, Linux checks access permissions when a process opens a file but not thereafter. If a file's permissions change while a process has the file open, unauthorized access can result. Ideally, one could argue that the permissions should be checked whenever an open file is accessed. In practise, such checking is considered to be an unnecessary overhead given the circumstances under which access was first obtained.
Open design: Security should not depend on the secrecy of the code's design or implementation, sometimes referred to as security through obscurity. For example, an open back door to a system is only as secure as the knowledge of its existence. Of course, this principle does not apply to information such as passwords or cryptographic keys, knowledge of which should also be shared among as few people as possible. For this reason, many secure authentication schemes also rely on biometric identification or the possession of a physical artifact such a hardware token or smart card, in addition to knowledge of a PIN code or password.
Separation of privilege: Divide the code into modules, where each module requires a specific, limited set of privileges to perform a specific task. Typically, multiple privileges should be required to grant access to a sensitive operation. This principle ensures separation of duty and provides defense in depth. For example, a main thread that has no privileges can generate a privileged thread to perform a task. A successful attack against the main thread thus gains minimal access to the system.
Least common mechanism: A system should isolate users and their activities from each other. Users should not share processes or threads and information channels should not be shared between users.
Fail-safe defaults: The default action should be to deny access to an operation. Should an attempt to perform an operation be denied, the system is as secure as it was before the operation started.
Accountability: Log the user and their privileges for each action that he or she attempts to perform. Any logs should be capable of being rotated and archived to avoid filling up a file system.
Psychological acceptability: Security mechanisms should be easy to install, configure, and use so that a user is less tempted to try to bypass them.

General Guidelines for Secure Coding

The following coding practices are recommended:

Check that input data is what the program expects by performing type, length, and bound checking. Inputs include command-line arguments and environment variables in addition to data that a user enters.
Check input data for the inclusion of constructs such as shell commands, SQL statements, and XML and HTML code that might be used in an injection attack.
Check the type, length, and bounds of arguments to system calls and library routines. If possible, use library routines that guard against buffer overflows.
Use full pathnames for file-name arguments, do not use files in world-writable directories, verify that a file being written to is not actually a symbolic link, and protect against the unintended overwriting of existing files.
Check the type, length, and bounds of values returned by system calls and library routines. Make the code respond appropriately to any error codes that system calls and library functions set or return.
Do not assume the state of the shell environment. Check any settings that a program inherits from the shell, such as the user file-creation mask, signal handling, file descriptors, current working directory, and environment variables, especially PATH and IFS . Reset the settings if necessary.
Perform assert checking on variables that can take a finite set of values.
Log information about privileged actions and error conditions. Do not allow the program to dump a core file on an end-user system.
Do not echo passwords to the screen, or transmit or store them as clear text. Before transmitting or storing a password, combine it with a salt value and use a secure one-way algorithm such as SHA-512 to create a hash.
If your program uses a pseudo-random number generating routine, verify that the numbers that it generates are sufficiently random for your requirements. You should also use a good random seed that a potential attacker should not be able to predict. See RFC 4086, Randomness Requirements for Security, for more information.
It is recommended that Address Space Layout Randomization (ASLR) is enabled on the host system as this feature can help defeat certain types of buffer overflow attacks. See Address Space Layout Randomization.
When compiling and linking your program, use the Position Independent Executables (PIE) feature to generate a position-independent binary. See Position Independent Executables.
Consider using chroot() to confine the operating boundary of your program to a specified location within a file system.
Do not execute a shell command by calling popen() or syscall() from within a program, especially from a setuid or setgid program.

The following guidelines apply if your program has its setuid or setgid bit set so that it can perform privileged actions on behalf of a user who does not possess those privileges:

Do not set the setuid or setgid bit on shell scripts. However, if you use Perl scripts that are setuid or setgid, perl runs in taint mode, which is claimed to be more secure than using the equivalent C code. See the perlsec(1) manual page for details.
Restrict the use of the privilege that setuid or setgid grants to the functionality that requires it, and then return the effective UID or GID to that of the user. If possible, perform the privileged functionality in a separate, closely-monitored thread or process.
Do not allow a setuid or setgid program to execute child processes using execlp() or execvp(), which use the PATH environment variable.

General Guidelines for Network Programs

The following coding practices are recommended for network programs:

Perform a reverse lookup on an IP address to obtain the fully qualified domain name, and then use that domain name look up the IP address. The two IP addresses should be identical.
Protect a service against Denial of Service (DoS) attacks by allowing it to stop processing requests if it becomes overloaded.
Set timeouts on read and write requests over the network.
Check the content, bounds, value, and type of data received over the network, and reject any data that does not conform to what the program expects.
Use certificates or preshared keys to authenticate the local and remote ends of the network connection.
Use a well-established technology such as TLS or SSL to encrypt data sent over the network connection.
Wherever possible, use existing networking protocols and technologies whose security characteristics are well known.
Log information about successful and unsuccessful connection attempts, data reception and transmission errors, and changes to the service state.