Re: ACL (access control lists) generic design questions

[Glenn and Mary Everhart <Everhart () gce com>]

William Herrera wrote:
I think some here might have suggestions about improvements to existing 
ACL's.


I'm working on an extensible access-control-list style authorization 
system, beyond the usual read/write authorization schemes, probably to 
be written as a Perl module for CGI use and using a database on the back 
end. This is designed to allow fine control over the use of data and 
other objects by a given user. Right now it mainly uses 
read/append/edit/delete modes, since in its present alpha form it has a 
well defined groupware use, but I intend to make it more flexible than 
that, generic enough to be used as a general-purpose open source perl 
object authorization module.


In doing so, I'd like to define modes of access beyond the ones allowed 
by Unix and Windows ACL's. These, so far, include:


list object (see the object in a ls or dir listing)

read or view object

append (simple data) to object

add link (to another object) within the object

edit (change existing object's data or structure)

delete object

undelete or roll back object to a prior state

administer (change object's authorizations or modes)

ownership (to be the creator of the object or equivalent)

Does anyone know of an access control type they've wanted in an access
control list but not had?


How about access by a process with too much privilege?
Also it would be handy to be able to control access in some ways
directly by integrity level. Initially it is I think sufficient to
be able to hand designate low integrity programs, but there needs
to be a system to propagate this state to objects that have been
accessed by, or perhaps altered by, a low integrity program. I
worked up some code that implemented such a number of years back, but
have not experimented in the area for some time. The point of this is
to deal with mobile code where the mobile code really should not be
treated as acting as a human user's agent.

It is probably worth mentioning that some of the old MLS operating systems
that were too slow back in the, say, late 70s, may be just fine now, with
machines that run ~1000 times faster, and getting faster still. What was
a little too slow to use on a pdp11 would probably look blazingly fast on
most any contemporary processor. Same might be true for good old Multics
if it can be compiled on newer iron. (I didn't get close enough to it to
know what it was written in. Maybe someone will comment.)