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

[email protected] writes:

> Russ's pam_krb5 works like
> 1a. check the proof that the entity (the human) has a fundamental
>     association to a _Kerberos_ identity of a certain class chosen
>     by the module
>     (e.g. "either the same string as the local account name
>     or the same string with "/root" suffix appended)
> 1b. take this as a proof that the entity (the human) has also
>     a fundamental association to the given _local_ identity

Note that this is only true if alt_auth_map is used, which is not the
default.  If alt_auth_map is not used, then 1b is false; pam_krb5 uses the
normal Kerberos authorization mechanism that's been in use for forever,
the same one that ssh, klogind, krshd, etc. all use (krb5_kuserok).  Well,
there are some other options as well, but that's the default.

> Kerberos can not be used for step (2) as Kerberos has nothing to
> do with how a certain host is set up. Its database does not contain
> acls-per-host-and-service.

This is true when speaking of Kerberos as a wire protocol, but Kerberos as
a software product has always included a simple authorization service
(krb5_kuserok, which uses .k5login as an ACL).  This has been true going
all the way back to Kerberos v4, which used .klogin instead.

> Simply skipping step 2 is also wrong as the resulting implicit
> "authorization acl" becomes an intersection of the set of the locally
> known Unix account names and of the principal names in the KDC, neither
> of which generally reflect which users shall be able the use the actual
> computer.

Putting aside the fact that you're ignoring .k5login, the part of your
sentence after the comma is simply false in Stanford's environment and in
many others.  That intersection *does* reflect which users shall be able
to use the actual computer.  And that configuration is extremely common;
in fact, I would say that it's the vast majority of Kerberos PAM
configurations.

>> The purpose of a PAM "account" module is to make a different class of
>> authorization decision; namely, to decide whether the account in
>> question is permitted to use the system at all.

> I would say "permitted to use the service in question" where the service
> can be, say, local-login, sudo, remote-login-via-ssh, younameit...

Except that's not what it generally does.

> If local accounts are created sparingly, then the local passwd mostly is
> the acl. As soon as you use a distributed name service for passwd, it
> becomes about as loose as KDC or much more, depending on the kind of the
> setup.

Only if you set up your distributed name service for password without
regard for security considerations.  Limiting which accounts are exposed
to a given system is a very basic configuration step when using a
distributed password name service.

> The passwd database is not practical as an acl.
> What about selective/temporary access ban on a set of hosts?
> What about installations with distributed name services, using NIS,
> LDAP or whatever?

These are all simple, solved problems and have been for well over a
decade.  It does not do your argument much good to say that something
that's widely, successfully used isn't practical.

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