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

[email protected] writes:
> On Thu, Oct 20, 2011 at 12:21:09PM -0700, Russ Allbery wrote:

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

I know; I just don't agree.  :)

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
complex authorization system that permits more restrictive rules.  But as
important as expressiveness of an authorization system is a match between
the authorization system and the expectations and understandings of the
administrator, and security that's too complicated for its purpose is
almost useless because people will do something (too) simple to it to
"make it work" and end up in a bad situation.

While there are all sorts of interesting cases where this is not the case,
I think it's quite safe to say from my personal experience and many
conversations with users of my software and with my peers that the vast
majority of specific instances of Kerberos deployed on particular systems
are quite simple.  By far the most common authorization problem in
Kerberos is to allow all configured users on the system to log on to their
accounts on the system using the Kerberos credentials from their default
local realm.  And for that purpose krb5_kuserok works quite well.

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

I was assuming that by "generally" you meant that this was the majority
case.  In that case, I was giving a counter-example, and a sufficient
quantity of counter-examples refutes a statement of generality in that
sense.

If you instead by "generally" meant "in the most general case," then I
agree; krb5_kuserok isn't appropriate for every situation.  But it's a
good 80% solution.

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

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
at other educational systems and companies, I've given tutorials and talks
on PAM and Kerberos for the AFS and Kerberos Best Practices Workshop, and
I maintain one of the major Kerberos PAM implementations and the default
for Ubuntu and Debian.  I also read all the discussion of Kerberos PAM
issues on the major Kerberos discussion lists.  So I hear a lot about how
people use it, and I of course see all the bug reports filed against
Ubuntu and Debian.

This doesn't mean that I'm right and you're wrong, of course, but it's a
lot of accumulated information about how a lot of people use PAM, and I'm
pretty sure it's enough total information to make at least some educated
guesses about what the vast majority of Kerberos PAM configurations look
like.

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

Of course.  I think nearly every institution of a reasonable size has
something like that; if they don't, I'd have to question either the
priorities of their IT management (who are squandering human resources on
makework) or the strategic thinking of their IT staff.  It's basically a
necessity to scale a system administration group when administering a
reasonably large set of computers.

There are a ton of different ways to do this, of course.  We've used
probably a half-dozen different ones during the time I've worked at
Stanford, ranging from package and locally-written scripts to NIS
netgroups and Puppet user management.  But we always had something.

> 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.  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
using things like restricted shells with separate ACLs or individual jails
or chroots per user, but we've never had a need to have a limited subset
of shell services.  When shell access isn't appropriate, the situation has
always changed drastically enough that the user is actually authenticating
to some sort of service, not for system login, and the service has its own
concept of ACLs.

If we were doing, say, a general web hosting facility that allowed shell
login, that might be different (but I suspect that the PAM authorization
model would still work; the restrictions would be done another way).

> Well, where is the list (of accounts to be exposed to a certain
> computer) stored in this case? Is it maintainable atomatically?

It can be stored in all sorts of places.  We store it in Puppet and use
Puppet's management of users on systems, but other popular choices are
LDAP and NIS.

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

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

Well, maybe we define simple in different ways.

I think it's solved in different ways because which way you want to use
depends a lot on what infrastructure you already have.  If you're already
using Puppet on all your systems, then managing users in Puppet is obvious
and easy.  If you have a good LDAP environment, then using nss-ldap along
with either netgroups in a NIS schema or ACLs in LDAP or something similar
to map sets of users to systems is quite powerful and one of the most
sophisticated solutions, although it's harder to set up initially.  Some
sites don't have many systems and have one set of admins and just
synchronize the /etc/passwd file between systems with simple scripts;
we've done that before too.

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.

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

If one doesn't already have a mechanism for adjusting such things across
all one's hosts easily and simply, I really have to question whether that
site has implemented large-scale system administration.  Which is fine;
some sites are just small, and they therefore use small solutions.  (But
manual changes often work at a small scale.)  But when you're talking
about large-site system administration, this is just basic, obvious, day
one stuff.  A large site without such a mechanism would be sort of like a
data center without redundant power.

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