Messages in this thread |  | | From | LD Landis <> | Subject | Authorization/Authentication Authority | Date | Fri, 13 Dec 1996 11:10:26 -0600 (CST) |
| |
Hi,
In a recent issue of UNIX Review (which I can't find right now, grrr, but it was this fall, I think), there was an article about what it would take to make UNIX a "well behaved" entity relative to security, etc. The model with which the conventional "UNIX Security Model" was contrasted was, of course, that of IBM MVS (where access questions are answered by a separate autonomous entity).
Now, having hacked kernel stuff from time to time, and also having to be sure to "do the right thing" (relative to security)... and given the current state of Linux (very good, IMO)... I've been thinking lately...
What is the likelihood of separating out the authentication/authorization, security, etc, etc, etc according to such a scheme? It seems to me that this would be relatively straight forward, given the current facilities in Linux, and would be a real win for those needing "advanced" features.
With such a partioning, if someone needed some special "ACL - Access Control List" or even a non-generalizable security measure (or something that no one else would want), there would be a central place through which such requests would go. This would allow easier customization, etc, as well.
For example (using 2.0.22 sources), logic such as namei.c:permission() and others would be placed "outside" the kernel. I know that this is not a trivial change, and there are scads of similar tests embedded throughout the kernel sources... But am curious if articles like that have encouraged some of the key developers to be thinking in these directions, or is it just to wrenching to consider?
-- Cheers, --ldl ----------------------------------------------------------------------------- LD Landis ldl@HealthPartners.Com N0YRQ Voice 612/883-5511 Fax 612/883-6363 HealthPartners, 8100 34th Avenue So, PO Box 1309, Minneapolis, MN 55440-1309 Shape your life not from your memories, but from your hopes. (Borrowed) -----------------------------------------------------------------------------
|  |