Linux pam run script

The Linux Pluggable Authentication Modules (PAM) provide a framework for system-wide user authentication. To quote the project:

PAM provides a way to develop programs that are independent of authentication scheme. These programs need «authentication modules» to be attached to them at run-time in order to work. Which authentication module is to be attached is dependent upon the local system setup and is at the discretion of the local system administrator.

This article explains the Arch Linux base set-up defaults for PAM to authenticate local and remote users. Applying changes to the defaults is subject of crosslinked specialized per topic articles.

Installation

The pam package is a dependency of the base meta package and, thereby, normally installed on an Arch system. The PAM modules are installed into /usr/lib/security exclusively.

The repositories contain a number of optional PAM packages, the #Configuration How-Tos show examples.

Configuration

A number of /etc paths are relevant for PAM, execute pacman —query —list pam | grep /etc to see the default configuration files created. They relate to either #Security parameters for the modules, or the #PAM base-stack configuration.

Security parameters

The path /etc/security contains system-specific configuration for variables the authentication methods offer. The base install populates it with default upstream configuration files.

Note Arch Linux does not provide distribution-specific configuration for these files. For example, the /etc/security/pwquality.conf file can be used to define system-wide defaults for password quality. Yet, to enable it the pam_pwquality.so module has to be added to the #PAM base-stack of modules, which is not the case per default.

See #Security parameter configuration for some of the possibilities.

PAM base-stack

The /etc/pam.d/ path is exclusive for the PAM configuration to link the applications to the individual systems’ authentication schemes. During installation of the system base it is populated by:

the pambase package, which contains the base-stack of Arch Linux specific PAM configuration to be used by applications, and
other base packages. For example, util-linux adds configuration for the central login and other programs, the shadow package adds the Arch Linux defaults to secure and modify the user database (see Users and groups).

The different configuration files of the base installation link together and are stacked during runtime. For example, on a local user logon, the login application sources the system-local-login policy, which in turn sources others:

For a different application, a different path may apply. For example, openssh installs its sshd PAM policy:

Consequently, the choice of the configuration file in the stack matters. For the above example, a special authentication method could be required for sshd only, or all remote logins by changing system-remote-login ; both changes would not affect local logins. Applying the change to system-login or system-auth instead would affect local and remote logins.

Like the example of sshd , any pam-aware application is required to install its policy to /etc/pam.d in order to integrate and rely on the PAM stack appropriately. If an application fails to do it, the /etc/pam.d/other default policy to deny and log a warning is applied.

The PAM package manual pages pam(8) and pam.d(5) describe the standardized content of the configuration files. In particular they explain the four PAM groups: account, authentication, password, and session management, as well as the control values that may be used to configure stacking and behavior of the modules.

Additionally, extensive documentation is installed to /usr/share/doc/Linux-PAM/index.html which, among various guides, contains browsable man pages for each of the standard modules.

Examples

The factual accuracy of this article or section is disputed.

Two short examples to illustrate the above warning.

First, we take the following two lines:

The authentication component pam_unix.so performs the task of checking the users credentials (password). The default action of this module is to not permit the user access to a service if their official password is blank.

— the latter being what pam_permit.so is used for. Simply swapping the control values required and optional for both lines is enough to disable password authentication, i.e. any user may logon without providing a password.

Second, as the contrary example, per default configuration of pam_nologin.so at /etc/pam.d/login, creating the following file:

results in that no user other than root may login (if root logins are allowed, another default for Arch Linux). To allow logins again, remove the file. Possibly, from the console you created it with.

With that as background, see #PAM stack and module configuration for particular use-case configuration.

Configuration How-Tos

This section provides an overview of content detailing how to apply changes to the PAM configuration and how to integrate special new PAM modules into the PAM stack. Note the man pages for the modules can generally be reached dropping the .so extension.

Security parameter configuration

The following sections describe examples to change the default PAM parameter configuration:

Security#Enforcing strong passwords with pam_pwquality

shows how to enforce strong passwords with pam_cracklib.so .

Security#Lock out user after three failed login attempts

shows how to configure the limits on login attempts with pam_faillock.so .

Security#Allow only certain users

limits user logons with pam_wheel.so .

Realtime process management#Configuring PAM and Security#Limit amount of processes

detail how to configure system process limits with pam_limits.so .

Environment variables#Using pam_env

shows examples to set environment variables via pam_env.so .

PAM stack and module configuration

The following articles detail how to change the #PAM base-stack for special use-cases.

pam_mount

detail examples for using pam_mount.so to automount encrypted directory paths on user login.

ECryptfs#Auto-mounting

uses pam_ecryptfs.so to automount an encrypted directory.

Dm-crypt/Mounting at login

shows how to use pam_exec.so to execute a custom script on a user login.

Active Directory integration#Configuring PAM

uses pam_winbind.so and pam_krb5.so to let users authenticate via Active Directory (LDAP, Kerberos) services.

LDAP authentication with its LDAP authentication#NSS and PAM section

is an article about integrating LDAP client or server-side authentication with pam_ldap.so .

YubiKey#Linux user authentication with PAM

describes how to use U2F ( pam_u2f.so ) and the proprietary Yubico OTP implementation ( pam_yubico.so ) provided by the YubiKey with PAM

pam_oath

shows an example to implement software based two-factor authentication with pam_oath.so .

fprint

employs pam_fprintd.so to setup fingerprint authentication.

pam_usb

shows how to configure pam_usb.so to use an usb-device for, optionally two-factor, authentication.

SSH keys#pam_ssh

uses pam_ssh.so to authenticate as a remote user.

pam_abl

explains how pam_abl.so can be used to limit brute-forcing attacks via ssh.

EncFS

may get automounted via pam_encfs.so .

Google Authenticator

shows how to set up two-factor authentication with pam_google_authenticator.so .

Very Secure FTP Daemon#PAM with virtual users

explains how to configure a FTP chroot with pam_pwdfile.so to authenticate users without a local system account.

Further PAM packages

Other than those packages mentioned so far, the Arch User Repository contains a number of additional PAM modules and tools.

General purpose utilities relating to PAM are:

Note the AUR features a keyword tag for PAM, but not all available packages are updated to include it. Hence, searching the package description may be necessary.

Источник

How to Configure and Use PAM in Linux

Linux-PAM (short for Pluggable Authentication Modules which evolved from the Unix-PAM architecture) is a powerful suite of shared libraries used to dynamically authenticate a user to applications (or services) in a Linux system.

It integrates multiple low-level authentication modules into a high-level API that provides dynamic authentication support for applications. This allows developers to write applications that require authentication, independently of the underlying authentication system.

Many modern Linux distributions support Linux-PAM (hereinafter referred to as “PAM”) by default. In this article, we will explain how to configure advanced PAM in Ubuntu and CentOS systems.

Before we proceed any further, note that:

As a system administrator, the most important thing is to master how PAM configuration file(s) define the connection between applications (services) and the pluggable authentication modules (PAMs) that perform the actual authentication tasks. You don’t necessarily need to understand the internal working of PAM.
PAM has the potential to seriously alter the security of your Linux system. Erroneous configuration can disable access to your system partially, or completely. For instance an accidental deletion of a configuration file(s) under /etc/pam.d/* and/or /etc/pam.conf can lock you out of your own system!

How to Check a Program is PAM-aware

To employ PAM, an application/program needs to be “PAM aware“; it needs to have been written and compiled specifically to use PAM. To find out if a program is “PAM-aware” or not, check if it has been compiled with the PAM library using the ldd command.

For example sshd:

How to Configure PAM in Linux

The main configuration file for PAM is /etc/pam.conf and the /etc/pam.d/ directory contains the PAM configuration files for each PAM-aware application/services. PAM will ignore the file if the directory exists.

The syntax for the main configuration file is as follows. The file is made up of a list of rules written on a single line (you can extend rules using the “\” escape character) and comments are preceded with “#” marks and extend to the next end of line.

The format of each rule is a space separated collection of tokens (the first three are case-insensitive). We will explain the these tokens in subsequent sections.

service: actual application name.
type: module type/context/interface.
control-flag: indicates the behavior of the PAM-API should the module fail to succeed in its authentication task.
module: the absolute filename or relative pathname of the PAM.
module-arguments: space separated list of tokens for controlling module behavior.

The syntax of each file in /etc/pam.d/ is similar to that of the main file and is made up of lines of the following form:

This is a example of a rule definition (without module-arguments) found in the /etc/pam.d/sshd file, which disallows non-root logins when /etc/nologin exists:

Understanding PAM Management Groups and Control-flags

PAM authentication tasks are separated into four independent management groups. These groups manage different aspects of a typical user’s request for a restricted service.

A module is associated to one these management group types:

account: provide services for account verification: has the user’s password expired?; is this user permitted access to the requested service?.
authentication: authenticate a user and set up user credentials.
password: are responsible for updating user passwords and work together with authentication modules.
session: manage actions performed at the beginning of a session and end of a session.

PAM loadable object files (the modules) are to be located in the following directory: /lib/security/ or /lib64/security depending on the architecture.

The supported control-flags are:

requisite: failure instantly returns control to the application indicating the nature of the first module failure.
required: all these modules are required to succeed for libpam to return success to the application.
sufficient: given that all preceding modules have succeeded, the success of this module leads to an immediate and successful return to the application (failure of this module is ignored).
optional: the success or failure of this module is generally not recorded.

In addition to the above are the keywords, there are two other valid control flags:

include and substack: include all lines of given type from the configuration file specified as an argument to this control.

How to Restrict root Access to SSH Service Via PAM

As an example, we will configure how to use PAM to disable root user access to a system via SSH and login programs. Here, we want to disable root user access to a system, by restricting access to login and sshd services.

We can use the /lib/security/pam_listfile.so module which offers great flexibility in limiting the privileges of specific accounts. Open and edit the file for the target service in the /etc/pam.d/ directory as shown.

Add this rule in both files.

Explaining the tokens in the above rule:

auth: is the module type (or context).
required: is a control-flag that means if the module is used, it must pass or the overall result will be fail, regardless of the status of other modules.
pam_listfile.so: is a module which provides a way to deny or allow services based on an arbitrary file.
onerr=succeed: module argument.
item=user: module argument which specifies what is listed in the file and should be checked for.
sense=deny: module argument which specifies action to take if found in file, if the item is NOT found in the file, then the opposite action is requested.
file=/etc/ssh/deniedusers: module argument which specifies file containing one item per line.

Next, we need to create the file /etc/ssh/deniedusers and add the name root in it:

Save the changes and close the file, then set the required permissions on it:

From now on, the above rule will tell PAM to consult the /etc/ssh/deniedusers file and deny access to the SSH and login services for any listed user.

How to Configuring Advanced PAM in Linux

To write more complex PAM rules, you can use valid control-flags in the following form:

Where valueN corresponds to the return code from the function invoked in the module for which the line is defined. You can find supported values from the on-line PAM Administrator’s Guide. A special value is default, which implies all valueN’s not mentioned explicitly.

The actionN can take one of the following forms:

ignore: if this action is used with a stack of modules, the module’s return status will not contribute to the return code the application obtains.
bad: indicates that the return code should be thought of as indicative of the module failing. If this module is the first in the stack to fail, its status value will be used for that of the whole stack.
die: equivalent to bad but may terminate the module stack and PAM immediately returning to the application.
ok: this instructs PAM that the system administrator thinks this return code should contribute directly to the return code of the full stack of modules.
done: equivalent to ok but may terminate the module stack and PAM immediately returning to the application.
N (an unsigned integer): equivalent to ok but may jump over the next N modules in the stack.
Reset: this action clears all memory of the state of the module stack and restart with the next stacked module.

Each of the four keywords: required; requisite; sufficient; and optional, have an equivalent expression in terms of the [. ] syntax, which allow you to write more complicated rules and they are:

required: [success=ok new_authtok_reqd=ok ignore=ignore default=bad]
requisite: [success=ok new_authtok_reqd=ok ignore=ignore default=die]
sufficient: [success=done new_authtok_reqd=done default=ignore]
optional: [success=ok new_authtok_reqd=ok default=ignore]

The following is an example from a modern CentOS 7 system. Let’s consider these rules from the /etc/pam.d/postlogin PAM file:

Here is another example configuration from the /etc/pam.d/smartcard-auth PAM file:

For more information, see the pam.d man page:

Lastly, a comprehensive description of the Configuration file syntax and all PAM modules can be found in the documentation for Linux-PAM.

Summary

PAM is a powerful high-level API that allows programs that rely on authentication to authentic users to applications in a Linux system. It’s powerful but very challenging to understand and use.

In this article, we’ve explained how to configure advanced features of PAM in Ubuntu and CentOS. If you have any questions or comments to share, use the feedback form below.

If You Appreciate What We Do Here On TecMint, You Should Consider:

TecMint is the fastest growing and most trusted community site for any kind of Linux Articles, Guides and Books on the web. Millions of people visit TecMint! to search or browse the thousands of published articles available FREELY to all.

If you like what you are reading, please consider buying us a coffee ( or 2 ) as a token of appreciation.

We are thankful for your never ending support.

Источник

Linux pam run script