Wednesday, May 12, 2010

Controlling login attempts with PAM (Pluggable Authentication Module)

It is generally a good and sensible practice to lock out a user after a number of failed login attempts, with some exceptions. You don't want to give an intruder unlimited attempts, but you don't want clumsy users pestering you all the time for login resets. And users who wish to play practical jokes locking out other users by trying to su to a different user's account, and failing on purpose.

On Debian, add this line to /etc/pam.d/common-auth:

auth required onerr=fail no_magic_root

And this line to /etc/pam.d/common-account:

account required onerr=fail deny=3 reset no_magic_root

On Red Hat, add the above two lines to /etc/pam.d/system-auth. This gives users three chances to log in, then locks them out if they fail. The no_magic_root option is very important -- this prevents the root user from being locked out. In this era of great bootable rescue disks like Knoppix, that's nowhere near the catastrophe it used to be.

When the offending user has sufficiently soothed your upset sensibilities, restore access this way:

# pam_tally --user doofusfred --reset=0
user doofusfred (1006) had 29

It even tattles on how many times the user tried to login.
Read more

Working with User and Group Management

Group Commands

Group definitions reside in the /etc/group file. A standard Linux /etc/group file contains the following information: groupname:x:groupid:user list.

The “x” in the group definition file is a deprecated placeholder for a group password.

To find out which groups you belong to, type groups at a command prompt.

$ groups
khess rdpusers
By default on most Linux systems, when an administrator creates a new user account, the system automatically creates a group account with the same name as the user account. An SA can specify a group when he creates the account but the group must already exist.

Here are two illustrative examples:

# useradd fred

# grep fred /etc/passwd

# grep fred /etc/group
# useradd -g 100 -c "Bob Alobdob" bob

# grep bob /etc/passwd
bob:x:505:100:Bob Alobdob:/home/bob:/bin/bash

# grep bob /etc/group
Why did the system return no response when you typed in grep bob /etc/group? It’s because the users group is Bob’s primary group. If users were a secondary group, Bob’s username would appear in the list. For example, create a new user with rpdusers (Group ID 504) as a secondary group.

# useradd -G 504 -c "Jon Shmon" john

# grep john /etc/passwd
john:x:506:507:Jon Shmon:/home/john:/bin/bash

# grep john /etc/group
A group must exist before you assign users to it. The groupadd command creates new groups with a specific Group ID (GID) and name.

# groupadd -g 1040 accounting

# grep 1040 /etc/group

You may also create a new group with just a group name and the system will assign a GID for you with the command, # groupadd groupname.

The groupmod command allows you to change the group name but the SA will have to change any files associated with the old group manually.

# groupmod -n accounting beancounters
# grep 1040 /etc/group
Note: Don’t confuse chgrp (changes group permissions) with groupmod (changes the name of a group).

You can remove a group with the groupdel command.

# groupdel beancounters
If you prefer to edit configuration files directly, although you shouldn’t, the vigr command edits the /etc/group file in a safe manner by setting locks so that only one administrator at a time can edit the file.

Administrators rely heavily on the “group” commands for group administration, user administration and in scripting those functions for automated solutions.

User Commands

I call this collection of utilities the “user” commands because their functionality centers on user administration and not on action taken by the users themselves. Even if a user knows the location of these commands (/usr/sbin), they still can’t issue them without root privilege.

For example, a clever user on your system tries to issue useradd and vipw.

$ /usr/sbin/useradd steve
useradd: Only root may add a user or group to the system.

$ /usr/sbin/vipw
vipw: Couldn't lock file: Permission denied
vipw: /etc/passwd is unchanged
The User commands have their Group analogs; you add a new user with useradd, modify a user account with usermod and delete a user account with userdel. And you edit the /etc/passwd file directly with vipw. You’ve already seen the useradd command in action in the Group Commands discussion.

The usermod allows Admins to alter any user account attribute including the user’s real name (comment field), home directory name, account expiration date, disabling functionality, group add and change, login name, account locking and unlocking, alter the user’s shell and more.

# grep khess /etc/passwd
khess:x:500:500:Kenneth Hess:/home/khess:/bin/bash

# usermod -c "Ken Hess" khess

# grep khess /etc/passwd
khess:x:500:500:Ken Hess:/home/khess:/bin/bash
The usermod command requires some restraint and careful typing when issuing commands that can make a user account unusable. Let’s say that Bob Alobdob, from an example in the Group discussion, wants his login name and home directory changed to robert.

# usermod -d "/home/robert" -m -l robert bob

# grep robert /etc/passwd
robert:x:505:100:Bob Alobdob:/home/robert:/bin/bash
Notice how I explicitly entered “/home/robert” in the command? If you don’t specify the whole path, Robert won’t have a home directory nor will its contents exist anymore. The command, as shown, changes his current home directory from /home/bob to /home/robert, his login from bob to robert and the -m moves the contents of his “bob” home directory to his “robert” home directory. User permissions change to robert as well for all files in his home directory.

Note: You cannot change the login name of a currently logged in user.

The userdel command’s function might seem obvious to you but you might surprise yourself after issuing the command to find that the user’s home directory is still intact.

Why would any programmer allow that directory to remain as clutter on your home filesystem? This is actually a failsafe mechanism and you should thank the thoughtful programmer who maintains userdel.

What if two user names only differ by a single letter and you removed the wrong one? The incorrectly deleted user’s home directory and files were wiped from the system with a slip of your finger. With the failsafe mechanism in place, you have to manually remove the home directory and hopefully you would catch your error before doing so.
Read more

Shaun Mallette's Blog Design by Insight © 2009