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

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

[David Howells]

> On Tue, May 13, 2003 at 06:42:49PM +0100, David Howells wrote:
> > I have a further suggestion for some new system calls specifically for
> > managing tokens. I'd like to add the following:
> > 
> >  (1) settok(const char *fs, const char *key, size_t size, const void *data)
> > 
> >      Present data to the named filesystem as being the authentication
> >      token for the specified key (eg: an AFS cell). If accepted, this
> >      token should be stored in the PAG to which the calling process
> >      belongs.
> 
> Tokens are very filesystem specific, with Coda the kernel really doesn't
> know in which 'realm' any object is located. So it will always just pass
> the PAG to the cache manager which will associate the right token to
> access the file.

OTOH, since settok wouldn't modify the PAG ring directly, but would rather
jump through a vector in the file_system_type object, it could deside to
confer with userspace and possibly not add a token at all.

Of course then the other calls would also have to vector through the
file_system_type object rather than affecting the PAG directly, but I'm happy
to do that.

> A minimal kernel implementation really only has a single newpag()
> systemcall and internal 'getpag()' that can be used by filesystems. All
> the token handling can be done by a (possibly filesystem specific)
> userspace daemon that is given a (pag,realm/key) tuple and returns a
> token.
>
> But ofcourse Coda is a 99% userspace implementation, so I'm already
> assuming that there are one or more userspace daemons.

This would just be a "standardised" way of communicating authentication info
to a filesystem. What the filesystem then did with it would be up to that
filesystem. Storing a token in a PAG or attached to a struct file would then
just be one option.
 
> >  (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.

> btw. is the 'size_t size' the size of the key, or the size of the buffer?

Actually the buffer size. I was assuming the key would be a NUL terminated
string, but it's probably best not to assume that, and I should add an extra
argument for the key size.

Filesystem name can remain a NUL terminated string as I'd have to search the
file_system_type structures.

> >  (4) cleartoks(const char *fs)
> 
> Isn't this simply deltok(fs, NULL)?

Probably.

David

Re: [OpenAFS-devel] 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: [OpenAFS-devel] 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: [OpenAFS-devel] Re: [PATCH] in-core AFS multiplexor and PAG support

[Pavel Machek]

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

Well, at that point you are getting quite far away from unix....
And this decision is pretty fundamental.

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

-- 
Horseback riding is like software...
...vgf orggre jura vgf serr.

Re: [OpenAFS-devel] 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

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

[Derek Atkins]

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.  Indeed, individual logins usually DO have separate PAGs (as the
login program runs setpag() to create a new pag).  Moreover, there is
a program called "pagsh" which allows a user to create a shell in a
new PAG -- allowing multiple PAGs even in one login session for a
single "user".

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available

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

[Jan Harkes]

On Tue, May 13, 2003 at 05:14:21PM -0500, Douglas E. Engert wrote:
> Jan Harkes wrote:
> > PAG != tokens.
> > 
> > PAG is a simple unique session identifier. AFS, Coda and DCE/DFS happen
> > associate credentials with a session.
> > 
> > But there is no reason why multiple PAG's can't map to the same set of
> > credentials. 
> 
> True. But traditionally with AFS or DCE at lest they have not. Each had its
> own set of credentials, and the PAG was only defined to allow the credentials
> to be shared. 

Actually, the PAG was defined to temporarily disable membership in one
or more groups. Every process would normally run in PAG 0, and the
credentials were shared based on the uid. When a user wanted to
'restrict' rights he would initiate a new PAG which provided a more
limited environment.

This is my interpretation of the AFS paper that documents the original
security policies of AFS as it was initially deployed on November 11,
1986.

    Integrating Security in a Large Distributed System  (# 12)
    Satyanarayanan, M.
    ACM Transactions on Computer Systems
    Aug. 1989, Vol. 7, No. 3, pp. 247-280 

http://www-2.cs.cmu.edu/afs/cs/project/coda-www/ResearchWebPages/docdir/sec89.pdf

    The process authentication group is described on pages 22-23 in the
    pdf, 268-269 in the original ACM publication.

Jan

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

[Douglas E. Engert]

Jan Harkes wrote:
> 
> On Tue, May 13, 2003 at 04:26:46PM -0500, Douglas E. Engert wrote:
> > Jan Harkes wrote:
> > > 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.
> 
> PAG != tokens.
> 
> PAG is a simple unique session identifier. AFS, Coda and DCE/DFS happen
> associate credentials with a session.
> 
> But there is no reason why multiple PAG's can't map to the same set of
> credentials. 

True. But traditionally with AFS or DCE at lest they have not. Each had its
own set of credentials, and the PAG was only defined to allow the credentials
to be shared. 
 
> You still don't 'join' a PAG, it is up to some filesystem
> specific policy how PAGs are mapped to credentials.

Not sure what you mean here, isn't it the other way around,
the file system uses the credentials, which happen to belong to a PAG.
In the past the credentials only belonged to one PAG, so "joining" was 
a way to use the same credentials. 

>
> > > 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.
> 
> I think we are saying the same thing. But abstract at a different level.

Yes I agree. 

> 
> Yes, a new session could use the same credentials as an existing
> session. But it is still a new session.
> 
> > > 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.
> 
> How long should the credentials be kept around? The kernel doesn't know
> the difference between a Kerberos ticket, an AFS or Coda token, or a DCE
> security context. In my case only the Coda servers can reliably tell us
> whether the token is valid at all.

How long? Not sure.

It comes down to what is a "session"  A user may say "I will be 
contacting this system for the next four hour, so hold on to any credentials
I send you now, even though I don't have an open connection or an active process."
A user could do something similiar with a sshd and port forwarding, or a VPN,
to keep a session running but they should not have to resort to these
methods if possible. 


> 
> > 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.)
> 
> That seems to be more an implementation issue, the token (or actually
> PAG) has to be associated with the open file handle. Logging out doesn't
> matter, except if the user explicitly flushes all tokens associated with
> his PAG.

Yes its an implementation issue. 

> 
> Jan

-- 

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

Re: [OpenAFS-devel] 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: [OpenAFS-devel] Re: [PATCH] in-core AFS multiplexor and PAG support

[Jan Harkes]

On Tue, May 13, 2003 at 04:26:46PM -0500, Douglas E. Engert wrote:
> Jan Harkes wrote:
> > 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.

PAG != tokens.

PAG is a simple unique session identifier. AFS, Coda and DCE/DFS happen
associate credentials with a session.

But there is no reason why multiple PAG's can't map to the same set of
credentials. You still don't 'join' a PAG, it is up to some filesystem
specific policy how PAGs are mapped to credentials.

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

I think we are saying the same thing. But abstract at a different level.

Yes, a new session could use the same credentials as an existing
session. But it is still a new session.

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

How long should the credentials be kept around? The kernel doesn't know
the difference between a Kerberos ticket, an AFS or Coda token, or a DCE
security context. In my case only the Coda servers can reliably tell us
whether the token is valid at all.

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

That seems to be more an implementation issue, the token (or actually
PAG) has to be associated with the open file handle. Logging out doesn't
matter, except if the user explicitly flushes all tokens associated with
his PAG.

Jan

Re: [OpenAFS-devel] 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: [OpenAFS-devel] Re: [PATCH] in-core AFS multiplexor and PAG support

[Jan Harkes]

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

Re: [OpenAFS-devel] 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: [OpenAFS-devel] 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: [OpenAFS-devel] 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: [OpenAFS-devel] Re: [PATCH] in-core AFS multiplexor and PAG support

[Jan Harkes]

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

RE: [OpenAFS-devel] 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: [OpenAFS-devel] 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: [OpenAFS-devel] 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: [OpenAFS-devel] 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