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

Hi Russ,

On Thu, Oct 20, 2011 at 12:21:09PM -0700, Russ Allbery wrote:
> 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).

I have already said why it is an unfortunate and avoidable implementation
of the mechanism.

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

That part of the sentence includes the word "generally". "At Stanford"
is not generally.

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

Well neither me neither you may say what is the majority, I guess.

I am actually curious how you maintain the validity of "the intersection"
(probably of the passswd database in the first hand) on all the computers?
Do you have any automated means of adding an account on a set of computers
when a new employee arrives, remove at her departure and alike? How
do you selectively disable services (say local against remote login)
if necessary (I guess you simply don't)?

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

Well, where is the list (of accounts to be exposed to a certain computer)
stored in this case? Is it maintainable atomatically? Such a list looks
like an acl - without a reason being applied via passwd (pam_listfile
or alike is much more transparent).

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

With all due respect these are not simple problems (selectively managing
access rights on large sets of hosts).

The fact that this has been "solved" in dozens different ways just
illustrates that no solution is general enough.

If a presence of an account in the password database decides over
authorization for host's services, you must adjust passwd databases on
every host according to your access control needs and anyway apply extra
control means when there is more than one service per host (say, local
vs remote login).

So the approach makes these problems even harder than they have to be.

> It does not do your argument much good to say that something
> that's widely, successfully used isn't practical.

Well, practical it is, in the sense of following with the stream.
In the sense of efficiently solving problems and avoiding to create
new ones it is not.

Looking at the history, we see that widely percepted views and practices
may happen to be spectacularly unreasonable and even harmful.
Do you mean computing is an exception? Alas, it is not.

Be sure, I really appreciate your pam_krb5.
Just trying to let the future users understand the implications when they
will use the module.

Regards,
Rune