summaryrefslogtreecommitdiff
path: root/doc/modules/pam_tally.sgml
blob: 44c6f4ed35a5e974f9e51894823f02245e9463a6 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
<!--

   $Id$
   
   This template file was written by Andrew G. Morgan <morgan@kernel.org>
   adapted from text provided by Tim Baverstock.
-->

<sect1>The login counter (tallying) module

<sect2>Synopsis

<p>
<descrip>

<tag><bf>Module Name:</bf></tag>
pam_tally

<tag><bf>Author[s]:</bf></tag>
Tim Baverstock
Tomas Mraz

<tag><bf>Maintainer:</bf></tag>

<tag><bf>Management groups provided:</bf></tag>
auth; account

<tag><bf>Cryptographically sensitive:</bf></tag>
	
<tag><bf>Security rating:</bf></tag>

<tag><bf>Clean code base:</bf></tag>

<tag><bf>System dependencies:</bf></tag>
A faillog file (default location /var/log/faillog)

<tag><bf>Network aware:</bf></tag>

</descrip>

<sect2>Overview of module

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

<p>
pam_tally comes in two parts: <tt>pam_tally.so</tt> and
<tt>pam_tally</tt>. The former is the PAM module and the latter, a
stand-alone program. <tt>pam_tally</tt> 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.

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

<p>
Note, there are some outstanding issues with this module:
<tt>pam_tally</tt> is very dependant on <tt>getpw*()</tt> - a database
of usernames would be much more flexible

<sect3>Generic options accepted by both components
<p>
<itemize>
<item> <tt>onerr=</tt>(<tt>succeed</tt>|<tt>fail</tt>):
   if something weird happens, such as unable to open the file, how
   should the module react?
<item> <tt>file=</tt><em>/where/to/keep/counts</em>:
   specify the file location for the counts.
   The default location is <tt>/var/log/faillog</tt>.
</itemize>

<sect2>Authentication component

<p>
<descrip>

<tag><bf>Recognized arguments:</bf></tag>
<tt>onerr=</tt>(<tt>succeed</tt>|<tt>fail</tt>);
<tt>file=</tt>/where/to/keep/counts;
<tt>deny=</tt><em>n</em>;
<tt>lock_time=</tt><em>n</em>;
<tt>unlock_time=</tt><em>n</em>;
<tt>magic_root</tt>;
<tt>even_deny_root_account</tt>;
<tt>per_user</tt>;
<tt>no_lock_time</tt>
<tt>no_reset</tt>;

<tag><bf>Description:</bf></tag>

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

<p>
<tag><bf>Examples/suggested usage:</bf></tag>

<p>
The <tt>deny=</tt><em>n</em> option is used to deny access if tally
for this user exceeds <em>n</em>.

<p>
The <tt>lock_time=</tt><em>n</em> option is used to always deny access
for at least <em>n</em> seconds after a failed attempt.

<p>
The <tt>unlock_time=</tt><em>n</em> option is used to allow access after
<em>n</em> 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.

<p>
The <tt>magic_root</tt> 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 <tt>su</tt>, otherwise this argument should be omitted.

<p>
By way of more explanation, when a process already running as root
tries to access some service, the access is <em>magic</em>, and
bypasses <tt>pam_tally</tt>'s checks: this is handy for <tt>su</tt>ing
from root into an account otherwise blocked. However, for services
like <tt>telnet</tt> or <tt>login</tt>, 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.

<p>
Normally, failed attempts to access root will <bf>NOT</bf> 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
<tt>su</tt> or at the machine console (not
<tt>telnet</tt>/<tt>rsh</tt>, etc), this is safe. If you really want
root to be blocked for some given service, use
<tt>even_deny_root_account</tt>.

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

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

<p>
The <tt>no_reset</tt> option is used to instruct the module to not reset
the count on successful entry.

</descrip>

<sect2>Account component

<p>
<descrip>

<tag><bf>Recognized arguments:</bf></tag>
<tt>onerr=</tt>(<tt>succeed</tt>|<tt>fail</tt>);
<tt>file=</tt>/where/to/keep/counts;
<tt>magic_root</tt>;
<tt>no_reset</tt>;

<tag><bf>Description:</bf></tag>

<p>
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.

<tag><bf>Examples/suggested usage:</bf></tag>

<p>
The <tt>magic_root</tt> 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 <tt>su</tt>, otherwise this argument should be omitted.

<p>
The <tt>no_reset</tt> option is used to instruct the module to not reset
the count on successful entry.

</descrip>

<!--
End of sgml insert for this module.
-->