openssh bugs - May 2007 - [Bug 1215] sshd requires entry from getpwnam for PAM accounts

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 devsdebug1: 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.

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





--- Comment #8 from Jesse Zbikowski <embeddedlinuxguy at gmail.com> 
2007-05-19 11:24:06 ---
Created an attachment (id=1292)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=1292)
vs pam_tacplus v1.2.9 http://ipsec.pl/pubs/pam_tacplus.php


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

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





--- Comment #9 from Jesse Zbikowski <embeddedlinuxguy at gmail.com> 
2007-05-19 11:26:35 ---
Created an attachment (id=1293)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=1293)
Remember the mapped username and restore it

This is applied on top of the patch 1171 above.


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

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





--- Comment #10 from James R. Leu <jleu at inoc.com>  2007-05-30 02:38:44
---
Created an attachment (id=1298)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=1298)
PermitPAMUserChange: runtime option that checks and handles PAM
changing the username

Works for PasswordAuthentication, but not
ChallengeResponseAuthentication


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

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


James R. Leu <jleu at inoc.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jleu at inoc.com




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

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


Jesse Zbikowski <embeddedlinuxguy at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
Attachment #1293 is|0                           |1
           obsolete|                            |




--- Comment #11 from Jesse Zbikowski <embeddedlinuxguy at gmail.com> 
2007-06-02 11:23:30 ---
Created an attachment (id=1300)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=1300)
Authorize with PAM virtual username, not local username

Thanks James!  This indeed gets around the "mapping-to-root" problem
without my hack in Comment 9.

I still believe the authorization request needs send the virtual (PAM)
username, NOT the local username.  Otherwise I see no way to give
different privileges to different PAM users, or to allow for a TACACS+
server which manages multiple independent systems.

My attached patch temporarily restores the virtual username during
authorization.  The idea is that the PAM module should map to
e.g. "nobody" during authentication, then map to an appropriate user
(perhaps based on TACACS+ AV pairs) during authorization: "op",
"admin", "guest", etc.  This patch is vs. 4.3p2 with
Darren's and
James' patches applied.  It saves the usernames during
sshpam_handle_user_change() and swaps them during do_pam_account().

Please let me know if I am on the right track with this.  I think a
much better design would be not to do any username mapping or
valid-user checking until *after* the accounting, but I haven't been
able to make that work yet.


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