4.11 Providing secure user access
4.11.1 User authentication: PAM
Pre-Invoke { "mount /usr -o remount,rw" };
Post-Invoke { "mount /usr -o remount,ro" };
};
Note that the Post-Invoke may fail with a “/usr busy” error message. This happens mainly when you are using files during the update that got updated. You can find these programs by running
# lsof +L1
Stop or restart these programs and run the Post-Invoke manually. Beware! This means you’ll likely need to restart your X session (if you’re running one) every time you do a major upgrade of your system. You might want to reconsider whether a read-only /usr is suitable for your system. See also this discussion on debian-devel about read-only /usr (http://lists.debian.org/debian-devel/2001/11/threads.html#00212).
4.11 Providing secure user access
4.11.1 User authentication: PAM
PAM (Pluggable Authentication Modules) allows system administrators to choose how ap-plications authenticate users. Note that PAM can do nothing unless an application is com-piled with support for PAM. Most of the applications that are shipped with Debian have this
support built in (Debian did not have PAM support before 2.2). The current default config-uration for any PAM-enabled service is to emulate UNIX authentication (read /usr/share /doc/libpam0g/Debian-PAM-MiniPolicy.gz for more information on how PAM ser-vices should work in Debian).
Each application with PAM support provides a configuration file in /etc/pam.d/ which can be used to modify its behavior:
• what backend is used for authentication.
• what backend is used for sessions.
• how do password checks behave.
The following description is far from complete, for more information you might want to read the Linux-PAM Guides (http://www.linux-pam.org/Linux-PAM-html/) as a reference.
This documentation is available in the system if you install the libpam-doc at /usr/share /doc/libpam-doc/html/.
PAM offers you the possibility to go through several authentication steps at once, without the user’s knowledge. You could authenticate against a Berkeley database and against the normal passwd file, and the user only logs in if he authenticates correct in both. You can restrict a lot with PAM, just as you can open your system doors very wide. So be careful. A typical configuration line has a control field as its second element. Generally it should be set to requisite, which returns a login failure if one module fails.
Password security in PAM
Review the /etc/pam.d/common-password, included by /etc/pam.d/passwd15 . This file is included by other files in /etc/pam.d/ to define the behaviour of password use in sub-systems that grant access to services in the machine, like the console login (login), graphical login managers (such as gdm or lightdm), and remote login (such as sshd). This definition is You have to make sure that the pam_unix.so module uses the “sha512” option to use encrypted passwords. This is the default in Debian Squeeze.
The line with the definition of the pam_unix module will look something like:
password [success=1 default=ignore] pam_unix.so nullok obscure minlen=8 sha512 This definition:
• Enforces password encryption when storing passwords, using the SHA-512 hash func-tion (opfunc-tion sha512),
15In old Debian releases the configuration of the modules was defined directly in /etc/pam.d/passwd.
• Enables password complexity checks (option obscure) as defined in the pam_unix(8) manpage,
• Imposes a minimum password length (option min) of 8.
You have to ensure that encrypted passwords are used in PAM applications, since this helps protect against dictionary cracks. Using encryption also makes it possible to use passwords longer than 8 characters.
Since this module is also used to define how passwords are changed (it is included by chpasswd) you can strengthen the password security in the system by installing libpam-crackliband introducing this definition in the /etc/pam.d/common-password configuration file:
# Be sure to install libpam-cracklib first or you will not be able to log in password required pam_cracklib.so retry=3 minlen=12 difok=3
password [success=1 default=ignore] pam_unix.so obscure minlen=8 sha512 use_authok So, what does this incantation do? The first line loads the cracklib PAM module, which
pro-vides password strength-checking, prompts for a new password with a minimum size16of 12 characters, and difference of at least 3 characters from the old password, and allows 3 retries.
Cracklib depends on a wordlist package (such as wenglish, wspanish, wbritish, . . . ), so make sure you install one that is appropriate for your language or cracklib might not be useful to you at all.
The second line (using the pam_unix.so module) is the default configuration in Debian, as de-scribed above, save for the use_authok option. The use_authok option is required if pam_unix.so is stacked after pam_cracklib.so, and is used to hand over the password from the previous module. Otherwise, the user would be prompted for the password twice.
For more information about setting up Cracklib, read the pam_cracklib(8) manpage and the article Linux Password Security with pam_cracklib (http://www.deer-run.com/
~hal/sysadmin/pam_cracklib.html) by Hal Pomeranz.
By enabling the cracklib PAM module you setup a policy that forces uses to use strong pass-words.
Alternatively, you can setup and configure PAM modules to use double factor authen-tication such as: libpam-barada, libpam-google-authenticator, libpam-oath, libpam-otpw, libpam-poldi, libpam-usb or libpam-yubico. The configuration of these modules would make it possible to access the system using external authentication mech-anisms such as smartcards, external USB keys, or One-Time-Passwords generated by external applications running, for example, in the user’s mobile phone.
Please note that these restrictions apply to all users but not to the password changes done by the root user. The root user will be able to set up any password (any length or complexity) for himself or others regardless of the restrictions defined here.
16The minlen option is not entirely straightforward and is not exactly the number of characters in the password.
A tradeoff can be defined between complexity and length by adjusting the “credit” parameters of different character classes. For more information read the pam_cracklib(8) manpage.
User access control in PAM
To make sure that the user root can only log into the system from local terminals, the following line should be enabled in /etc/pam.d/login:
auth requisite pam_securetty.so
Then you should modify the list of terminals on which direct root login is allowed in /etc /securetty(as described in ‘Restricting console login access’ on page53). Alternatively, you could enable the pam_access module and modify /etc/security/access.conf which allows for a more general and fine-tuned access control, but (unfortunately) lacks decent log messages (logging within PAM is not standardized and is particularly unrewarding problem to deal with). We’ll return to access.conf a little later.
User limits in PAM
he following line should be enabled in /etc/pam.d/login to set up user resource limits.
session required pam_limits.so
This restricts the system resources that users are allowed (see below in ‘Limiting resource us-age: the limits.conf file’ on the facing page). For example, you could restrict the number of concurrent logins (of a given group of users, or system-wide), number of processes, memory size etc.
Control of su in PAM
If you want to protect su, so that only some people can use it to become root on your system, you need to add a new group “wheel” to your system (that is the cleanest way, since no file has such a group permission yet). Add root and the other users that should be able to su to the root user to this group. Then add the following line to /etc/pam.d/su:
auth requisite pam_wheel.so group=wheel debug
This makes sure that only people from the group “wheel” can use su to become root. Other users will not be able to become root. In fact they will get a denied message if they try to become root.
If you want only certain users to authenticate at a PAM service, this is quite easy to achieve by using files where the users who are allowed to login (or not) are stored. Imagine you only want to allow user ’ref’ to log in via ssh. So you put him into /etc/sshusers-allowed and write the following into /etc/pam.d/ssh:
auth required pam_listfile.so item=user sense=allow file=/etc/sshusers-allowed onerr=fail
Temporary directories in PAM
Since there have been a number of so called insecure tempfile vulnerabilities, thttpd is one example (see DSA-883-1 (http://www.debian.org/security/2005/dsa-883)), the libpam-tmpdiris a good package to install. All you have to do is add the following to /etc /pam.d/common-session:
session optional pam_tmpdir.so
There has also been a discussion about adding this by default in Debian configuration, but it s. Seehttp://lists.debian.org/debian-devel/2005/11/msg00297.htmlfor more information.
Configuration for undefined PAM applications
Finally, but not least, create /etc/pam.d/other and enter the following lines:
auth required pam_securetty.so
auth required pam_unix_auth.so
auth required pam_warn.so
auth required pam_deny.so
account required pam_unix_acct.so
account required pam_warn.so
account required pam_deny.so
password required pam_unix_passwd.so
password required pam_warn.so
password required pam_deny.so
session required pam_unix_session.so
session required pam_warn.so
session required pam_deny.so
These lines will provide a good default configuration for all applications that support PAM (access is denied by default).