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

I think you're not understanding what I'm getting at, but I'm not quite
following your discussion, so it may just be that I'm not understanding
your point.

[email protected] writes:

> 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 don't see any way that the alt_auth_map example does this.  Perhaps I
should take a step back and explain what it does, to make sure that we're
on the same page.

        If this option is present, the default behavior is to try this
        alternate principal first and then fall back to the standard
        behavior if it fails. The primary usage is to allow alternative
        principals to be used for authentication in programs like
        sudo. Most examples will look like:

            alt_auth_map=%s/root

        which attempts authentication as the root instance of the username
        first and then falls back to the regular username (but see
        *force_alt_auth* and *only_alt_auth*).

In other words, adding an alt_auth_map=%s/root to the PAM configuration is
equivalent to giving every user a .k5login file that lists both user@REALM
and user/root@REALM and then using search_k5login.  It allows the /root
instance to be used to authenticate to their personal UNIX account.

It does *not* allow that instance to be used to authenticate to root, and
it doesn't allow it access to any accounts other than their own.  So I
don't understand your point above about "all future services."  It allows
the root instance to be equivalent to the regular instance for logging on
to systems as that user, but surely that's not something that's
particularly exciting?  Both of those are principals that identify the
user.  It's not something that you want to do if the root instance should
not have access to things the regular instance has access to, but this is
an unusual way to use root instances.

I consider it mostly useful in combination with force_alt_auth or
only_alt_auth and a special configuration for a program like sudo, and
that was the original purpose.  If your sudo PAM configuration contains:

    alt_auth_map=%s/root only_alt_auth

then users have to use their root instance when authenticating to sudo
rather than their regular instance.  In other words, it lets you apply the
same instance handling that ksu does by default to sudo, rather than using
the user's normal password for sudo access (which I consider less secure).

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

I don't understand what I said that would cause this confusion.  Giving
out a root instance to someone at Stanford does not give them access to
anything.  It *allows* them to use ksu *if* that root instance is added to
root's .k5login file, and also gives them a separate principal that they
can use for privileged operations (and some other parts of our
infrastructure require that people use root instances rather than regular
instances).  But it doesn't bypass any authorization checks; there's
nothing that you get access to solely because you have a root instance.

However, in practice, the privileges of a root instance are a superset of
the privileges of the corresponding regular instance because people don't
request root instances unless they plan on using them, and how they're
used is to get root on systems.  Systems onto which they generally also
authenticate with their regular instance.  And as we all know, root on a
system that receives forwarded Kerberos tickets (and we use AFS, so we do
usually forward Kerberos tickets) has access to any of those tickets and
hence can impersonate regular users of that system with a bit of effort.

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

This is handled by whether or not that instance is added to root's
.k5login.

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