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

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: [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: 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

[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

[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

[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]

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

[David Howells]

Linus Torvalds wrote:
> On Tue, 13 May 2003, David Howells wrote:
> > 
> >  (1) PAG (Process Authentication Group) support. A PAG is ID'd by a unique
> >      number, and is represented in memory as a structure that has a ring of
> >      associated authentication tokens.
> > 
> >      Each process can either be part of a PAG, or it can PAG-less - in
> >      which case it has no authentication tokens.
> > 
> >      Two new syscalls are added: setpag and getpag.
> 
> I think the code looks pretty horrible,

Any particular bits?

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

Maybe... There are arguments either way, but if the token ring is kept in
struct user, a task can't detach from it and pass a token-less set of keys
onto another process it wants to run.

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.

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

David

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

[Linus Torvalds]

On Tue, 13 May 2003, David Howells wrote:
> > 
> > I think the code looks pretty horrible,
> 
> Any particular bits?

I htink the table-driven approach is just generally pretty nasty, even if
it's clever and concise. I personally prefer a table of function pointers 
over a table of constraints.

Right now you have one table of constraints, and then later on when you
actually implement the code that _does_ anything, you'll end up having
another table (or switch statment) per filesystem of actual actions.  And
neither with any kind of compile-time type checking, since the actual
interfaces to pass stuff around are just extended ioctls.

The Linux way of doing things is to have a per-object "operations
structure", which is not an anonymous table (array of identical entries),
but a list of unique entries (a structure of strongly typed function
pointers). And then you never de-multiplex (which inherently loses type
information), or you at least do it only _once_ and make sure that you
stronly type things at that point so that any downstream stuff is typed.

> Maybe... There are arguments either way, but if the token ring is kept in
> struct user, a task can't detach from it and pass a token-less set of keys
> onto another process it wants to run.

Oh, but it can. The pointer should be kept at two places: the "struct 
task_struct" contains the initial pre-process value, and at file open time 
that pointer should get copied (and the user count incremented) and put 
into the "struct file". 

So you can pass the set of keys the way UNIX _always_ passes rights - 
through the file descriptor. 

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

The advantage of associating the PAG with the real uid rather than make it
per-process is that it's a lot easier to administer that way, I think. You
don't need to log out or anything like that to have changes take effect
for your session, and it is very natural to say "this user now gets key
X". Which is what I think you really want when you do something like enter
a key to an encrypted filesystem, for example.

Put another way: you'd usually add the PAG's at filesystem _mount_ time,
no? And at that point you'd usually want to add it "retroactively" to the 
session processes that caused the mount to happen, no? Not just to the 
children of the mount.

			Linus

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

[Jan Harkes]

On Tue, May 13, 2003 at 09:47:59AM -0700, Linus Torvalds wrote:
> > Maybe... There are arguments either way, but if the token ring is kept in
> > struct user, a task can't detach from it and pass a token-less set of keys
> > onto another process it wants to run.
> 
> Oh, but it can. The pointer should be kept at two places: the "struct 
> task_struct" contains the initial pre-process value, and at file open time 
> that pointer should get copied (and the user count incremented) and put 
> into the "struct file". 
> 
> So you can pass the set of keys the way UNIX _always_ passes rights - 
> through the file descriptor. 

Right, if some process/user opens a file and then passes the descriptor
to another process/user which closes it. The close should operate under
the same permissions as the original opener.

Simple example when this happens is when a setuid application is started
and the stdout/stderr is redirected to a file. 'ping foo >out 2>&1'. The
shell opens the file under my uid, but the setuid application closes it
under the new uid.

> The advantage of associating the PAG with the real uid rather than make it
> per-process is that it's a lot easier to administer that way, I think. You
> don't need to log out or anything like that to have changes take effect
> for your session, and it is very natural to say "this user now gets key
> X". Which is what I think you really want when you do something like enter
> a key to an encrypted filesystem, for example.

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.

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. If our identity
already was proven beyond reasonable doubt, we clearly already have our
'token' and the additional cost to associate this with the new PAG is
zero.

Jan

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

[Pavel Machek]

Hi!

> > The advantage of associating the PAG with the real uid rather than make it
> > per-process is that it's a lot easier to administer that way, I think. You
> > don't need to log out or anything like that to have changes take effect
> > for your session, and it is very natural to say "this user now gets key
> > X". Which is what I think you really want when you do something like enter
> > a key to an encrypted filesystem, for example.
> 
> 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

? 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
-- 
				Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...

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

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

[Linus Torvalds]

On Tue, 13 May 2003, David Howells wrote:
> 
>  (1) PAG (Process Authentication Group) support. A PAG is ID'd by a unique
>      number, and is represented in memory as a structure that has a ring of
>      associated authentication tokens.
> 
>      Each process can either be part of a PAG, or it can PAG-less - in which
>      case it has no authentication tokens.
> 
>      Two new syscalls are added: setpag and getpag.

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

		Linus

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

[Alan Cox]

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 ?

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