> > 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.
You understand perfect. >From "man chown" I found possibility to set behaviour of chown by "set rstchown=0" into file /etc/system. This setup switches the restriction "_POSIX_CHOWN_RESTRICTED" in the OS to "false". (It is someting like a bit a MAC - Mandatory Access Contrlol). With this setup it is everything right. From the point of view of security I think this setup is not good. I would recommend not to change ownership of group in the function call of chown() in pam_krb5_auth.c. It is possible to use for example: chown(&cache_name[5], pw->pw_uid, -1 ). I have tried it. It works well. There is only one potential disadvantage of this solution: a user cannot change group of "credential" file so she/he cannot share it with somebody. But I think , this using is nonsense. (May be). > Steve Langasek > postmodern programmer Cheers Josef Kelbler VUMS Computers ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
