Russ Allbery wrote:
Juha Jäykkä <[EMAIL PROTECTED]> writes:
In my opinion, the problem is pam_krb5.so, which checks the .k5login
file in pam_sm_authenticate(). Its own documentation says it only checks
.k5login in pam_sm_acct_mgmt(), but this is incorrect. I am not sure
this is a bug, though, and therefore haven't reported it. I just thought
there must be people around who have these three working together and
they must have a solution which is more general than depending on a
single pam module. Comments?
.klogin and .k5login files have always had to be world-readable. Consider
the case with ssh and forwarded credentials. You have to authenticate the
user before you can accept tickets for them, and in order to authenticate
the user you have to be able to check the .k5login file.
I have always argued that there was some room for improvment in this area.
The .k5login should not have to be world readable. Let me explain my argument.
The sshd could accept a forwarded ticket for the sole purpose of using it to get
an AFS token so the sshd could access the .k5login file before the krb5_kuserok
was called (There might be some other dot files that could also be accessed
early.)
Getting this ticket early does not changed the security model, as the checking
of
the .k5login is to allow access to the local machine, not the AFS file system.
The forwarded ticket and token could be discarded if the krb5_kuserok fails.
This would require some changes to do this, and I don't know of any site
that has done this. Its too ingrained in Unix that root has access to the
home directory during login.
Not checking the
.k5login file at the time of authentication is a bug; you may authenticate
a user who shouldn't be allowed to log in, and there are indeed programs
(xlockmore, for instance) that only call pam_authenticate.
The solution is to create a world-, or at least local-network-, readable
directory in every user's home directory, grant l access to the top level
of their home directory, move .k5login to the readable directory, and
symlink it. So far as I know, every site that uses AFS with Kerberos has
had to deal with this; Stanford has been doing this for all users for over
a decade. The l ACLs on the top level of the home directory are rather
unfortunate, but the other ways to work around this are much more complex.
We do this too.
Any distributed file system has the same problem, if files in the home
directory need to be accessed during login. NFSv4 may have to address the
same problems.
,
--
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
