[E-Lang] draft statement of consensus

Karp, Alan alan_karp@hp.com
Tue, 6 Feb 2001 11:45:45 -0800

As I stated previously, I believe that we are talking about access control
mechanisms, not security.  The former determines whether or not to honor a
request based on the authorities presented by, or the identidy of, the
requester.  The latter determines what authorities are given to whom (in the
generic sense of "whom").  In that regard, statement 1 might be changed to

1. We all agree that currently available ACL systems are too broken to be
serious contenders for general-purpose effective access control.

It is my belief that ACLs do provide an adequate means of expressing
"security" in the above sense.  I don't believe that capabilities are very
good at expressing "security" in the above sense.  On the other hand, I
support the statement if the definition of the word "security" is taken to
mean access control.

Alan Karp
Principal Scientist
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-2
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278

> -----Original Message-----
> From: Marc Stiegler [mailto:marcs@skyhunter.com]
> Sent: Monday, February 05, 2001 4:51 PM
> To: E Language Discussions
> Subject: [E-Lang] draft statement of consensus
> Goodness--I take 2 days off from reading this list, and there 
> is a huge
> batch of interesting new stuff crying out for me to respond 
> :-) Well, today
> I am keeping focus on the Statement of Consensus.
> At the bottom please find the second draft of a Statement of 
> Consensus,
> incorporating changes as identified in email responses to the 
> first draft.
> This draft is designed to eventually be a standalone 
> document: if I do not
> get any disagreements in a 4 day period, I will publish this 
> as "final" on
> e-lang to make it a part of the archive.
> If someone has a great idea for a wordsmithing change, or 
> another point of
> possible consensus, I urge holding back until this one is 
> published: if I
> have to change any of these statements, I will feel obligated 
> to start the
> 4-day quiet period from scratch again :-)
> Unless someone objects to the following policy, I would consider it
> acceptable to delete a statement without restarting the quiet 
> period. I
> would do this of course only if the statement stimulates criticisms.
> I have included a list of names of participants. If someone 
> desires their
> name removed or added to the list, please let me know. Zooko, 
> because of the
> disclaimer at the end of the statement, you may desire to 
> have your name
> added, your choice. Changing the list of participant names 
> will also not
> make me feel obligated to start the clock again, I will just 
> change it for
> the final.
> Finally, I have left the numbering of the statements the same 
> so that if
> someone wants to compare the old to the new, point 7 is still 
> point 7. I
> will renumber for the final.
> --marcs
> ----Change notes----
> Statements 1-3: I have left the substantive statements 
> exactly as they were,
> and deleted the justifications I had written that explained 
> why I thought
> these were good candidates for consensus. Statement 3 had a 
> long qualifier
> which is now subsumed by the Disclaimer at the end.
> Statement 4: Deleted. This is the one about extensibility 
> with capabilities
> and ACLs. I believe there are some powerful statements to be 
> made in this
> realm, but they need to be worked through for a future 
> summary. Soon I will
> post email demonstrating the flexibility of capabilities with hopes of
> finding an interesting consensus. Not today :-)
> Statement 5: Edited for readability, but I do not believe the 
> change was
> substantive.
> Statement 6(a-c): Now based on Jonathan's critique, ending with the
> assertion about E and EROS from the original to which no one 
> objected. In
> the original there was a big caveat about disparity of 
> knowledge of E and
> EROS, now subsumed by the Disclaimer at the end.
> Statement 7: Excerpted from Tyler's critique of the original 
> statement 7,
> based on elements that were not disputed later by David and 
> Markm. There is
> probably a stronger statement that can be made here, but I 
> believe it should
> be postponed for a future summary.
> As repeatedly noted above, I have added a Disclaimer at the 
> end which states
> the limits of the claims based on the knowledge of the 
> participants. On the
> one hand, the disclaimer is saying something that is 
> necessarily so, and
> anyone could deduce that it is true. On the other hand, it 
> probably deserves
> to be said explicitly.
> --------------DRAFT------------------
> Statements Of Consensus as of February 9, 2001
> 1. We all agree that currently available ACL systems are too 
> broken to be
> serious contenders for general-purpose effective security.
> 2. We all agree there is at least one security relationship that
> capabilities cannot create, even in theory. This is the one 
> Ralph Hartley
> identified that Mark Miller agrees with. We also agree that 
> this one is not
> of practical importance. We also agree that there may be 
> others that might
> be of practical importance, though there is no agreement that 
> others have
> been found.
> 3. We all agree that capabilities systems as embodied in EROS 
> and E seem
> architecturally sound enough to be serious contenders for providing
> general-purpose effective security.
> 5. We all agree that the Principle of Least Authority (POLA) 
> is an important
> element in security design, and is indeed a sensible best-practice.
> 6a) We all agree that capabilities inherently convey "narrow" 
> authorities,
> in the sense that they name only one object at a time (in 
> contrast to user
> ids as basis for protection, which name multiple objects at a time).
> 6b) We all agree that explicitly designating authority at the 
> locus of use
> imposes a style of use that simultaneously tends to reduce 
> the number of
> authority misuse errors and renders them easier to locate, 
> identify, and
> repair. We agree that capability systems (via C-list indices) lend
> themselves to such explicit designation. We deduce that 
> capability systems
> lend themselves to the application of POLA, though one can 
> build non-POLA
> capability systems.
> 6c) Finally, we recognize that POLA is a part of both E and 
> EROS as actual
> implementations.
> 7. We all agree that each authority should have its own protection,
> according to the POLA. Compromising one protection should not yield
> the ability to compromise others.
> Disclaimer: The participants in this discussion have a wide 
> disparity of
> knowledge about different aspects of these discussions. 
> Consequently, the
> necessarily more correct way of stating this consensus is 
> that everyone
> agrees within the constraints of their knowledge: For any one 
> aspect of
> these statements of consensus, those with a weaker knowledge 
> of that aspect
> know of no fault in the statement, and are necessarily 
> trusting those with a
> stronger knowledge of that aspect to have highlighted a fault 
> if there is
> one. Equally of course, if new evidence or insights become 
> available, people
> may have a different opinion at a later date, making this 
> document obsolete.
> Participants in this discussion, alphabetical by first name, include:
> Alan Karp            (alan_karp@hp.com)
> Ben Laurie           (ben@algroup.co.uk)
> Bill Frantz           (frantz@communities.com)
> David Wagner      (daw@mozart.cs.berkeley.edu)
> Hal Finney           (hal@finney.org)
> Jonathan Shapiro (shap@cs.jhu.edu)
> Ka-Ping Yee        (ping@lfw.org)
> Marc Stiegler       (marcs@skyhunter.com)
> Mark Miller          (markm@caplet.com)
> Norm Hardy         (norm@cap-lore.com)
> Nikita Borisov      (nikitab@cs.berkeley.edu)
> Ralph Hartley      (hartley@aic.nrl.navy.mil)
> Tyler Close         (tclose@oilspace.com)
> _______________________________________________
> e-lang mailing list
> e-lang@mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang