Re: [OpenAFS-devel] Re: MEMORY credential cache interop between Heimdal and MIT?

[u+openafsdev-sr55@chalmers.se]

Hello Todd,

On Fri, Aug 31, 2007 at 03:46:20PM -0400, Todd M. Lewis wrote:
> u+openafsdev-sr55@chalmers.se wrote:
> >I would argue for connecting each network identity to a different
> >local uid, [...] [I]f a person happens to use several network
> >identities, the corresponding processes should have different local uids.
> 
> This would preclude a single process being authenticated to two or more 
> cells at the same time.

[As a general solution a special purpose process may be taught to handle
multiple identities and implement access protection itself. Then the process
should be alloted a uid not available to other / general purpose processes.
But it is probably not the scenario you meant]

In practice, as long as the identities are of similar "protection level"
and there is no need for isolation, they may be used by the same uid.

A different matter is a combination of a plain user running a web browser,
and a cell admin - those probably should be isolated to a higher degree,
depending on their relative vulnerability and importance.

PAGs do not provide reliable isolation and neither allow to choose
the level of isolation. In some cases you need less isolation than
PAGs offer, e.g. when you'd like one "independent" process to refresh
credentials for another one, with other words in some scenarios
you wish you would be able to "join" a PAG.

For uids the tools are in place: su, setuid - but
not any general solution for PAGs.

> It also precludes one tree of cooperating process (think Apache) from 
> acting on behalf of multiple users via their network identities.

Why would it preclude?
setuid() gives a process access to the uid's identity.

> Now, if you substitute your "local uid" above with "local gid", and allow 
> the OS to instantiate and destroy these groups as needed when presented 
> with new network identities, and otherwise follow the normal process group 
> list inheritance rules that have been around for ever, you've solved the 
> two problems above without conflating local uids with network identities. 
> You've also exactly reimplemented PAGs.

Gids look of course like a nice tool for such a task, they even belong to
the "basic *nix design", but there is a catch.

In the design the role of *nix groups is to give extra rights to
otherwise isolated processes (of different uids), not the other way around.

That's why I would not consider gids a suitable identity scope.
Groups can be used for connecting different identities as needed
(allowing access to common objects), but not for isolation.

> >[the actual uid allocation method is irrelevant as long as uids are not 
> >shared
> >by different identities. I'm using static allocation, it can be done
> >dynamically as well]
> 
> Network identities have no business accessing/allocating files in local 
> file systems. Local processes (which have local ids, and are governed by 
> the local system policies) may, and they may be acting on behalf of 

I am talking about _uid_ allocation for use by processes, not about files.
This is of course the host-local matter of policy/implementation,
irrelevant for the network identities, as long as uid's are "supplied"
in some way.

A trivial example would be to give each user multiple login names
and corresponding passwords. This is a no-programming administrative
implementation, not very appealing yet fully functional.

> >Given the above I am fine with Kerberos credentials
> >in a local file protected by the ancient "owner" and mode bits.
> 
> To the extent that Kerberos is being used as the local key master for 
> local ids, fine. However, local files are the wrong place to keep 
> arbitrary network credentials for exactly this reason: it exposes them to 
> access by other uncredentialed local process running under those uids, 
> i.e. outside the equivalent of a PAG.

You are saying that relying on PAGs makes Kerberos credentials
file storage insecure. That's right, and the fault is not of Kerberos,
nor is Kerberos the only one whose security suffers of PAGs.

In a secure *nix-like system there should be no "uncredentialed local process
running under the same uid".

As soon as you taking compromises, that _can_ be fine, but it is inherently
less secure. You are essentially looking for security-related subsystems
like Kerberos to help you taking compromises, to somewhat reduce your losses.

Nothing wrong with compromises, but they should be clearly stated as such.
PAGs however seem to be marketed as both convenient (which is a matter of
taste) and safe (which is incorrect).

Regards,
Rune