7.1 Physical Security

7.1.1 Delegate Minimal Privileges as Appropriate
7.1.2 About Discretionary and Mandatory Access Control Policies
7.1.3 About Targeted and Multilevel Security Policies
7.1.4 About Security Contexts and Users
7.1.5 Ensure Strong Defenses
7.1.6 Encryption Algorithms, Mechanisms, and Mapping

The first and foremost layer of security you need to take into account is the physical security of the computer systems. How much physical security you need on a system is dependent on your situation and other logistics such as using shared labs, shared systems, deployments in a virtualized environment on a larger server, and so on. The various measures that need to be taken to ensure security involve things such as securing direct physical access to a machine and the security of connected peripheral and devices, as well as restricting access to system details such as BIOS passwords, screen-saver settings, password policies for console login, and so on.

7.1.1 Delegate Minimal Privileges as Appropriate

A privilege is a discrete right that can be granted to an application. With a privilege, a process can perform an operation that would otherwise be prohibited by the operating system. Oracle Linux, like traditional UNIX systems, follows a superuser-based model. Applications check the ID of the user (such as 0 for root) to test for the availability of specific privileges. The sudo command allows a user to execute a command as root or another specified user, provided that they have been granted permission in the /etc/sudoers file. If you want to grant certain users authority to be able to perform specific administrative tasks via sudo, you can use the visudo command to modify the contents of this file.

By default, an Oracle Linux system is configured so that you cannot log in directly as root. You must log in as a named user before using either su or sudo to perform tasks as root. This configuration allows system accounting to trace the original login name of any user who performs a privileged administrative action.

You can also configure SELinux to provide Role-Based Access Control (RBAC). Under this security model, a user's membership of an SELinux domain determines which processes and files he or she can run or access on the system.

7.1.2 About Discretionary and Mandatory Access Control Policies

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. Access to files and devices is based solely on user identity and ownership. Malware or broken software can do anything with files and resources that the user that started the process can do. If the user is root or the application is setuid or setgid to root, the process can have root-access control over the entire file system.

The National Security Agency created Security Enhanced Linux (SELinux) to provide a finer-grained level of control over files, processes, users and applications in the Linux operating system. 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.

The features of SELinux enable an organization to define and implement a security policy on an Oracle Linux system. A security policy is the set of rules and practices that help protect information and other resources, such as computer hardware, at your site. Typically, security rules handle such issues as who has access to which information or who is allowed to write data to removable media. Security practices are recommended procedures for performing tasks.

When security-relevant access occurs, such as when a process attempts to open a file, SELinux intercepts the operation in the kernel. If a MAC policy rule allows the operation, it continues; otherwise, SELinux blocks the operation and returns an error to the process. The kernel checks and enforces DAC policy rules before MAC rules, so it does not check SELinux policy rules if DAC rules have already denied access to a resource.

SELinux should normally run in Enforcing mode where the kernel denies access to users and programs unless permitted by SELinux security policy rules. All denial messages are logged as AVC (Access Vector Cache) denials. If SELinux runs in Permissive mode, the kernel does not enforce security policy rules but SELinux sends denial messages to a log file. This allows you to see what actions would have been denied if SELinux were running in enforcing mode. This mode is intended to used for diagnosing the behavior of SELinux. If you disable SELinux, the kernel uses only DAC rules for access control.

7.1.3 About Targeted and Multilevel Security Policies

An SELinux policy describes the access permissions for all users, programs, processes, and files, and for the devices upon which they act. You can configure SELinux to implement either Targeted Policy or Multilevel Security (MLS) Policy.

Targeted Policy applies access controls to a limited number of processes that are believed to be most likely to be the targets of an attack on the system. Targeted processes run in their own SELinux domain, known as a confined domain, which restricts access to files that an attacker could exploit. If SELinux detects that a targeted process is trying to access resources outside the confined domain, it denies access to those resources and logs the denial. Only specific services run in confined domains. Examples are services that listen on a network for client requests, such as httpd, named, and sshd, and processes that run as root to perform tasks on behalf of users, such as passwd. Other processes, including most user processes, run in an unconfined domain where only DAC rules apply. If an attack compromises an unconfined process, SELinux does not prevent access to system resources and data.

Multilevel Security (MLS) Policy applies access controls to multiple levels of processes with each level having different rules for user access. Users cannot obtain access to information if they do not have the correct authorization to run a process at a specific level. In SELinux, MLS implements the Bell–LaPadula (BLP) model for system security, which applies labels to files, processes and other system objects to control the flow of information between security levels. In a typical implementation, the labels for security levels might range from the most secure, top secret, through secret, and classified, to the least secure, unclassified. For example, under MLS, you might configure a program labelled secret to be able to write to a file that is labelled top secret, but not to be able to read from it. Similarly, you would permit the same program to read from and write to a file labelled secret, but only to read classified or unclassified files. As a result, information that passes through the program can flow upwards through the hierarchy of security levels, but not downwards.

7.1.4 About Security Contexts and Users

Under SELinux, all file systems, files, directories, devices, and processes have an associated security context. For files, SELinux stores a context label in the extended attributes of the file system. The context contains additional information about a system object: the SELinux user, their role, their type, and the security level. SELinux uses this context information to control access by processes, Linux users, and files.

An SELinux user account compliments each regular Oracle Linux user account. SELinux maps every Oracle Linux user to an SELinux user identity that is used in the SELinux context for the processes in a user session.

In the Role-Based Access Control (RBAC) security model, a role acts as an intermediary abstraction layer between SELinux process domains or file types and an SELinux user. Processes run in specific SELinux domains, and file system objects are assigned SELinux file types. SELinux users are authorized to perform specified roles, and roles are authorized for specified SELinux domains and file types. A user's role determines which process domains and file types he or she can access, and hence, which processes and files, he or she can access.

SELinux users form part of a SELinux policy that is authorized for a specific set of roles and for a specific MLS (Multi-Level Security) range, and each Oracle Linux user is mapped to an SELinux user as part of the policy. As a result, Linux users inherit the restrictions and security rules and mechanisms placed on SELinux users. To define the roles and levels of users, the mapped SELinux user identity is used in the SELinux context for processes in a session.

7.1.5 Ensure Strong Defenses

The Internet comprises hundreds of thousands of networks that are interconnected without boundaries. In today's business environment, you will rarely find any standalone servers that cater for meaningful business needs. Network sharing and data sharing have become an essential part of any enterprise system deployment. With the advancement of the Internet and interconnected networks, network security has become essential. Part of almost every organizational network is accessible from other computers across the world and is, therefore, potentially vulnerable to threats from individuals who might not have any physical access. Oracle Linux provides a network security architecture that is based on standard industry interfaces. As security technologies evolve, application developers do not have to modify their code if they use the standardized interfaces.

Oracle Linux provides standard industry interfaces for network security such as PAM, GSS-API, SASL, and PKCS#11, eliminating any need for you to write, maintain, and optimize cryptographic algorithms. Oracle Linux provides optimized cryptographic mechanisms as part of the operating system. This cryptographic framework is the backbone of cryptographic services in Oracle Linux and provides standard PKCS #11 interfaces to accommodate consumers and providers of cryptographic services.

Consumers of cryptographic services need not have any specific knowledge of the installed cryptographic mechanisms. Similarly, providers of cryptographic services can support different types of consumers. You do not have to write consumer-specific code in the providers.

7.1.6 Encryption Algorithms, Mechanisms, and Mapping

Oracle Linux provides cryptographic services to users and applications through individual commands, user-level and kernel-level frameworks, and user and kernel programming interfaces. The cryptographic framework provides these cryptographic services to applications and kernel modules in a seamless manner. Applications can also make use of direct cryptographic services, such as encryption and decryption of files. If a cryptographic accelerator is integrated with the CPU, the cryptographic framework can take advantage of this hardware on behalf of applications.

The available function calls are described in the following manual pages:

  • Arcfour (RC4) in rc4(3)

  • Blowfish in blowfish(3)

  • DES in des(3)

  • MD4 and MD5 in md5(3)

  • RSA in RSA_set_method(3)

  • SHA1 in sha(3)

For information about hardware-assisted encryption and how to benefit from it without making fundamental changes to application code, see Oracle Advanced Security Transparent Data Encryption Best Practices.

For more information about configuring system security, see the Oracle Linux Security Guide.