Erights - User contributions [en]

Ambient authority

2009-06-12T06:16:57Z

Daw: The last paragraph was thoroughly confusing

== Draft Definition ==

A [[subject]] may have several different [[permission]]s. '''Ambient authority''' is authority that can be used without having to identify which specific permission is intended. In an ambient authority system, when a subject requests an action (typically by naming an object and an operation on that object), the action is allowed if the subject has any permission that would allow the action.a

In contrast, in a designated authority system, a subject explicitly identifies a subset (usually one) of its permissions, and the action is allowed only if permitted by that subset of permissions.

In an ambient authority system, a subject making a request does not specify which permission to use -- the subject does not identify which permission is claimed to justify allowing the request. Instead, the system looks through all of the subject's permissions and allows the request if any of the subject's permissions would justify allowing the request.

In an ambient authority system, a subject may have many permissions, and there is often no way for the subject to single one of these out. As a result, in these systems, developers may not think of the subject as having multiple different permissions at once; instead, developers might just associate the union of all those permissions with the subject, and call them ''the'' permissions of the subject.

== Examples of ambient authority ==

All UNIX processes run by some user have ''ambient authority'' to manipulate all files owned by that user.

All UNIX processes have ''ambient authority'' to listen to TCP or UDP ports 1024--65535.

All UNIX processes have ''ambient authority'' to send any signal to any other UNIX process.

== Acknowledgement ==

The term ''ambient authority'' was coined by Dean Tribble and Mark S. Miller.

Ambient authority

2009-06-12T06:10:51Z

Daw: Add further explanation, derived from a comment by Alan Karp

== Draft Definition ==

A [[subject]] may have several different [[permission]]s. '''Ambient authority''' is authority that can be used without having to identify which specific permission is intended. In an ambient authority system, when a subject requests an action (typically by naming an object and an operation on that object), the action is allowed if the subject has any permission that would allow the action.a

In contrast, in a designated authority system, a subject explicitly identifies a subset (usually one) of its permissions, and the action is allowed only if permitted by that subset of permissions.

In an ambient authority system, a subject making a request does not specify which permission to use -- the subject does not identify which permission is claimed to justify allowing the request. Instead, the system looks through all of the subject's permissions and allows the request if any of the subject's permissions would justify allowing the request.

In an ambient authority system, often there is no way to identify a specific permission, so there is no concept of having different permissions.

== Examples of ambient authority ==

All UNIX processes run by some user have ''ambient authority'' to manipulate all files owned by that user.

All UNIX processes have ''ambient authority'' to listen to TCP or UDP ports 1024--65535.

All UNIX processes have ''ambient authority'' to send any signal to any other UNIX process.

== Acknowledgement ==

The term ''ambient authority'' was coined by Dean Tribble and Mark S. Miller.

Ambient authority

2009-06-12T06:10:16Z

Daw: Clarify first definition

Object-Capability patterns

2008-03-31T01:07:59Z

Daw:

This page contains information about common object-capability patterns that have appeared in a number of different object-capability systems.

'''TBD: Powerbox, Attenuating Facets / Forwaders, Logging Forwarders

{| border="1"
|+ An Historical Overview
! Pattern !! First Described In !! Appears In
|-
| Sealer-Unsealers || James H. Morris, Jr. Protection in Programming Languages. ''Communications of the ACM'', 16(1):15–21, 1973. || Gedanken, E, KeyKOS, Emily, Caja, Joule, Joe-E
|-
| Trademarks || James H. Morris, Jr. Protection in Programming Languages. ''Communications of the ACM'', 16(1):15–21, 1973. || Gedanken, E, KeyKOS
|-
| RevocableForwarder|| David D. Redell. ''Naming and Protection in Extensible Operating Systems''. PhD thesis, Department of Computer Science, University of California at Berkeley, November 1974. || E, KeyKOS, Emily
|-
| Coercers || E. Dean Tribble, Mark S. Miller, Norm Hardy, and David Krieger. ''[http://www.erights.org/history/joule/index.html Joule: Distributed Application Foundations]''. Technical Report ADd03.4P, Agorics Inc., Los Altos, December 1995. || Joule, E
|-
| Membranes || J. E. Donnelley. [http://www.webstart.com/jed/papers/DCCS/ A Distributed Capability Computing System], ''Proc. of the Third International Conference on Computer Communication'', pp. 432-440, 1976. || E, DCCS, KeyKOS, Emily, Joe-E/Waterken (? in the form of the Horton pattern)
|}

Documentation

2008-03-31T00:46:15Z

Daw: /* Talks and Presentations */

== Books and Theses ==

[http://www.evoluware.eu/fsp_thesis.pdf Patterns of Safe Collaboration]

[http://gonzo.uni-weimar.de/~scheffl2/Diploma_MScheffler.pdf Object-Capability Security in Virtual Environments]

[[Image:Ewalnut-pink.gif]]
[[Walnut|'''''E''''' in a Walnut]] - This is a basic tutorial on the '''''E''''' language covering basic, distributed, and secure distributed programming.

[http://www.erights.org/talks/thesis/index.html Robust Composition] - Towards a Unified Approach to Access Control and Concurrency Control. This is [[User:MarkM|Mark Miller]]'s PhD disseration, and it explains the rationale, philosophy, and goals of '''''E''''' and related systems.

[[Safe Serialization Under Mutual Suspicion]] (Wiki conversion in progress)

== Tutorials ==

[http://www.erights.org/elang/intro/index.html Tutorials] - several short tutorials showing how to use '''''E'''''.

[http://www.erights.org/elang/quick-ref.html Quick Reference Card] - Reminders of some useful patterns.

[[FAQ]]

== Papers ==

[http://www.erights.org/elib/capability/ode/index.html Capability-based Financial Instruments] "An Ode to the [[wikipedia:Mark Granovetter|Granovetter]] Diagram" - diagramming communication relationships.

[http://www.hpl.hp.com/techreports/2003/HPL-2003-222.html Paradigm Regained: Abstraction Mechanisms for Access Control] by Mark S. Miller and Jonathan S. Shapiro.

[http://www.erights.org/talks/promises/paper/tgc05.pdf Concurrency Among Strangers: Programming in '''''E''''' as Plan Coordination] - by Mark S. Miller, E. Dean Tribble, Jonathan Shapiro. Explains '''''E''''''s concurrency control & distributed computing model.

[http://web.comlab.ox.ac.uk/oucl/work/toby.murray/papers/AALPE.pdf Authority Analysis for Least Privilege Environments] by Toby Murray and Gavin Lowe.

[http://www.erights.org/elang/tools/causeway/causeway-paper.pdf Causeway: A message-oriented distributed debugger] by Terry Stanley, E. Dean Tribble, and Mark S. Miller.

== Talks and Presentations ==

[http://youtube.com/watch?v=apVt7vhBqj0 Caja] by Mike Samuel

[http://www.youtube.com/watch?v=gGw09RZjQf8 The Lively Kernel] by Dan Ingalls

[http://www.youtube.com/watch?v=EGX2I31OhBE Object-Capabilities for Security] by David Wagner
([http://www.cs.berkeley.edu/~daw/talks/TRUST07.pdf slides from an earlier version of this talk])

[http://www.youtube.com/watch?v=V13wmj88Zx8 Gears and the Mashup Problem] by Douglas Crockford

[http://www.youtube.com/watch?v=vrbmMPlCp3U Desktops to Donuts: Object-Caps Across Scales] by Marc Stiegler

[http://www.youtube.com/watch?v=8aedCggam4s Core Patterns for Web Permissions] by Tyler Close

[http://www.youtube.com/watch?v=oE3x_gM3YFU Paradigm Regained: Abstraction Mechanisms for Access Control] by Mark Miller

[http://www.youtube.com/watch?v=UH66YrzT-_M The Virus Safe Computing Initiative at HP Labs] by Alan Karp