[OpenAFS] Re: Error logging by pam_afs causes password to appear in log files

[Charles Clancy]

On Thu, 20 Feb 2003, Charles Karney wrote:

> Summary:
>
>     pam_afs logs the username on failed authentication attempts in
>     contexts where the user may accidentally have entered his password.

Most would blame this on the user.

> Problem 1.
>
> Sometimes, when walking up to my blank monitor, I assume that my X
> session is locked, when, in fact, I have logged out.  I then enter my
> password into the "Username" box for gdm.  (My monitor is still warming
> up at this point, so I don't see what's happening.)

As you mentioned below, this is solved by the "nowarn" option.  If you're
interested in a more specific behavior, I can send you a patched version.

> Problem 2.
>
> (A minor nit...)  pam_afs behaves differently with a NULL password
> compared to a non-NULL bad password.

This may have to do with your pam configuration:

> auth        required      /lib/security/pam_env.so
> auth	    sufficient	  /lib/security/pam_afs.so try_first_pass ignore_root
> auth        sufficient    /lib/security/pam_unix.so likeauth nullok

Try the following:

auth required /lib/security/pam_env.so
auth sufficient /lib/security/pam_afs.so ignore_root
auth sufficient /lib/security/pam_unix.so likeauth use_first_pass

First of all, there's no "first_pass" to "try" when pam_afs is
authenticating, because pam_env does not initiate a PAM conversation to
obtain one.

Since you don't have a "use_first_pass" or "try_first_pass" on the
pam_unix.so line, if AFS authentication fails for any reason, it will
always prompt for your UNIX password.  I'm not sure if the "nullok" on
pam_unix is affecting the NULL password behavior, but I don't think it's a
good option to have, in general.

> The first causes the login to fail (with an alert box, which is not the
> standard that other modules use!), and the second causes the system to
> prompt for the Unix password. Why does AFS (klog/pam_afs) treat a NULL
> password specially?  Why not just treat it as a bad password.  This
> would provide more consistent behavior to the user.

The reason you're seeing different behavior is that when a "\0" password
is entered is that pam_afs returns PAM_NEW_AUTHTOK_REQD instead of
PAM_AUTH_ERR.  Your GUI login screen interprets the two differently.
Most applications treat anything !=PAM_SUCCESS as an error, but you seem
to have a smart application.  pam_afs is just trying to currectly use the
PAM return codes.

> Later:
>
> In going over the pam_afs documentation (pam_afs.5) in the openafs 1.2.8
> source tree (why isn't this included in the openafs-client rpm?), I see
> that the security aspect of Problem 1 is fixed by "nowarn".  So perhaps
> this problems are mainly an issue of how the default install is done.
> (The options I used on pam_afs are the ones suggested by the rpm
> installation.)  However, I would still claim that the behavior of
> pam_afs after a failure without the "nowarn" option should be
>
> (a) if the AFS user exists, log "bad password for AFS user USER"
> (b) if the AFS user does not exist, log "unknown AFS user"

The problem is that pam_afs doesn't know why authentication has failed --
be it an invalid username or invalid password.  It can specifically handle
the case where the password is blank, but it still it doesn't know that
it's because you just typed in your password as a username.

As far as the default RPM install, you'd have to talk to the RPM
maintainers.  The PAM options are just printed to the screen, so it's not
like it would be any more difficult for you to use different ones.

[ t charles clancy ]--[ tclancy@uiuc.edu ]--[ www.uiuc.edu/~tclancy ]
[ crypto ]---[ coordinated science lab ]---[ university of illinois ]