Bad chown() in pam_krb5 module

[Steve Langasek]

On Fri, Nov 22, 2002 at 05:38:41PM +0100, Josef Kelbler wrote:
> Hi guys from "pam_krb5" team at "sourceforge.net" or  whoever !

Aside: there is a mailing list for discussion of this PAM module at
<pam-krb5 at lists.netexpress.net>.

> I built and tested "pam_krb5" module on Solaris 8 together with installed
> MIT Kerberos 5-1.2.6.
> PAM telnetd worked well but PAM sshd (OpenSSH 3.4p1) not.
> In /var/adm/messages log  I found:
> sunblade sshd[26586]: [ID 800047 auth.crit] fatal:
>   PAM setcred failed[3]: Error in underlying service module

> So I decided to debug and obtained:
> sunblade sshd[1949]: [ID 843472 auth.debug] pam_krb5:
>   pam_sm_setcred(sshd user1005): chown(): Not owner

Yep.

> It seems to me:
> pam_krb5 successfuly obtains for the user1005 tickets (TGT and
> host/sunblade...>). I know it from KDC log.
> It creates the CCache. Then it changes ownership to euid of target user1005.
> And then it try to do "chown" of CCache file to permitions applicable for
> end user.
> This chown() gives this error. It cannot to change.
> I don't know why.

The handling of uids by the various PAM facilities is underspecified in
the existing PAM spec.  Since one of the tasks of pam_krb5 is to create
the initial ccache for the user logging in (since pam_krb5 is intended for
initial logins to a Kerberos realm), it needs to be able to both create a
file as the user at login time, and remove the file at the time of logout.
There are only two sets of functions appropriate for this in PAM: the
session functions and the setcred() function (called with different
arguments).  Our reading of the PAM specs is that Kerberos tickets, being
a form of "credential", should be handled by the setcred() ("set
credential") function, not by the session functions.  However, recent
versions of sshd have had inconsistent handling of root permissions where
PAM is concerned.

> I included in source program "pam_krb5_auth.c" before the call of chown()
> 4 tests for
> UID, GID, EUID and EGID and printed them to syslog.
> I tested 3 cases under PAM:
> 1) telnetd (it was OK)
> 2) sshd with option "UsePrivilegeSeparation=no" (It was bad)
> 3) sshd with option "UsePrivilegeSeparation=yes", where sshd used account
> "sshd" (it was OK)

> 2) sshd (no separation),  UID=0, GID=1, EUID=1005, EGID=1
> 3) sshd (with separation), UID=1005, GID=10, EUID=1005, EGID=10

> UID=0 ... It is user root.
> GID=10 ... It is group staff.
> UID=1005 ... It is connecting user.
> GID=1 ... It is group other.

> pam_krb5 creates CCache in /etc/krb5cc_1005 (here). It creates it with EUID.
> In the bad case (2 - sshd without separation) the created file
> /etc/krb5cc_1005 had:
> -rw --- ---   user1005   other(group)

If I understand all of this, it appears that the file is created with the
correct permissions initially; sshd is running as the user; but when
privilege separation turned off, the primary effective GID is 1 instead of
10, and 10 is also not in the supplementary groups list of the process
(see getgroups(2)), so the sshd process is not allowed to change the
file's GID from 1 to 10.

> Do you know answer? It is a fault or what.

This sounds like a bug in OpenSSH, which should be initializing the group
list at the same time that it's calling seteuid().

HTH,
-- 
Steve Langasek
postmodern programmer