RE: [SC-L] ACL (access control lists) generic design questions (oh, and Reply-To)
Hi William, You might want to look into the way Windows has solved it. I haven't seen any detailed docs on this beyond Keith Brown's Programming Windows Security [1], but I'm sure they're out there. Basically, if I recall correctly, Win32 makes so that each object type can have its own set of permissions. These can be mapped into generic permissions, i.e. GENERIC_READ maps to FILE_READ for files and REGKEY_READ (or whatever it's called) for registry keys. So, the generic permissions can be used by clients to require Read, without knowing the specific bits for the object type in question. Depending on whether you want to support inheritance and grouping/containment, this can become tricky. If you want to stick with static types, maybe you should throw in an execute bit as well, it's not appropriate for all object types, but files might be one example, and you can easily define custom types that are actions rather than objects. Hope that helps, Kim [1] http://www.amazon.com/o/ASIN/0201604426 P.S. Kenneth, any chance you could set the Reply-To header to [EMAIL PROTECTED] instead of the original sender? My first stab at a reply to this thread went to Brian A. Shea... Cheers! [Ed. Thanks for the suggestion. Do others on the list want a reply-to pointing back at SC-L as well? Let me know, and I'll go with what the group wants. KRvW] > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of William Herrera > Sent: den 26 februari 2004 09:20 > To: [EMAIL PROTECTED] > Subject: [SC-L] ACL (access control lists) generic design questions > > Hello folks, > > 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?
RE: [SC-L] ACL (access control lists) generic design questions
Glenn and Mary Everhart [EMAIL PROTECTED] wrote: >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.) Hi all, Multics was written in PL-1 and some assembler. See the following link. http://www.multicians.org/general.html Later, Bill
Re: [SC-L] ACL (access control lists) generic design questions
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.)
[SC-L] ACL (access control lists) generic design questions
Hello folks, 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?
Re: [SC-L] ACL (access control lists) generic design questions
William, I'll be very interested in your extensible ACL-style authorization.
If you are serious about generalizing the ACL interpretations, you might
think back not just to Multics (with directories and files having different
interpretations of the ACL protection bits), but also to our Provably Secure
Operating System (PSOS), in which each capability had an associated type and
where the capabilities for each type had their own type-specific
interpretation of the protection bits. PGN
@inProceedings{DaleyNeumann,
Author="R.C. Daley and P.G. Neumann",
Title="A General-Purpose File System for Secondary Storage",
Booktitle="{AFIPS} Conference Proceedings, Fall Joint Computer Conference",
Publisher="Spartan Books", Year="1965", Month="November", Pages="213--229"}
The 1973-1980 work on PSOS is summarized more recently in "PSOS Revisited":
@InProceedings{NeumannFeiertag03,
Author="P.G. Neumann and R.J. Feiertag",
Title="{PSOS} Revisited",
BookTitle="Proceedings of the 19th Annual Computer Security Applications
Conference (ACSAC 2003), Classic Papers section",
Organization="IEEE Computer Society",
Address="Las Vegas, Nevada", Year="2003", Month="December", pages="208--216",
NOTE="http://www.csl.sri.com/neumann/psos03.pdf.";
}
RE: [SC-L] ACL (access control lists) generic design questions
Would you want to ad any ACL ability or attributes for Meta-Data on objects? or would that ACL be on a different object? -Original Message- From: William Herrera [mailto:[EMAIL PROTECTED] Sent: Thursday, February 26, 2004 12:20 AM To: [EMAIL PROTECTED] Subject: [SC-L] ACL (access control lists) generic design questions Hello folks, 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?
Re: [SC-L] ACL (access control lists) generic design questions
William Herrera wrote: Does anyone know of an access control type they've wanted in an access control list but not had? It would be nice to be able to control the ability to annotate an object (eg. by adding additional data forks), and also on file systems like ext2 that support additional attributes like immutability or append only to be able to control access to those. Cheers Rich.
