jjg@linus.UUCP (Jeff Glass) (06/16/85)
I would like to ask for your comments on a mod I made recently
on our 4.2bsd system (on a 750).
since here at MITRE we have many users who are also Multics users,
a frequent disparagement of UNIX is that it only has owner-group-other
control on files, whereas Multics has access control lists, which are
much more flexible.
so, I implemented access control lists in UNIX. the implementation allows
up to 8 entries in an access control list. an entry may be either for
a specific user or group. the user or group may be granted any (or none)
of the read-write-execute permissions. the owner of the file (or the
superuser) can set the access control list.
this is in addition to the conventional user-group-other control.
the chmod system call and program are unchanged.
the changes to the kernel were very minor: two new system calls were
added to get and set the access control list for a file; the access()
routine was modified to use the access control list in addition to the
user-group-other control; and the routines to create files and
directories were trivially modified to clear the access control list
for the new file. also, the login program was modified to clear the
acl on the terminal line.
the access control list is stored in the inode, in what was the
ic_spare field. I know that this is reserved for future use, but this
was an experiment, so I felt that I could try it and see how it works.
anyway, I don't know what I would have to do to increase the inode size.
this has been running at our site for a month, with good results.
no problems have been found yet.
if you are interested, I would be glad to send you the diffs to the
kernel code and the sources of the programs to list and modify the
access control lists of files. in any case, I would like to hear your
comments and suggestions.
/jeff
security!jjg@mitre-bedford.ARPA (MIL)
{allegra,ihnp4,utzoo,philabs,uw-beaver}!linus!security!jjg (UUCP)wcs@ho95e.UUCP (x0705) (06/21/85)
> so, I implemented access control lists in UNIX. [.....] > >... the changes to the kernel were very minor: two new system calls were > > /jeff > > security!jjg@mitre-bedford.ARPA (MIL) > {allegra,ihnp4,utzoo,philabs,uw-beaver}!linus!security!jjg (UUCP) At the Dallas USENIX, Dan Klein of Avatar gave a paper on "A Capability Based Protection Mechanism Under UNIX". He wanted the same kind of flexibility you wanted, written in a portable way without kernel hacking. So he invented Capa's. A capa is a program you can give somebody which gives them permission to do <something> and/or <anything> to one or more files that belong to you. Capa's appear to be secure and flexible, and they're portable (V6, V7, 4.2BSD, System III, System V!) The code for them is described in the paper. (There's a typo on the last-4th line; change "*execv = 0" into "*ev = 0".) Dan's mailing address is listed as {mcnc,decvax,floyd}!dls!mi-cec!dvk Dan.Klein@CMU-CS-A.ARPA but you should really get the procedings from the conference so you can read the other papers also. -- Bill Stewart, AT&T Bell Labs, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
smk@axiom.UUCP (Steven M. Kramer) (06/26/85)
> Bill Stewart, AT&T Bell Labs, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs > Protection Mechanism Under UNIX". He wanted the same kind of flexibility you > wanted, written in a portable way without kernel hacking. So he invented > Capa's. A capa is a program you can give somebody which gives them permission The problem with capa's is that although there is no kernel hacking necessary, there is not complete security when using them, and more importantly, many UNIX programs do not have the command line interface that is required with them. The philosophy of capa's, for those who do not know, is to have a setuid program deal with opening files and the capa (capability) is really a file descriptor passed to a normal program from the setuid program (since UNIX allows them to be passed via an exec). I have done similar things with setuid programs in Linus III/IV by having a setuid program become a resource manager. I guess the point in both applications is that, when properly administered, setuid programs can become extremely useful in creating "domains" for handling least privilege concepts. (They also can easily defeat such purposes as we know.) -- --steve kramer {allegra,genrad,ihnp4,utzoo,philabs,uw-beaver}!linus!axiom!smk (UUCP) linus!axiom!smk@mitre-bedford (MIL)