Jan Harkes wrote:
>
> The local user id is not a 'trusted' identity for a distributed filesystem.
> Any user still have to prove his identity by obtaining tokens.
>
> If someone obtains my user id on in any way (i.e. weak password/
> bufferoverflow/ root exploit), he should not be allowed to use or access
> my tokens as he hasn't proven his identity. In this case he would either
> still be in his original process authentication group, or a new and
> empty PAG. But definitely not in any of my authentication groups.
>
> Which is also why joining a PAG should never be allowed.
Joining a PAG can be allowed, if the connecting process can prove its
identify to the owner of the PAG. This does not imply that using a weak password
gets you access to a PAG that was instituted via some more secure
method.
In the example I used of Kerberized rsh, the rshd running as root, would
only allow a second connection to join the PAG if the second connection was
also authenticated via the same Kerberos user.
>
> Any arguments about 'it avoids the cost of obtaining credentials' are
> stupid because that cost is exactly what it takes to prove that a new
> session is in fact associated with a specific user.
No that is not true. In a Kerberos example, the client needs a service
ticket, to prove its identity to the server, and then it delegates a
forwardable TGT to the server so the server can act on behalf of the user.
The server can then use the forwarded TGT to obtain additional
tickets for AFS for example.
Since each invocation of the server would be placed into its own PAG,
(sort of by definition of a PAG) then each invocation of the server would
have to get a new AFS token.
What I am looking for is that the server can verify the identity, of the
client, then use previously forwarded credentials, such as a TGT or AFS token,
so it does not have to get a new token., i.e. it joins the existing PAG.
Note that the ability to join a PAG requires root access to place the new
process in the existing PAG. A user process can not on its own join a PAG.
> If our identity already was proven beyond reasonable doubt,
Maybe to the local system, but not to a third party.
> we clearly already have our
> 'token' and the additional cost to associate this with the new PAG is
> zero.
I would say the "token" is in the PAG, so the new process would join
the existing PAG. We may be saying the same thing, just describing
how PAGs are used. Traditionally a PAG was created for a process and
inherited by its children. I am saying root processes could add additional
processes to the existing PAG, such as in the rshd example.
>
> Jan
>
> _______________________________________________
> OpenAFS-devel mailing list
> [email protected]
> https://lists.openafs.org/mailman/listinfo/openafs-devel
--
Douglas E. Engert <[email protected]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
On Tue, May 13, 2003 at 01:51:00PM -0500, Douglas E. Engert wrote:
> Jan Harkes wrote:
> > The local user id is not a 'trusted' identity for a distributed filesystem.
> > Any user still have to prove his identity by obtaining tokens.
...
> > Which is also why joining a PAG should never be allowed.
>
> Joining a PAG can be allowed, if the connecting process can prove its
> identify to the owner of the PAG. This does not imply that using a
> weak password gets you access to a PAG that was instituted via some
> more secure method.
> In the example I used of Kerberized rsh, the rshd running as root, would
> only allow a second connection to join the PAG if the second connection was
> also authenticated via the same Kerberos user.
The kernel doesn't know whether you got into the system using a
kerberized rsh, ssh, telnet, or by a buffer-overflow.
The 'authenticated' user in fact already got his kerberos tokens on the
system he is logging in from. The kerberized rshd simply adds the token
used as authentication to the new session, if it is a TGT it can be used
to obtain AFS and other credentials either from within the daemon or
through commands in a .login script (using afslog or aklog or something).
> Since each invocation of the server would be placed into its own PAG,
> (sort of by definition of a PAG) then each invocation of the server would
> have to get a new AFS token.
Which actually seems logical to me.
> What I am looking for is that the server can verify the identity, of the
> client, then use previously forwarded credentials, such as a TGT or AFS token,
> so it does not have to get a new token., i.e. it joins the existing PAG.
You could have the kerberized rshd remember the tokens it obtained
during a previous login or were forwarded by the client and associate
them with the new PAG. No need to join an existing PAG.
What you propose has completely different behaviour depending on whether
the user happens to have a secondary permanent connection to the target
host or not. If there is no permanent session there will be no PAG to
join and each rsh invocation will have to reauthenticate anyways.
Jan