A server authentication is done by using two of the following three categories, or factors, for providing identity: 

GLYPH<SM590000> Something that you know: A password or PIN 

GLYPH<SM590000> Something that you have: A token, a user ID, a badge, or a certificate 

GLYPH<SM590000> Something that you are: Biometrics characteristics 

The traditional way to authenticate on a Linux server is having a user ID on the system and knowing a password for it. Implementation of more than two of the factors is available for a Linux system, making it possible to request a user ID, a password, and a PIN that is generated by some electronic device, such as a token or an application on a cell phone, when authenticating. Use of more factors for authentication brings a high level of security to what is being accessed. 

The Pluggable Authentication Modules (PAMs) can be used to reinforce compliance with the organization information security policy by increasing the number of factors that are used to authenticate and allowing access only to users meeting the specific characteristics that are defined with PAM. Applications that are enabled to use PAM can be plugged into new technologies without the need to modify the existing applications. This flexibility provides administrators with the following advantages: 

GLYPH<SM590000> Use any available authentication service for an application. 

GLYPH<SM590000> Use multiple authentication mechanisms for a service. 

GLYPH<SM590000> Add authentication service modules without needing to modify the application. 

GLYPH<SM590000> Use a single password for authentication on multiple modules. 

Another factor that improves the security level is the use of PKI, such as an SSH key pair. The users must have a public and private key pair that ensures the user’s ID. Although it is possible to use an SSH key pair without setting a password to it, a password should be set to the key pair. This prevents an attacker who has access to the private key but does not know the password for the user ID from being authenticated at the server. 

## 8.3.2 Access control 

Defining each job role in Linux is complicated because everything converges to the root user ID. However, doing so is a preferred practice that defines the access and provides strong control over who can access a superuser account. 

The discretionary access control (DAC) model, which is standard Linux security, does not provide protection from broken software or malware running as a normal user or root. Users can grant risky levels of access to files they own. 

Use of mandatory access control (MAC) provides full control over all interactions of the software. Administratively defined policy closely controls users and process interactions within the system, and can protect the system from broken software or malware running as any user. 

Security-Enhanced Linux (SELinux) on Red Hat Enterprise Linux (RHEL) is an implementation of MAC that uses Linux Security Models that is based on the principle of least privilege. When enabled in permissive mode, every access to a system resource by a user or process such as an I/O device must be controlled by SELinux. This can sometimes cause extra processing cycles on the system. 

