From: hpa@merle.acns.nwu.edu (H. Peter Anvin N9ITP) Subject: Re: Access control lists and Linux Date: Sat, 17 Apr 1993 02:37:33 GMT
In article <1rj7ug$89r@walt.ee.pdx.edu> of comp.os.linux,
gary@acacia (Gary Moyer) writes:
> steve@rama.demon.co.uk (Steve Entwistle) writes:
> : One possibility would be to develop a generalised security
> : package, such as RACF, used on IBM Mainframe systems. This system uses a
> : central database in which all the security information for various
> : resources is stored, e.g. Files, Users, Terminals etc.
> :
> : A sample entry for a File resource might be :-
> :
> :
> : Filename : /etc/foobar
> : Default Access : NONE
> :
> : User fred, Access = READ
> : Group Wheel, Access = UPDATE
> :
> :
> : Rather than changing the filesystem code, you could insert a
> : call to the resource checking routine in all the system calls that access
> : the resource you want to protect (in this case, all the system calls concerned
> : with file accesses). If there is no entry in the database for a particular
> : file, I guess you would then just use the normal file permission bits.
> :
> : The advantages of doing it this way is that not only is it filesystem
> : independent, but it is also readily extended to protecting other resources.
>
> Thats an interesting idea. I can see 2 major drawbacks:
> 1) what protection scheme would be used for this centralized data base?
> 2) if it were stored on a secondary storage device: what would guarantee
> security to it ?
>
> Thoughts?
>
Well, here is a suggestion:
Let each filesystem be mounted with or without access daemon support
(with for flexible security, without for speed). If the kernel
detects a permission mismatch, it will call up (through some standard
interface) `accessd' which (of course) runs as root. It informs
accessd of uid, gid(s) and filename, and accessd returns the
permissions approved to the kernel. Alternatively `accessd' could be
a part of the kernel, but it *would* be bloat....
I would suggest the accessd database is simply a (collection of)
file(s) to which only root have access (by the traditional permissiona
bits).
Of course any such proposal must be carefully examined, especially the
interface between the access daemon and the kernel (/dev/access 600
root maybe).
/hpa
-- INTERNET: hpa@nwu.edu FINGER: hpa@eecs.nwu.edu BITNET: HPA@NUACC IBM MAIL: 36073 at IBMX400 HAM RADIO: N9ITP, SM4TKN NeXTMAIL: hpa@speedy.acns.nwu.edu Heja Sverige friskt humör! EG väntar utanför! :-)