Erights - User contributions [en]

Talk:Object capability

Dmbarbour — Fri, 10 Jul 2009 21:23:38 GMT

Dmbarbour:

Are you sure, Dmbarbour?

May I suggest you
* first to read [http://www.erights.org/talks/thesis/ Mark Miller's thesis]
* then install E
* read E in a [[Walnut]] and experiment with E
If you like it, join e-lang or cap-talk mailing list and discuss your ideas.

[[User:Kosik|Kosik]] 15:17, 10 July 2009 (CDT)

I have read Mark Miller's thesis, many years ago. And I played with '''E language''' then, too. I've gained more than a few inspirations from these, but I'm not all that fond of the language (in particular, how it handles distribution, disruption, resilience, persistence, concurrency, consistency, facets, and I'm not impressed with available optimizations achievable).

Anyhow, I can only express my professional opinion on what [[object capability]] means based on the literature I have read, same as Mark Miller or anyone else, and take comfort in the fact that formal definitions are graded by '''utility in making distinctions''' rather than by their conformance with the opinions of others. You ask if I'm "sure"? I'm very certain of the utility in understanding [[object capability]] as distinct from other capabilities, and I'm very certain of the utility in understanding [[capability]] as distinct from '''secure''' capability, such that one can meaningfully discusss the security '''of''' capabilities rather than just security '''with''' capabilities. So, in that sense, I'm sure.
-- [[User:Dmbarbour|Dmbarbour]] 16:15, 10 July 2009 (CDT)

-------

Upon seeing you 'rewrite' my professional opinion on the matter with your own, it is clear to me that you would prefer to maintain and grow this wiki on your own rather than risk dissenting opinions. I'll leave you alone now. But, before I go, May I suggest that you read some capability literature that ''wasn't'' written by Mark Miller? There's a lot of it out there.
-- [[User:Dmbarbour|Dmbarbour]] 16:23, 10 July 2009 (CDT)

Talk:Object capability

Dmbarbour — Fri, 10 Jul 2009 21:23:22 GMT

Dmbarbour:

Talk:Object capability

Dmbarbour — Fri, 10 Jul 2009 21:15:29 GMT

Dmbarbour:

Are you sure, Dmbarbour?

May I suggest you
* first to read [http://www.erights.org/talks/thesis/ Mark Miller's thesis]
* then install E
* read E in a [[Walnut]] and experiment with E
If you like it, join e-lang or cap-talk mailing list and discuss your ideas.

[[User:Kosik|Kosik]] 15:17, 10 July 2009 (CDT)

''I have read Mark Miller's thesis, many years ago. And I played with '''E language''' then, too. I've gained more than a few inspirations from these, but I'm not all that fond of the language (in particular, how it handles distribution, disruption, resilience, persistence, concurrency, consistency, facets, and I'm not impressed with available optimizations achievable).''

''Anyhow, I can only express my professional opinion on what [[object capability]] means, same as Mark Miller or anyone else, and take comfort in the fact that formal definitions are graded by '''utility in making distinctions''' rather than by their conformance with the opinions of others. You ask if I'm "sure"? I'm very certain of the utility in understanding [[object capability]] as distinct from other capabilities, and I'm very certain of the utility in understanding [[capability]] as distinct from '''secure''' capability, such that one can meaningfully discusss the security '''of''' capabilities rather than just security '''with''' capabilities. So, in that sense, I'm sure.'' [[User:Dmbarbour|Dmbarbour]] 16:15, 10 July 2009 (CDT)

Talk:Object capability

Dmbarbour — Fri, 10 Jul 2009 21:15:08 GMT

Dmbarbour:

Are you sure, Dmbarbour?

May I suggest you
* first to read [http://www.erights.org/talks/thesis/ Mark Miller's thesis]
* then install E
* read E in a [[Walnut]] and experiment with E
If you like it, join e-lang or cap-talk mailing list and discuss your ideas.

[[User:Kosik|Kosik]] 15:17, 10 July 2009 (CDT)

''I have read Mark Miller's thesis, many years ago. And I played with '''E language''' then, too. I've gained more than a few inspirations from these, but I'm not all that fond of the language (in particular, how it handles distribution, disruption, resilience, persistence, concurrency, consistency, facets, and I'm not impressed with available optimizations achievable).''

''Anyhow, I can only express my professional opinion on what [[object capability]] means, same as Mark Miller or anyone else, and take comfort in the fact that formal definitions are graded by '''utility in making distinctions''' rather than by their conformance with the opinions of others. You ask if I'm "sure"? I'm very certain of the utility in understanding [[object capability]] as distinct from other capabilities, and I'm very certain of the utility in understanding [[capability]] as distinct from '''secure''' capability, such that one can meaningfully discusss the security '''of''' capabilities rather than just security '''with''' capabilities'''. So, in that sense, I'm sure.'' [[User:Dmbarbour|Dmbarbour]] 16:15, 10 July 2009 (CDT)

Talk:Capability

Dmbarbour — Fri, 10 Jul 2009 21:00:03 GMT

Dmbarbour:

The article can be further improved by given more examples of capabilities from CapROS, EROS and Coyotos systems. What objects can those capabilities designate? Which operations do those capabilities permit their holder to perform with designated objects? [[User:Kosik|Kosik]] 05:17, 10 July 2009 (CDT)

-------------

It seems the article describes an object-capability as though it is the only sort. I understand it is the type of capability used in E and such, but other sorts are used for security.
* Password Capabilities (SPKI, Certificates) do not need to designate objects
* Object Capabilities

Further, capability doesn't imply '''unforgeable''' unless you're talking about '''secure''' capabilities, and '''capability-based security'''.

----

You are right. Some capabilities are indeed unforgeable and some are merly ''hardly guessable''. Cannot these two different terms:
* unforgeable
* hardly unguessable
be contracted to some single adjective? Using the term "unforgeable or hardly unguessable" is awkward. [[User:Kosik|Kosik]] 10:59, 10 July 2009 (CDT)

''I'm afraid you didn't grok. I mean to say that capabilities may be very forgeable and guessable. They [the forgeable and guessable capabilities] simply aren't secure capabilities, or suitable for capability-based security. And the page still has a heavily '''object-'''capability bias.''

----

Concerning object-capability bias, see my suggestion at the top of the page. More example are needed and can be added. I am just not qualified to give them.

It is possible to demonstrate that if you say "capabilities are very forgeable and guessable" you are wrong.

[[User:Kosik|Kosik]] 11:51, 10 July 2009 (CDT)

----

''Please demonstrate, then. Demonstrate that "Capability" implies "Secure capability" in global vernacular and I'll be happy to recant. But I suspect you're not qualified to do that, either.''

----

Here is a [http://altair.fiit.stuba.sk/mediawiki/index.php/SandboxedPing non-trivial example]. You can try to explain me how it would be possible for an untrusted sandboxed subsystem to forge or guess arbitrary capabilities?

Similar examples can be also shown in any object-capability programming language one chooses to use. I may try to show some code in E with a similar point. I am not qualified to show any examples showing a similar point in capability-based operating systems but I think on cap-talk there are such people.

[[User:Kosik|Kosik]] 13:16, 10 July 2009 (CDT)

----

''You've got your logic backwards, Kosik. I'm asserting that not all capabilities are secure, not that all (and 'arbitrary') capabilities are insecure.''

----

What do you mean by "secure capability"?

[[User:Kosik|Kosik]] 14:55, 10 July 2009 (CDT)

''A secure capability is any power to perform an operation that is available to a system but unavailable (not merely forbidden) to a subject acting within that system.''

Talk:Capability

Dmbarbour — Fri, 10 Jul 2009 20:59:27 GMT

Dmbarbour:

Talk:Ambient capability

Dmbarbour — Fri, 10 Jul 2009 20:57:42 GMT

Dmbarbour:

I have never heard of this term. Why do we need it? Isn't the term [[ambient authority]] sufficient? Can you give some example of things you (the author) consider as an example of [[ambient capability]]? Are there some examples of ambient capabilities that are somehow different from ambient authority? [[User:Kosik|Kosik]] 01:19, 10 July 2009 (CDT)

----

[[Ambient authority]] doesn't apply '''unless''' permissions are enforced in denying an operation. The two are barely even related. Ambient authority is not sufficient or appropriate as terminology to properly discuss the circumstances surrounding distribution and mobility.

Consider an object that accesses the following:
* a keyboard
* a monitor
* current local time via a clock
* random number generator
* a HTTP cache
* a Domain Name Service
* a timer (10 Hz event)
* hooking into Data Distribution Service (a distributed publish/subscribe)
* local memory allocations (i.e. to allocate values)

These capabilities are ALL ambient, at least initially. Access to each of them is highly contingent on context. It takes much work to create a common namespace that would let one machine have access to the monitor or keyboard on another machine.

But consider:
* An object-capability system (OS or language) is likely to wrap access to the keyboard and monitor into objects with secure (unforgeable) designations. If the above object is mobilized, the keyboard and monitor objects designate the keyboard and monitor on the original host, thus causing messages to cross the network. That's the desired behavior... keyboard and monitor are reasonably 'unique' ambients (though one might transparently replace the keyboard or monitor), so fit reasonably well into the [[object capability]] system.
* Access to a clock, random number generator is more questionable. [[object-capability languages]] can go either way: allow access as new language primitives, in which case the 'current local time' is ambient to programs written in that language (and refers to the time on the host). Or wrap these into objects, in which case once object is mobilized it will need to send messages across the network for each request to the current local time. Sending requests for random numbers across the network is wasteful, at the very least. Accessing a clock across a network introduces variation in latency.
* access to HTTP cache and Domain Name Service across a network after mobilization is pointless, but also demonstrate that there's no feasible way for [[object-capability languages]] to possibly provide all the desired ambient capabilities AS object capabilities after a mobilization.
* Access to the 10 Hz event and DDS adds an extra challenges: having subscribed to these locally requires handing object-capabilities to other objects on the local system in order to subscribe and later unsubscribe. When mobilizing, however, having a 10 Hz event or DDS updates cross the network is problematic: those services can easily be provided locally for much higher performance, reliability, consistent latency, and quality of service. This suggests some first-class support for subscriptions (and later unsubscribe) to ambients is necessary to deal with certain distribution issues.
* Most [[object-capability languages]] simply make allocations from local memory into 'primitives' making them ambient to the program, but there is always talk of wrapping memory resources into capabilities in order to handle quotas and such. After a mobilization, the 'primitives' approach means that the object will allocate any new objects on the remote machine, whereas if memory is wrapped into quota caps then one will be allocating memory on its original host. This suggests, at the very least, that quotas need to be handled differently if object-capabilities are to be networked.

[[Object-capability languages]] + '''distribution or mobility''' benefits considerably from first-class support for [[ambient capability|ambient capabilities]]. But to discuss such possibilities requires that one first understand terminology such as [[ambient capability]].

Usefully, ambient capabilities - even 10 Hz events and DDS and HTTP cache and DNS - '''can''' be reified. But one needs to explicitly recognize such [[ambient capability|ambient capabilities]] as being distinct from [[object capability|object capabilities]].

----

May I choose single of your points? You say that access to a local time via a clock is an "ambient capability". This is false in case of [http://altair.fiit.stuba.sk/mediawiki/index.php/Tamed_Pict Tamed Pict]. Untrusted sandboxed subsystems do not have such an "ambient capability". What kind of "ambient capabilities" have untrusted sandboxed subsystems written in Tamed Pict? What kind of "ambient capabilities" do have untrusted sandboxed subsystems written in E?

Other points are also false but that is beyond the scope now until you show a single "ambient capability".

[[User:Kosik|Kosik]] 13:35, 10 July 2009 (CDT)

''I said that "local time via a clock is an [[ambient capability]], '''at least initially'''". I.e. at the hardware/OS/abstract-machine/LAN level. I then go on to explain options available to a secure capability-system (like a capability OS or [[object-capability languages]]) for securing these capabilities. Two options were explicitly mentioned:''
* wrap the [[ambient capability]] to the local time via a clock in an 'object' with a secure [[object capability]]. This has certain implications when comes time to mobilize objects (i.e. for load-balancing, disruption tolerance, etc.)
* or allow access to local time as a language primitive, which tends to add [[excessive authority]] to the language.

''There are many more options, of course. Infinitely many. Two more are:''
* One can create a 'major domo' object that provides a set of factories for certain local capabilities to 'guests', who must take advantage of them. The factories and the rest of the system is secure and thus provide a sandbox (up to primitive caps, such as memory allocation in many languages).
* One can reify the notion of an 'ambient', thus producing [[ambient object|ambient objects]] that have the same semantics everywhere but different implementations. One may then provide something similar to [[object capability]] to these reified ambients through factories rather than as language primitives, and these access to these ambients will implicitly follow objects as they are distributed.

''Tamed Pict just happens to choose one option among many: it uses the 'major domo' option to provide access to local time and various other features. The 'major domo' seems to be expressed by importing some 'trusted' modules, which provide those capabilities to the guest via automatic construction of various hooks. Unfortunately, this sandbox approach has many flaws for transparent distribution:''
* the provided [[capability]] isn't tuned to the guest, which means it provides [[excessive authority]] for some guests and [[insufficient authority]] for others
* if the major-domo doesn't provide a necessary capability, the guest cannot transparently continue using the remote capability to ensure the guest has the exact same capability before and after mobilization.
* active interactions with these ambients (e.g. subscriptions) are not maintained and must be rebuilt by the guest after each mobilization, pretty much utterly destroying transparency

''Transparent distribution, especially automatic distribution, especially of the first-class sort, is useful for: redundancy and self-healing, load-balancing, latency and bandwidth optimizations, improved quality-of-service, and disruption tolerance.

''[[ambient authority]] is not [[ambient capability]]. A secure [[ambient capability]] must not be denied or lost simply because one is mobilized to a new sandbox. [[ambient authority]] will 'grant' or 'deny' permissions. It is effectively expressed by granting a set of factories to the guest - the guest may only behave within the limits of those factories. By comparison [[ambient capability]] is effectively expressed by ensuring the guest has the exact same set of capabilities both before and after a mobilization - but only up to semantics, allowing (and sometimes requiring) for the guest to automatically take advantage of the local HTTP cache, local random number generator, local timers, etc. Unlike objects, '''ambients''' have poorly defined boundaries.''

Talk:Capability

Dmbarbour — Fri, 10 Jul 2009 19:07:07 GMT

Dmbarbour:

The article can be further improved by given more examples of capabilities from CapROS, EROS and Coyotos systems. What objects can those capabilities designate? Which operations do those capabilities permit their holder to perform with designated objects? [[User:Kosik|Kosik]] 05:17, 10 July 2009 (CDT)

-------------

It seems the article describes an object-capability as though it is the only sort. I understand it is the type of capability used in E and such, but other sorts are used for security.
* Password Capabilities (SPKI, Certificates) do not need to designate objects
* Object Capabilities

Further, capability doesn't imply '''unforgeable''' unless you're talking about '''secure''' capabilities, and '''capability-based security'''.

----

You are right. Some capabilities are indeed unforgeable and some are merly ''hardly guessable''. Cannot these two different terms:
* unforgeable
* hardly unguessable
be contracted to some single adjective? Using the term "unforgeable or hardly unguessable" is awkward. [[User:Kosik|Kosik]] 10:59, 10 July 2009 (CDT)

''I'm afraid you didn't grok. I mean to say that capabilities may be very forgeable and guessable. They [the forgeable and guessable capabilities] simply aren't secure capabilities, or suitable for capability-based security. And the page still has a heavily '''object-'''capability bias.''

----

Concerning object-capability bias, see my suggestion at the top of the page. More example are needed and can be added. I am just not qualified to give them.

It is possible to demonstrate that if you say "capabilities are very forgeable and guessable" you are wrong.

[[User:Kosik|Kosik]] 11:51, 10 July 2009 (CDT)

----

''Please demonstrate, then. Demonstrate that "Capability" implies "Secure capability" in global vernacular and I'll be happy to recant. But I suspect you're not qualified to do that, either.''

----

Here is a [http://altair.fiit.stuba.sk/mediawiki/index.php/SandboxedPing non-trivial example]. You can try to explain me how it would be possible for an untrusted sandboxed subsystem to forge or guess arbitrary capabilities?

Similar examples can be also shown in any object-capability programming language one chooses to use. I may try to show some code in E with a similar point. I am not qualified to show any examples showing a similar point in capability-based operating systems but I think on cap-talk there are such people.

[[User:Kosik|Kosik]] 13:16, 10 July 2009 (CDT)

''You've got your logic backwards, Kosik. I'm asserting that not all capabilities are secure, not that all (and 'arbitrary') capabilities are insecure.''

Talk:Capability

Dmbarbour — Fri, 10 Jul 2009 19:04:11 GMT

Dmbarbour:

The article can be further improved by given more examples of capabilities from CapROS, EROS and Coyotos systems. What objects can those capabilities designate? Which operations do those capabilities permit their holder to perform with designated objects? [[User:Kosik|Kosik]] 05:17, 10 July 2009 (CDT)

-------------

It seems the article describes an object-capability as though it is the only sort. I understand it is the type of capability used in E and such, but other sorts are used for security.
* Password Capabilities (SPKI, Certificates) do not need to designate objects
* Object Capabilities

Further, capability doesn't imply '''unforgeable''' unless you're talking about '''secure''' capabilities, and '''capability-based security'''.

----

You are right. Some capabilities are indeed unforgeable and some are merly ''hardly guessable''. Cannot these two different terms:
* unforgeable
* hardly unguessable
be contracted to some single adjective? Using the term "unforgeable or hardly unguessable" is awkward. [[User:Kosik|Kosik]] 10:59, 10 July 2009 (CDT)

''I'm afraid you didn't grok. I mean to say that capabilities may be very forgeable and guessable. They simply aren't secure capabilities, or suitable for capability-based security. And the page still has a heavily '''object-'''capability bias.''

----

Concerning object-capability bias, see my suggestion at the top of the page. More example are needed and can be added. I am just not qualified to give them.

It is possible to demonstrate that if you say "capabilities are very forgeable and guessable" you are wrong.

[[User:Kosik|Kosik]] 11:51, 10 July 2009 (CDT)

----

''Please demonstrate, then. Demonstrate that "Capability" implies "Secure capability" in global vernacular and I'll be happy to recant. But I suspect you're not qualified to do that, either.''

----

Here is a [http://altair.fiit.stuba.sk/mediawiki/index.php/SandboxedPing non-trivial example]. You can try to explain me how it would be possible for an untrusted sandboxed subsystem to forge or guess arbitrary capabilities?

Similar examples can be also shown in any object-capability programming language one chooses to use. I may try to show some code in E with a similar point. I am not qualified to show any examples showing a similar point in capability-based operating systems but I think on cap-talk there are such people.

[[User:Kosik|Kosik]] 13:16, 10 July 2009 (CDT)

''You've got your logic backwards, Kosik. I'm asserting that not all capabilities are secure, not that all (and 'arbitrary') capabilities are insecure.''

Talk:Ambient capability

Dmbarbour — Fri, 10 Jul 2009 18:15:24 GMT

Dmbarbour:

Talk:Capability

Dmbarbour — Fri, 10 Jul 2009 17:07:47 GMT

Dmbarbour:

Talk:Capability

Dmbarbour — Fri, 10 Jul 2009 16:23:20 GMT

Dmbarbour:

Talk:Capability

Dmbarbour — Fri, 10 Jul 2009 16:21:42 GMT

Dmbarbour:

Talk:Ambient capability

Dmbarbour — Fri, 10 Jul 2009 16:18:37 GMT

Dmbarbour:

Talk:Ambient capability

Dmbarbour — Fri, 10 Jul 2009 16:17:54 GMT

Dmbarbour:

Talk:Ambient capability

Dmbarbour — Fri, 10 Jul 2009 16:16:44 GMT

Dmbarbour:

Talk:Ambient capability

Dmbarbour — Fri, 10 Jul 2009 16:16:10 GMT

Dmbarbour:

Ambient capability

Dmbarbour — Thu, 09 Jul 2009 22:12:13 GMT

Dmbarbour:

Ambient capability describes constraint and provision of operations by virtue of [[context]]. The term is very useful in discussion of distribution and mobility of code and service components.

== Application ==

Ambient capability is applicable for many reasons. A few are:
* limitation of [[namespace|namespaces]]: namespaces are artificial constructs, and both [[secure naming]] and [[designation]] can occur only performed under the umbrella of an [[ambient authority]]. A designation querying a "keyboard" may have different meaning (i.e. applying to different physical keyboards) given different contexts.
* limitations on [[communication]]: even if a namespace is properly maintained, there inherently exist limitations over communications. Networks may be partitioned, connections disrupted. Temporal windows for send and receive might fail to match.
* [[primitive capability|primitive capabilities]]: any programming language will offer a set of ambient capabilities via its interpreter. Use of console IO, access to filesystem, ability to ask for the current time or a random number, consumption of CPU resources and memory, communications support, etc. are often ambient and ''usually'' offer [[excess authority]] in order to achieve some degree of flexibility.
* capabilities to ambient resources: at the edges of a useful programming language, one must interact with sensors and actuators. These objects are provided by an 'operating system' of some sort that will abstract devices in terms of data-flows, event-flows, and objects subject to command. To said operating system, the capabilities being accessed are inherently ambient.

On the last point, some security and optimization strategies are achieved by layering languages with different levels of ambient capability in each language layer both in order to avoid [[excess authority]] and support more optimization assumptions.

As with [[ambient authority]], it is HOW operations are constrained or provided that determines whether one is discussing an 'ambient' capability. However, one can very reasonably argue that ALL capabilities are, to some degree, 'ambient'. While this introduces some fuzziness, the term [[ambient capability]] can be utilized effectively when the ambient nature of a capability is very significant to achievement of engineering properties - such as distribution and mobility of code.

[[Object-capability languages]] aim to minimize the role of [[ambient capability]] in order to achieve certain forms of security.

== Relation to Ambient Authority ==

[[Ambient authority]] will '''allow''' or '''deny''' operations in accordance with a set of '''permissions''' that are provided within a [[context]]. A denial of an operation due to permissions is merely one mechanism by which ambient capability may be constrained.

However, allowance for an operation does not support or provide for that operation. You may easily be ''permitted'' to perform and command operations that you ''cannot'' perform due to [[context]].

Thus, [[ambient authority]] can be considered a ''limitation'' on [[ambient capability]].