Re: aname_to_locaname vs gssapi svc/host.domain.org@REALM

"<[email protected]> " <[email protected]> writes:

> Yes, it is an example of reserving the semantics of a part of namespace
> for a certain service (host-local authorization aka login).

> Russ' module is good (the mapping principals->semantics is configurable)
> but that page does not ever warn "if you made the choice like
> 'alt_auth_map=%s/root' then DO NOT use principals of that form */root
> for anything else UNLESS you know that the set of identities to be
> allowed "THIS" and "THAT" will ALWAYS coincide'

> The things above about THIS, THAT and ALWAYS is crucial for security but
> hardly anyone thinks about it while blindly following the proposed
> example.

I think this warning is somewhat overstated.  It's sufficient if one's
naming policy is such that user/root is always considered stronger (more
secure) than user; in other words, if the */root instance should have a
superset of the privileges of the regular instance.

It so happens that this is often the case for the common uses of root
instances.  I think Stanford is a reasonably typical site in how we use
such instances, and if someone has access to one of our root instances,
that means they can get root access to a system on which we have a
regular account, forward tickets, and so forth, and therefore can
compromise the regular instance relatively easily.

Also, note that if you set only_alt_auth in addition to alt_auth_map the
principals at that point can have disjoint privileges.

-- 
Russ Allbery ([email protected])             <http://www.eyrie.org/~eagle/>