[Bug 1215] sshd requires entry from getpwnam for PAM accounts

[bugzilla-daemon at bugzilla.mindrot.org]

http://bugzilla.mindrot.org/show_bug.cgi?id=1215


Jesse Zbikowski <embeddedlinuxguy at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |embeddedlinuxguy at gmail.com




--- Comment #7 from Jesse Zbikowski <embeddedlinuxguy at gmail.com>  2007-05-19 11:21:19 ---
Darren, thanks for this patch.  I am using it to authenticate TACACS+
users using pam_tacplus.  However I can't get it to do authorization in
a sane way.

The user mapping is done immediately after authentication.  This means
I can't use TACACS+ for authorization.  For my experiment, I hacked
pam_tacplus to set the PAM username to "op", which is a valid Unix
user, following authentication.  When ssh then makes the authorization
request, it tries to authorize "op", which TACACS+ doesn't know about
-- rather than the original TACACS+ user.  /etc/pam.d/ssh then falls
back to system-auth (in Fedora 5, this is basically pam_unix.so
passwd-based authorization).  So the effect is, all authenticated
TACACS+ users get authorized, even if they don't have the desired
service/protocol a/v pairs.  I believe the user mapping should be
performed as the last step, after pam_acct_mgmt() (i.e. authorization)
and pam_open_session() (i.e. accounting).

Worse: after authorizing "op" via system-auth, the PAM username gets
set to "root".  Thus pam_open_session() is sending accounting data for
"root" to the TACACS+ server, and the user gets a root shell. 
Presumably the username gets set to "root" by pam_unix.so.

To work around this, I patched pam-auth.c to store the mapped username
in an environment variable PAM_MAP_USER.  Then after accounting, we
restore the mapped username.  This works around the "root shell"
problem, though not the inability to authorize with TACACS+.  Clearly
what I'm doing here is awful, but it illustrates the problem.  I did
try to change pam-auth.c to defer user-mapping until after we open the
accounting session, but this seems to be non-trivial.  Please advise on
the best approach from here.

Here is the debug output for sshd without my hack:

debug1: auth2_challenge: user=tacuser devs=
debug1: kbdint_alloc: devices 'pam'
debug1: auth2_challenge_start: trying authentication method 'pam'
Postponed keyboard-interactive for tacuser from 192.168.0.104 port
37235 ssh2
debug1: sshpam_check_userchanged
debug1: PAM: user mapped from 'tacuser' to 'op'
debug1: PAM: user 'op' now valid
debug1: do_pam_account: called
debug1: sshpam_check_userchanged
debug1: PAM: got username 'root' from thread


-- 
Configure bugmail: http://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.