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

Hello Russ,

On Thu, Oct 13, 2011 at 08:28:31PM -0700, Russ Allbery wrote:
> "<[email protected]> " <[email protected]> writes:
> > 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

> > 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 is of course totally reasonable to have different kinds of principals,
the more protected ones being used (and thus potentially exposed to
stealing or attacks) more seldom and for more grave activities.

This is actually not related to using name pattern match for authorization.

[We are using special identities (principal names) for root-like
activities, but a fact of possessing such identity does not give
any privileges per se, one also must be present in an activity-specific
acl.]

A consistent pam setup may include an acl (like pam_listfile) doing
explicit authorization per identity for the actual purpose. Then there
are no extra implications for security, whether you use "/"-principal
names or not.

On the other hand if it is the fact of having */root identity which
authorizes by itself, then it is crucial to avoid doing the same thing
for a different service. Alternatively you only will be able to allocate
such identity to the persons to be authorized for _all_ such services,
including future ones (!) This _is_ possible to live with (consciously
or by accident) but it is unsafe in the long run as the semantics of
possessing such an identity becomes hard to evaluate. Should a new
helpdesk substitute get one or not?

I guess this implication is not evident, certainly not to all.

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

It looks like you are taking the unsafe way and treat all "advanced
services and rights" as a single class. While it may work for Stanford I
do not think it would be safe to recommend such practice to an average
system administrator.

There is nothing which prevents different people to treat the meaning
of the possession of such principal in different ways (having different
services in mind). Hence in a bigger installation you will never know
whether one or another person really has reasons to be authorized for a
certain cervice, even if somebody allocated a /root identity for her.
Nor will you have means to allow/disallow some things selectively for
a certain person when the need arrives.

IOW this is a long term violation of the principle of least privilege.

In many cases you will not notice the consequences but when you notice
it may be too late.

Regards,
Rune