[2178] in Kerberos
Re: Existing authentication mechanisms have a deficiency
daemon@ATHENA.MIT.EDU (Danny Nessett)
Wed Sep 9 12:54:24 1992
Date: Wed, 9 Sep 92 09:14:34 PDT
From: nessett@ocfmail.ocf.llnl.gov (Danny Nessett)
To: glenz@ocsg.COM, kerberos@Athena.MIT.EDU
Cc: tytso@Athena.MIT.EDU
Glen Zorn writes,
> I think you may be confusing authentication and authorization:even if a system
> were completely Kerberized for authentication purposes, you would still need
> some way to specify which principals were *authorized* to perform various
> tasks, access local files, etc.Probably you would want this control to reside
> locally, or at least be configurable on a machine-by-machine basis -- I might
> be trusted to administer a software development system, but not to browse
> the company's payroll files. That's where the /etc/passwd file (or its
> surrogate) comes in, in specifying which users (however they are
> authenticated) are allowed what type of access (if any) to the local system.
>
> ~ Glen
Similarly, Ted Ts'o writes,
>
> Yup.... what's missing is "an authorization mechanism". Both Kerberos
> and SPX purport to offer an "authentication", and completely punt on the
> "authorization" issue, leaving that as an exercise for the application
> writer to deal with.
>
> While this may seem to be an amazing cop out, since every nearly every
> application which uses the authentication services provided by Kerberos
> or SPX will require some sort of authorization policy, even if it is as
> simple as checking an ACL, file, there is a good reason for this design
> choice. And the reason is this:
>
> While authentication systems are relatively well-understood at
> this point, authorization policies are not.
>
> Specifically, there is no good, general model which shows what sort of
> functionality an system would need in order to provide a completely
> general authorization policy which would work for all possible
> applications. There have been attempts to do so --- ECMA has issued one
> or two technical reports which try to do so --- but they tend to be
> fairly confusing, and it is not clear at least to me whether they
> generate more light than heat. So it seems fairly clear to me that a
> workable authorization framework is at least partially still an area for
> research.
>
> What we use at MIT Project Athena is a system called "Moira" to handle
> our authorization policies. Specifically, it is a database system which
> automtically distributes configuration files to most of the Project
> Athena servers every night. This allows most of the authorizatrion
> information to bee kept in exactly one place, as your requirement
> specifies. Since connections to Moira require a Kerberos-authenticated
> connection, reasonable access list control can be placed on the Moira
> database, and it is even possible to figure out who made what
> modifications to a particular database entry.
>
> Moira is big and hard to set up (it runs on top of Ingres), so it may
> not be appropriate for all sites. But it is one solution which keeps a
> large part of the authorization information in one centralized place.
>
> - Ted
While I agree that authorization is a topic that has not been adequately
treated yet in regards to distributed systems, I think you missed my point.
The /etc/passwd file carries alot of information about a user including
his encrypted password, his uid, his personal information, etc. It is also
true that /etc/passwd couldn't simply be eliminated unless the data about
a person that is kept there is stored elsewhere. However, my point was
about authentication; I was not addressing the general question of eliminating
/etc/passwd.
One could imagine a system configured so that all on-machine authentication
requests contacted the appropriate server, say the Kerberos server or
SPX LEAF server, rather than looking in /etc/passwd for the user's
encrypted password. Actually, I think SUN already does something like this
by looking in the NIS (aka Yellow Pages) database for a user's encrypted
password. Moving the authentication information off-machine has the advantage
of centralizing the data, allowing it to be protected more carefully at lower
cost, providing a single point of administration for authentication, etc.
My suggestion about modifying su to contact the appropriate server to
perform authentication was along these lines.
By the way, I'm not claiming that such a scheme is problem-free. It means
locating and changing all programs that access the encrypted password
field of /etc/passwd and changing them to call a routine that authenticates
using the central server. This requires not only new code, but also maintenance
of these modified programs as the central authentication systems change from
version to version.
Regards,
Dan
