On Fri, Aug 29, 2003 at 12:29:45AM -0400, Ken Hornstein wrote:
> - Setuid programs threw a whole monkey wrench into the works.  If you
>   index your credentials based on the userid, a setuid program loses
>   any rights that you have.  This is clearly not something the original
>   "Unix security model" people thought about (because, hey, they didn't
>   have network filesystems!).  This is a rather odd case, but one that
>   comes up all of the time when you're using a distributed filesystem
>   like AFS: I want to be "me" over the network, but be "root" locally.
>   I don't see how this fits in the "Unix security model" at all.

Or the other way: even _if_ the setuid programs retains access to the
remote filesystem, how do you separate two instances of the same program
running at the same time by different users? Real world example: To print
a remote file you need a setuid-lpd program to copy this file to the
spool directory. This program is trusted by the local user (hey, he's
working on the machine) but not by the distributed filesystem. Therefore
it needs access _as_ the local user but still the UID lpd for writing.
Think about setuid as a mechanism to set a local filesystem credential
based on the authentication of the _file_. Now AFS credentials and
UID crendentials are orthogonal.

> 
> - People _wanted_ to be able to act as different network identities.  They
>   couldn't easily do this before, because of limitations with the
>   "Unix security model".  This is so common in the AFS world it doesn't
>   even bear thinking about, and there's no security problem with it,
>   because _different process trees have different credentials_.  So they
>   share the same Unix userid; so what?  Even if we share the same Unix
>   userid, we're not in the same PAG, and there's nothing I can do
>   to gain access to those credentials (short of becoming root, but we're
>   discounting that right now).  So where, exactly, is the problem?
>   We've _moved beyond_ the limitations in Unix security model.

This could be done using different local uids, but that wouldn't solve the
problem of setuid.

> 
> - Those pesky Kerberos credentials have an expiration time associated to
>   them.  It's not uncommon to have different expiration times associated
>   with different sets of credentials.  I routinely get much shorter-lived
>   tickets when I log in from home.  But if I were to send those tickets
>   to a machine I was running a job on at work, I'd wipe out my long-lived
>   tickets at work.  This causes no end of confusion.  Another example is
>   the supercomputer systems we have here; the batch systems in this
>   case automatically renew a user's ticket for them so they can read/write
>   to their home directory in AFS, but we don't want those batch credentials
>   interfering with a user's login session (and for security reasons, we'd
>   rather _not_ have a remote user get an interactive login with a long-lived
>   ticket).
> 
> To combat these problems, the designers of AFS implemented the
> concept of credentials that were tied to a "login session", in the
> form of the PAG.  Again, no one is in love with the particular
> implementation, but it's served us well these many years.  To
> everyone who has real-world experience with AFS, PAGs are indispensible.

The PAG is just on implementation, it could be "easily" replaced by a true
credential using a tag mechanism or similiar. The whole point of PAG is not
to provide security against ptracing, but against right escalation for the
_normal_ operation. So that the CGI script mentioned in this thread does not
provide access to some AFS ressource simply because the owner is logged in
and that is similiar in terms of functionality to chroot which helps security
by risen the bar for useful breakins.

Joerg

> 
> And as a final note ... Greg, I'm not going to read your reply, so you
> need not bother (but I know you will, because you just can't resist
> anyone else getting the last word in).
> 
> --Ken
> 
>