Re: [OpenAFS-devel] Re: [PATCH] in-core AFS multiplexor and PAG support

[Jan Harkes <jaharkes@cs.cmu.edu>]

On Tue, May 13, 2003 at 01:25:17PM -0500, Neulinger, Nathan wrote:
> > > 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.
> > 
> > Someone asked for it, but I suspect if allowed at all it may 
> > be best that this
> > ability is governed by its own capability bit and also that 
> > the security
> > interface should be consulted.
> 
> Definately. This is only allowed for root in any case. (Or the cap as
> you describe.)

I don't care if the local user id is 'root', or 'nobody'. As long as
this session hasn't gone through the steps to prove its identity, it
should not be allowed to hijack an existing session.

What should be allowed is for someone to obtain credentials (tokens) and
explicitly pass them to another PAG. Which is probably the reason you
want to be able to join a PAG in the first place.

situation:
  "Hmm, my AFS tokens on my desktop are about to expire"
  
solution 1 (which I believe is bad):
  "log in remotely, join the existing PAG and refresh the tokens"

solution 2:
  "log in remotely, obtain new tokens and explicitly pass them to
  another PAG"

A really bad reason for joining a PAG would be that you want to log in
remotely, but don't want to pay for the cost of proving your identity in
the new session.

Jan