[OpenAFS] home on afs woes

[Douglas E. Engert]

Russ Allbery wrote:

> Juha J=E4ykk=E4 <juolja@utu.fi> writes:
>=20
>=20
>>In my opinion, the problem is pam_krb5.so, which checks the .k5login
>>file in pam_sm_authenticate(). Its own documentation says it only check=
s
>>.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 though=
t
>>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?
>=20
>=20
> .klogin and .k5login files have always had to be world-readable.  Consi=
der
> the case with ssh and forwarded credentials.  You have to authenticate =
the
> user before you can accept tickets for them, and in order to authentica=
te
> the user you have to be able to check the .k5login file.=20

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 argu=
ment.

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_k=
userok
was called (There might be some other dot files that could also be access=
ed early.)
Getting this ticket early does not changed the security model, as the che=
cking of
the .k5login is to allow access to the local machine, not the AFS file sy=
stem.
The forwarded ticket and token could be discarded if the krb5_kuserok fai=
ls.

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 authentic=
ate
> a user who shouldn't be allowed to log in, and there are indeed program=
s
> (xlockmore, for instance) that only call pam_authenticate.
>=20
> The solution is to create a world-, or at least local-network-, readabl=
e
> directory in every user's home directory, grant l access to the top lev=
el
> 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 h=
as
> had to deal with this; Stanford has been doing this for all users for o=
ver
> 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 compl=
ex.

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.

,

>=20

--=20

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444