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

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

[Douglas E. Engert]

David Howells wrote:
> 
> I'm not sure that the ability to arbitrarily join a PAG should be permitted,
> but it was requested.

This was a very handy feature which could be used with DCE/DFS. It is especially 
nice if the cost of obtaining credentials is high, vs the amount of 
processing being done, for example if the user is running a script, and doing 
multiple kerberos rsh commands to a host, if the rshd could join a PAG,
it would not need to received delegated credentials for each connection,
as it could use the credentials that where delegated earlier. 

It could can also be used as a way to refresh credentials. 



> 
> David
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel

-- 

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

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

[Neulinger, Nathan]

> > > Also, using a separate PAG structure means that you can 
> lend your keys to
> > > an SUID program and conversely it means a SUID program 
> can't so easily
> > > gain access to keys it didn't inherit from its caller.
> > 
> > "task->user" always follows uid ("real uid"), and as such 
> you can always
> > switch back and forth by just changing uid.
> 
> So anyone who has the ability to get root on a box can 
> immediately use other
> peoples keys with su... OTOH, the ability to get root would 
> normally permit
> someone sufficiently motivated to get this anyway.

This isn't any good since it implies that a given uid can only have a
single set of tokens. Users can freely authenticate to afs and get
tokens for other afs ids at any time. As long as they are in different
pags, they can freely coexist. Now, if you're talking about pag-less
only, then the above is reasonable and expected. 

-- Nathan

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

[Neulinger, Nathan]

Yes, handles it fine and used quite frequently, just have to set a new
pag (done automatically if it's really a new login and not just a new
xterm, or can start a command with 'pagsh' command to start it in a new
pag).

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216


> -----Original Message-----
> From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk] 
> Sent: Tuesday, May 13, 2003 10:44 AM
> To: Linus Torvalds
> Cc: David Howells; Linux Kernel Mailing List; 
> linux-fsdevel@vger.kernel.org; openafs-devel@openafs.org
> Subject: [OpenAFS-devel] Re: [PATCH] in-core AFS multiplexor 
> and PAG support
> 
> 
> On Maw, 2003-05-13 at 16:52, Linus Torvalds wrote:
> > I think the code looks pretty horrible, but I think we'll 
> need something
> > like this to keep track of keys. However, I'm not sure we 
> should make this
> > a new structure - I think we should make the current 
> "tsk->user" thing
> > _be_ the "PAG". 
> 
> With something like SELinux a PAG may belong to a role not to a user
> even though other limits like processes probably belong to 
> the user as a
> whole. 
> 
> How does AFS currently handle this, can two logins of the 
> same user have
> seperate PAGs ?
> 
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
> 

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

[Neulinger, Nathan]

> > 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.)

-- Nathan

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

[Douglas E. Engert]

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
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel

-- 

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

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

[Neulinger, Nathan]

> > >  (2) gettok(const char *fs, const char *key, size_t size, 
> void *buffer)
> > > 
> > >      Get a copy of an authentication token.
> > 
> > Not sure what the use of this is for userspace. I can see how your
> > kernel module would use it.
> 
> OpenAFS has it, but I'm not sure what uses it.

Any afs user space tool that needs to talk to file servers - such as all
the administration utilities - vos, bos, pts, etc. Eventually they could
use kerberos cred caches directly, but not until they are converted to
kerberos. Right now, they fetch the current auth data from the kernel
and use it to authenticate to whatever non-kernel service they are
talking to.

-- Nathan

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

[Douglas E. Engert]

"Neulinger, Nathan" wrote:
> 
> > > >  (2) gettok(const char *fs, const char *key, size_t size,
> > void *buffer)
> > > >
> > > >      Get a copy of an authentication token.
> > >
> > > Not sure what the use of this is for userspace. I can see how your
> > > kernel module would use it.
> >
> > OpenAFS has it, but I'm not sure what uses it.
> 
> Any afs user space tool that needs to talk to file servers - such as all
> the administration utilities - vos, bos, pts, etc. Eventually they could
> use kerberos cred caches directly, but not until they are converted to
> kerberos. Right now, they fetch the current auth data from the kernel
> and use it to authenticate to whatever non-kernel service they are
> talking to.

If the PAG was implemented well, then even the Kerberos credentials
could be contained within the PAG, or accessible only by other processes
in the same PAG. 

One way to think of the PAG is a way of getting around the limited
capabilities of UNIX to have only a UID which is only locally unique. 
The PAG identifies the user globally, and stores credentials to use
to prove it to other systems of file systems. 

Linus said in two previous note:

> I think we should make the current "tsk->user" thing _be_ the "PAG".  

and:
> A "user" is by definition what the unix filesystem considers to be the
> "atom of security".

This may well be true, but current UNIX file systems continue to use the
simple UID and GID for access. Maybe there something that can be done
here as well. 
    


> 
> -- Nathan
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel

-- 

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

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

[Derrick J Brashear]

On Tue, 13 May 2003, David Howells wrote:

> > >  (2) gettok(const char *fs, const char *key, size_t size, void *buffer)
> > >
> > >      Get a copy of an authentication token.
> >
> > Not sure what the use of this is for userspace. I can see how your
> > kernel module would use it.
>
> OpenAFS has it, but I'm not sure what uses it.

The simplest case: "List my tokens" (if you want any sort of detail about
them). A program "tokens" does just this, lists all tokens you have, then
enumerates with GetToken to get each and print some information about them
(are they expired, for instance).

There are also some debugging tools which can pull tokens back out and
decode them using the server key, and some old primitive authentication
passing stuff which is probably now all obsolete did also.

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

[Douglas E. Engert]

Jan Harkes wrote:
> 
> 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.

No, but the sshd, or rshd can look at the credentials and determine if you
are establishing a new connection, and then let this process join the
previous PAG, i.e. share the credentials if appropriate.

> 
> 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).

True but I am saying that you don't want to have to call aklog to get new
AFS tokens for each connection, but would rather use the existing AFS token
or credentials already present from the previous session. 

When we did this back in 1997 we did this with the DFS PAG as the overhead
of getting a DCE context could be quite large, requiring many tickets
Here are some comments forom the k5dcecon.c program:


/*
 * k5dcecon - Program to convert a K5 TGT to a DCE context,
 * for use with DFS and its PAG.
 * 
 * The program is designed to be called as a sub process, 
 * and return via stdout the name of the cache which implies 
 * the PAG which should be used. This program itself does not 
 * use the cache or PAG itself, so the PAG in the kernel for 
 * this program may not be set. 
 * 
 * The calling program can then use the name of the cache
 * to set the KRB5CCNAME and PAG for its self and its children. 
 *
 * If no ticket was passed, an attemplt to join an existing
 * PAG will be made. 
 * 
 * If a forwarded K5 TGT is passed in, either a new DCE 
 * context will be created, or an existing one will be updated.
 * If the same ticket was already used to create an existing
 * context, it will be joined instead. 
 * 
 * Parts of this program are based on k5dceauth,c which was
 * given to me by HP and by the k5dcelogin.c which I developed. 
 * A slightly different version of k5dcelogin.c, was added to
 * DCE 1.2.2
 * 
 * D. E. Engert 6/17/97 ANL
 */


> 
> > 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.

We maybe saying the same thing. I would say the PAG is where this information is
stored. One may define the PAG as a kernel only concept which is destroyed
when the last process ends, where I am also saying it includes cached credentials
which may persist longer.


> 
> 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.

It is possible that the credential can be kept around for some time, 
as was the case with the k5dcecon, so previous credentials could be reused. 
In the case of the DCE, there where three files, one of which was the kerberos
cache. The filenames has the PAG number as part of the file name. 

The DFS cache manager process would assist the kernel in getting additional
tickets and use these files. 

This was not possible with AFS, since the AFS token was only in the kernel,
and would be destroyed when the last process in the PAG finished. 
(To bad, as we have seen problems if a user saves a big file, then logs off,
and the token is destroyed before the cache manager writes the file ac
to the server.) 



> 
> Jan

-- 

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

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

[Russ Allbery]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> How does AFS currently handle this, can two logins of the same user have
> seperate PAGs ?

Yes.  In fact, that's the default situation and it requires some work to
get two logins of the same user into the same PAG.

AFS currently handles PAGs by creating "random" high-numbered groups and
putting the user into them, and then associating the token with that group
in the kernel.

One could debate whether it's best to put a user into the same PAG as
their other logins by default, but it's imperative that a user be able to
create a separate PAG when they wish to (so, for example, they can acquire
separate credentials in that new PAG without affecting the credentials and
PAG for their other running processes).

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

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

[Booker Bense]

On Tue, 13 May 2003, Derrick J Brashear wrote:

> On Tue, 13 May 2003, David Howells wrote:
>
> > > >  (2) gettok(const char *fs, const char *key, size_t size, void *buffer)
> > > >
> > > >      Get a copy of an authentication token.
> > >
> > > Not sure what the use of this is for userspace. I can see how your
> > > kernel module would use it.
> >
> > OpenAFS has it, but I'm not sure what uses it.
>
> The simplest case: "List my tokens" (if you want any sort of detail about
> them). A program "tokens" does just this, lists all tokens you have, then
> enumerates with GetToken to get each and print some information about them
> (are they expired, for instance).
>
> There are also some debugging tools which can pull tokens back out and
> decode them using the server key, and some old primitive authentication
> passing stuff which is probably now all obsolete did also.
>

- It may be obsolete, but there are a lot of people using AFS
token passing in ssh.

_ Booker C. Bense

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

[Nathan Neulinger]

> ? If he has same uid as you *and* you
> have >=1 process running, what prevents
> him from gdb attach <that process>,
> and force it to do whatever he needs
> by forcing syscall?
> 				Pavel

That's a good point, and perhaps it should be an option to not allow
ptrace or other potentially dangerous operations between processes in
different pags. But leave that optional, as it might still be useful -
for example, logging in and diagnosing a daemon running in a separate
pag.

It's not clear if this would be best as a per-pag flag or a global one
though. 

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216