Let's talk about user and account security on Linux systems. Once someone has an account on a system, they have greater access to that system. Said another way, it's easier to attack a system if you can gain access to an account on that system. One of the most common attacks is a privilege escalation attack. A privilege escalation attack involves gaining elevated access to resources that are normally protected from a user. A bug in the software running on the system may be exploited or an insecure configuration can be exploited to elevate their privileges. The first line of defense is to keep unwanted users from getting access to an account. The next line of defense is to secure the account so that they only have access to what they need on the system and nothing more. In order to secure the accounts on a Linux system we first need to understand how authentication works on Linux. PAM, which stands for pluggable authentication modules is a centralized authentication mechanism used on Linux systems. Historically, each application had to provide its own method for authenticating users. For example, the login program would directly check the /etc/password and /etc/shadow files to verify the provided username and password were valid. With PAM, applications and services can offload that work to PAM. Now the login program relies on PAM to authenticate users. As new authentication methods become available, authentication modules can be created for those methods and then used by PAM aware applications and services. For example, if you want to use a hardware device connected to your system that scans fingerprints, an authentication module would be used to verify that the fingerprint scanned matches a valid user. The log in command doesn't have to be rewritten to handle fingerprint based authentications, it can simply rely on PAM to do the verification. PAM configuration files live in /etc/pam.d. Each PAM aware application or service has a file for its configuration in the /etc/pam.d directory. For example, the configuration file for the login application is /etc/pam.d/login. While the configuration file for SSHD is /etc/pam.d/sshd. The configuration file contains a list of directives. These directives are comprised of a module interface, a control flag, the module name and any module arguments. PAM uses four different types of module interfaces, these module interfaces correspond to the different aspects of the authorization process. The auth module interface authenticates users. In the most basic scenario it requests and verifies the validity of a password. The account module interface verifies if access is allowed, it checks to make sure that the account isn't locked and its password hasn't expired. If you have configured restrictions for when an account can be used, that is validated with this interface. For example, you could configure account such that they can only be used during normal business hours. The password module interface is used for changing passwords. The session module interface manages sessions. Modules with this interface can perform additional actions such as mounting a user's home directory. Be aware that a module can provide any or all of these interfaces. All PAM modules generate a success or failure result when they are called. Control flags tell PAM what to do with a result. Modules can be listed or stacked in a particular order and the control flags determine how important the success or failure of a particular module is to the overall goal of authenticating the user to the service. When the required control flag is present the module result must be successful for authentication to continue. If the test fails at this point, the user is not notified until the results of all module tests that reference that interface are complete. The requisite control flag is much like the required control flag, however, the user is notified immediately with a message reflecting the first failed require or requisite module test, no other modules are invoked beyond this point. If a module flag with sufficient succeeds and no other required modules have failed then the user is immediately authenticated, no other modules are checked at this point. However, if the module fails and it's ignored in the directives in the configuration file are checked. The optional control flag causes the result of the module to be ignored unless it's the only module that references the interface. The include control flag pulls in or includes all the lines in the configuration file, which match the given parameter and appends them as an argument to the module. This control flag is typically used to pool in configuration that applies to multiple PAM aware services. These control flags that I've just shared with you are called simple control flags. There are many complex control flags that can be set using attribute equals value pairs. A complete list of attributes is available in the pam.d man page.