Module Name: pam_tally Author[s]: Tim Baverstock Tomas Mraz Maintainer: Management groups provided: auth; account Cryptographically sensitive: Security rating: Clean code base: System dependencies: A faillog file (default location /var/log/faillog) Network aware: Overview of module

This module maintains a count of attempted accesses, can reset count on success, can deny access if too many attempts fail.

pam_tally comes in two parts: pam_tally.so and pam_tally. The former is the PAM module and the latter, a stand-alone program. pam_tally is an (optional) application which can be used to interrogate and manipulate the counter file. It can display users' counts, set individual counts, or clear all counts. Setting artificially high counts may be useful for blocking users without changing their passwords. For example, one might find it useful to clear all counts every midnight from a cron job.

The counts file is organized as a binary-word array, indexed by uid. You can probably make sense of it with od, if you don't want to use the supplied appliction.

Note, there are some outstanding issues with this module: pam_tally is very dependant on getpw*() - a database of usernames would be much more flexible Generic options accepted by both components

onerr=(succeed|fail): if something weird happens, such as unable to open the file, how should the module react? file=/where/to/keep/counts: specify the file location for the counts. The default location is /var/log/faillog. audit: display the username typed if the user is not found. It may be useful for scripts, but you should know users often type their password instead making your system weaker. Activate it only if you know what you are doing. Authentication component

Recognized arguments: onerr=(succeed|fail); file=/where/to/keep/counts; deny=n; lock_time=n; unlock_time=n; magic_root; even_deny_root_account; per_user; no_lock_time no_reset; Description:

The authentication component first checks if the user should be denied access and if not it increments attempted login counter. Then on call to pam_setcred it resets the attempts counter if the user is NOT magic root.

Examples/suggested usage:

The deny=n option is used to deny access if tally for this user exceeds n.

The lock_time=n option is used to always deny access for at least n seconds after a failed attempt.

The unlock_time=n option is used to allow access after n seconds after the last failed attempt with exceeded tally. If this option is used the user will be locked out only for the specified amount of time after he exceeded his maximum allowed attempts. Otherwise the lock is removed only by a manual intervention of the system administrator.

The magic_root option is used to indicate that if the module is invoked by a user with uid=0, then the counter is not incremented. The sys-admin should use this for user launched services, like su, otherwise this argument should be omitted.

By way of more explanation, when a process already running as root tries to access some service, the access is magic, and bypasses pam_tally's checks: this is handy for suing from root into an account otherwise blocked. However, for services like telnet or login, which always effectively run from the root account, root (ie everyone) shouldn't be granted this magic status, and the flag `magic_root' should not be set in this situation, as noted in the summary above.

Normally, failed attempts to access root will NOT cause the root account to become blocked, to prevent denial-of-service: if your users aren't given shell accounts and root may only login via su or at the machine console (not telnet/rsh, etc), this is safe. If you really want root to be blocked for some given service, use even_deny_root_account.

If /var/log/faillog contains a non-zero .fail_max/.fail_locktime field for this user then the per_user module argument will ensure that the module uses this value and not the global deny/lock_time=n parameter.

The no_lock_time option is for ensuring that the module does not use the .fail_locktime field in /var/log/faillog for this user.

The no_reset option is used to instruct the module to not reset the count on successful entry. Account component

Recognized arguments: onerr=(succeed|fail); file=/where/to/keep/counts; magic_root; no_reset; Description:

The account component resets attempts counter if the user is NOT magic root. This phase can be used optionaly for services which don't call pam_setcred correctly or if the reset should be done regardless of the failure of the account phase of other modules. Examples/suggested usage:

The magic_root option is used to indicate that if the module is invoked by a user with uid=0, then the counter is not decremented/reset. The sys-admin should use this for user launched services, like su, otherwise this argument should be omitted.

The no_reset option is used to instruct the module to not reset the count on successful entry.