[OpenAFS] home on afs woes
Wed, 04 Jan 2006 19:26:07 -0500
On Wednesday, January 04, 2006 05:31:15 PM -0600 "Douglas E. Engert"
> Exactly where in the PAM stack do you want
>> to obtain (and, if need be, discard) this extra token? pam_open_session()
> I am not sure. It has to be after the GSSAPI or pam_authenticate has a TGT
> (which could have been via keyboard interactive or at the console) but
> the krb5_kuserok is called.
You don't want to use the forwarded ticket for this, or one that was
obtained by pam_authenticate. Those are tickets for which the client
(read: attacker) knows the session key, and thus can spoof the server and
give you back a false .klogin file.
Access to the klogin file must in some way be protected by a key which the
potential attacker does not and cannot know.
In AFS, the intended mechanism for this is a feature of rxgk that will
allow the cache manager to combine users' credentials with its own in such
a way that traffic is protected by a key which is tied to the user's
identity but is known only to the cache manager. One side effect of the
technique used to achieve this is that the cache manager will be able to
protect _all_ communication with the fileserver, even when done on behalf
of unauthenticated users.
Another is that, if we choose to implement the feature, the fileserver will
be able to make access control decisions based on the client host's
identity as well as that of the user. The effect would be similar to the
behavior of IP-address ACL's today, except that it would behave reasonably
consistently and would actually be secure.
With these features, it is possible to access and trust a .klogin file
without requiring the user's credentials, if users and/or administrators
are willing to set permissive enough ACL's. Personally, I fall into that
camp -- I don't mind if .k5login contents are world-readable.
Another feature I'd like to see added to the ptserver is the ability to map
a large set of Kerberos principals (either enumerated or based on a
pattern) to a single PTS entry. I've been thinking about this for a long
time, though, and haven't yet come up with a way to represent it that
doesn't make the lookups grossly inefficient (something we cannot afford;
this is an operation the fileserver uses a lot, and its performance is a
If we can ever find a way to provide that capability, it should allow the
camp that wants to keep klogin files secret a way to do so without creating
a pts entry for every host.
-- Jeffrey T. Hutzelman (N3NHS) <firstname.lastname@example.org>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA