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

On 10/14/2011 11:28 AM, Russ Allbery wrote:
> 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.

Is it really equivalent to that .k5login entirely?  It is not, since 
krb5_kuserok will not associate users and principals what pam_krb tries 
to fix with this.  So, stacks that don't call upon pam: gssapi, sasl, 
nfs...  will not associate the principals pam_krb5 does.

I think for a start one change in lib/krb5/kuserok.c gets it done:

check_one_file(krb5_context context,
const char *filename,
struct passwd *pwd,
krb5_principal principal,
krb5_boolean *result)
{
FILE *f;
char buf[BUFSIZ];
krb5_error_code ret;
struct stat st;
*result = FALSE;
...	*newline  =  '\0';
ret = krb5_parse_name (context, buf, &tmp);
if (ret)
continue;

-- *result = krb5_principal_compare (context, principal, tmp);

++ *result = krb5_principal_match (context, principal, tmp);
krb5_free_principal (context, tmp);
if (*result) {
fclose (f);
return 0;
}
}
fclose (f);
return 0;
}


makes a good start.




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