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

Hello Russ,

On Sun, Oct 30, 2011 at 12:18:25AM -0700, Russ Allbery wrote:
> >> 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.
> I know; I just don't agree.  :)

The difference between our viewpoints is that you (probably like most of
the people you interact with) are oriented to solving "problems of the
day". You want to help those people when you develop for Kerberos). That's
a very reasonable point of view.

Nevertheless I am looking at _why_ many of the problems are there and it
leads me to a different estimation of pros and cons.

I have seen already a couple of generations of system administrators
who become very skilled in implementing hacks and workarounds. Of
course they do solve problems of the day - problems which often would
not be there were it not the confusing design from the beginning.

> I think krb5_kuserok is a simple authorization system, but it's a fine one
> for some common purposes.  I certainly appreciate your desire to have a

We disagree about what "common purposes" are.

What is a good measure of complexity of a system? 20 years ago I said
"the number of computers". Now I say "the number of differently configured
service instances" (including the "login" service, which is nothing more
than one kind of many - it used to be the only one in 1970's but that's it).

Given the shift in the perception I can not agree that unix-specific parts
of Kerberos API are "natural". Such API bits reflect the reality of the past.
I want the Kerberos deployers (the system administrators) be aware of
this fact. Many, well, most of them (in my humble experience) do not.

Harry's case is a nice example - he is knowledgeable, capable of reading
and understanding the source, debugging and doing all the technical stuff.
At least one of his problems was that he expected several different
limitations which in reality do not exist. He is also trying to keep
the old access management model (without actually any reason besides the
historical one), which is at best incovenient in the long run.

So I am trying to improve the (documentation and) understanding by pointing
out the limitations of the traditional practices and APIs and why they
are not as suitable as they are very often percepted.

> > Well neither me neither you may say what is the majority, I guess.
> 
> Sure.  But I've been using Kerberos in production environments for over 15
> years now, I've gone to a lot of conferences and talked to administrators

Russ, I feel a great respect for your experience and work. You are
presumably well informed about how Kerberos-aware people are using
Kerberos.

My experience is less Kerberos-specific, I have always been concerned
about well done system administration, with or without Kerberos.
We have different perspectives and hence are likely to have different
views. I guess compared to yourself I had a chance to meet more system
administrators who did never go to Kerberos-related conferences. So take
my word for it or ignore.

Kerberos is widely misunderstood - with the consequences for
security and for the infrastructure architectures.

You have a very detailed idea of how Kerberos works and you can
see the implications of different deployment decisions. There are
unfortunately few other people who do.

A very popular use of Kerberos is certainly for login authentication.
Do you think an average system administrator can distinguish which
parts of a pam_krb5 correspond to "server" and "client" in Kerberos?
I don't think so. How can they know that they are using it correctly
and securely?

[[[
To make sure what I mean:
- pam_krb fetches a service ticket for a service
  "host/f.q.d.n" (the service principal name)
  using credentials for user "alice" (the client principal name)
  so, at this point pam_krb5 acts as a Kerberos client
  for the service (which happens to run on the same computer
  and even in the same process)

  (IOW the login process provides to an anonymous user access to a
  kerberos client instance, for the purpose of ipossibly accessing the
  unix login service)

- pam_krb5 sends the service ticket to the process of itself (a no-op)
  and asks to be allowed to login - this is the actual client-server
  communication, as seen by Kerberos protocols

- pam_krb5 verifies the ticket against a keytab to see if the client
  is who she pretends to be
  (here pam_krb5 is acting as a server)

- (optionally doing authorization decisions, which has nothing to do with
  Kerberos protocols but the libraries historically include some means -
  creating an impression that this somehow relates to the protocol...)
]]]

> > How do you selectively disable services (say local against remote login)
> > if necessary (I guess you simply don't)?
> 
> We don't just because we've never had a need to do so.

That's possibly why you do not notice the limitation.

>  It's hard to
> devise a subset of login services that are reasonably distinguishable and
> truly isolated (so that you can't get from one to the other through
> obvious means).  I know people who do a lot of work with things like that

We do not allow remote logins to some classes of users / computers.
Besides other things, if an account becomes compromized, it can not be
abused from overseas, without coming to a computer in person. This makes
a nice difference.

> > Such a list looks like an acl - without a reason being applied via
> > passwd (pam_listfile or alike is much more transparent).
> 
> Why wouldn't you want to apply it to /etc/passwd?  It gives you various
> other things for free.

Hmm. What do I get "for free"? The possibility
to check for a presence of a name in a single acl by getpwent().
And a hard constraint that the record's presence must reflect what I need.
If it is a saving, then only in really small installations.

If the presence of a user record means the right to use the computer:
- it is coupled to "directory service" information (I would miss the
  info if the user is banned to login, even temporarily, also I have to
  make sure the metainfo is correct when I add the user back)
- it is a single acl per computer while I practically always need more

If you mean that a certain form of a field in passwd is to be interpreted
as an authorization bit (like abusing the passwd hash field or gecos or
shell) - I don't find it useful, to put different kinds of information
together. I want to be able to modify every piece (acl vs say last name)
without risking to influence the other ones.

I may as well prefer different means to deliver the information, depending
on how often it changes and how fast it is to be delivered. This can
differ for different kinds of acls and of course differ between the directory
information and the access control information.

So relying on passwd as "the" authorization database removes many
potentially useful, sometimes possibly crucial possibilities. Everyone
may still decide to go this way and take the consequences. I want just
that such a decision becomes a conscious one.

> It's an area where I doubt that there will ever be a solution that's
> sufficiently general that everyone will want to use the same one, since
> such a general solution would also be far too complicated for many people
> who can use something much simpler.

A well structured general solution is as complex as the actual problem it
is solving at the moment, not more (not less, it would not be a complete
solution otherwise).

Going the traditional Unix way does not make it simple. It is to the
contrary applying the unrelated complexity and flaws of an old design
outside its original target.

I appreciate that you took the time to explain and argue your point
Russ. Technically we understand each other well, I believe. Pity that
we have different views on how Kerberos should be documented and which
practices are to be recommended.

Regards,
Rune