Talk:Object-capability model

To do

To do:

• Add etymology to introduction [done 2007-01-06T22:38]
  • The name comes from recognition of the fact that "pure" object-oriented programming constitutes the capability-based security model. [done 2007-01-06T22:38]
  • Touted advantages of objects (encapsulation, modularity) are precisely what we want for security (privilege separation, least privilege). [done 2007-01-06T22:38]

• Section: Advantages of object-capabilities
  • No such thing as ambient authority (explain what that is)
  • Only connectivity begets connectivity
  • Show the Granovetter diagram!
  • No fixed set of operations (read, write, etc.); everything is invocation
  • Section: Combining designation and authority
    • Solving Confused Deputy

• Section: Relationship to object-oriented programming
  • references are called "pointers" Pointers often imply pointer artimetric which is forbidden in object capabilities systems. Also Java documentation uses the word reference instead of pointer --Zarutian (talk) 03:20, 10 September 2008 (UTC)

• Section: Relationship to capability-based security
  • references are called "capabilities"
  • the term "capability"
  • object-capabilities versus password capabilities
  • explain distinctions as in Capability Myths Demolished

• Possible section: relationship to lambda calculus?

— Ka-Ping Yee 08:26, 6 January 2007 (UTC)

A few additional topics

• Synergy (can + can opener => contents)
• sealers/unsealers
• factory pattern
• membrane pattern (probably doesn't belong on front page) Would require introduction to revocable forwarders --Zarutian (talk) 03:24, 10 September 2008 (UTC)
• other systems to mention:
  • Joule [added 2007-01-06T22:38]
  • KeyKOS [added 2007-01-06T22:38]
  • Coyotos

— Dean Tribble 18:47, 6 January 2007 (UTC)

Concrete example

So far this page is pretty abstract. I think the first subsection after the introduction should give a practical example. — Ka-Ping Yee 23:59, 6 January 2007 (UTC)

A request from Mark Miller (erights)

A request from Mark Miller (erights):

• This article has suffered some from reversion wars, where some anonymous contributors revert some editorial revisions of other anonymous contributors, back and forth. I have done this myself. So that discussion can replace further reversion wars, I ask that all potentially controversial edits to this article be done after logging in, so disagreements can be more directly discussed. Hereafter, I will do so as well.
• Question: Is there any way to put a wikipedia article into a state where such login is required in order to edit? --Mark S. Miller (talk) 07:54, 6 July 2009 (UTC)

Addresses versus References Controversy

The text below was deleted by a wikepdia editor

There is a controversy as to whether to use the terminology "address" or "reference" for the capability to send a message to an Actor/Object/Resource. The following arguments have been made in favor of using "address":

• Address is a term that has been traditionally been used for providing the capability to deliver a message as in "network address" and "email address".
• The memory address an Actor/Object can be used to invoke it. Such memory addresses can be protected against forgery by the use of tagged architecture and by the use virtual machines such as Java Virtual Machine and Common Language Runtime.

The following arguments have been made in favor of using "reference":

• Reference is a term that has been used in some programming languages for a value that enables a program to directly access the particular data item, such as a variable or a record, in the computer's memory (e.g. "ref" in Algol 68 and "&" in C and C++). The reference is said to refer to the data item, and accessing that data is called dereferencing the reference.
• References in some programming languages cannot be synthesized or forged. For example pointer arithmetic is sometimes not allowed on references. Also, in some programming languages (e.g. Algol 68 but not C and C++) integers cannot be converted into references.

Both "addresses" and "references" have some limitations:

• Addresses need to be distinguished between those that are just plain text like "billg@microsoft.com" and those that are unforgeable (unguessable) Actor addresses. A text address like "billg@microsoft.com" does not by itself provide the means to send a message: the internet address of a mail server is needed in addition. Also Actor addresses need to be distinguished from addresses on current stock hardware (e.g. X86) that allow reading, writing, and executing the contents at the memory address.

• References need to be distinguished between those in current programming languages that typically allow assignment to change what is referenced and the newer invokable-only references discussed in this article that can be used only to send messages.

It seems to me that the argument above for the use of "address" is preferable to the one for "reference."--171.66.82.181 (talk) 16:50, 6 July 2009 (UTC)

Both a (typically unguessable) address and (often unguessable) message are necessary but not sufficient to perform an operation

The following was deleted from the article:

It is important to note that both the address and message are required. Having just an address may not be sufficient because the sender may not be able to construct a workable message. Likewise, having just a message may not be sufficient because it may not be possible to construct an address that will work. For example, a web-key may be needed. Also the Actor at an address that receives a message retains the ability to decide what to do.

The above material has important information that should be restored.--171.66.82.181 (talk) 17:58, 6 July 2009 (UTC)

Relationship of the Object-capability model and the Actor model

Below is some material that can be used in explaining the relationship of Object-capability model and the Actor model:

Most of the object-capability model was first formalized as the Actor model of concurrent computation. However, there are some differences including the following:

• The Actor model prefers to use the terminology "address" for where to send a message instead of the term "reference" which has been preferred by some object-capability researchers.

• Being readily applicable to cloud computing (where unforgeable references cannot be implemented), the Actor model allows the use of unguessable addresses interchangeably with local computer unforgeable references. (For the purposes of the Laws for Actors, if any information about an unguessable address is leaked, then the whole address is leaked.) Because the Actor Model allows this use of unguessable address, it is not an Object Capability model. Conversely, because the Object Capability Model does not allow this use of unguessable addresses, it is not an Actor Model.

• Object-capability systems differ from the Actor model as follows:

• concurrency: The Actor Model uses message passing for all aspects of concurrency so that the thread pools, locks, queues, cores, etc. used in its implementation are not exposed.
• storage management: The Actor Model assumes real-time garbage collection of all Actors (preferably with no pauses) including futures.
• eq: The Actor Model allows testing two Actor addresses (perhaps obtained from different sources) to determine if they are the same.
• typing: The Actor Model allows the implementation of programming languages that allow optional typing, e.g., ActorScript.
• primitiveness of messages: The Actor model allows (binary) XML and JSON to be used as primitive messages.
• ordering of message arrival: The Actor model posits an arrival order on messages sent to a serialized Actor.

• The Actor model requires that loaders, evaluators, etc. obey the laws for Actors. On the other hand, the object-capability model requires a loader (eval, exec) having the property of _loader isolation_. A loader loads data describing behavior (code, script, lambda expression) together with an initial state (c-list, environment, instance variable frame, acquaintances) to create a new object. A loader obeys _loader isolation_ if the new object's only initial references are from the explicitly provided state, with no implicit grants by the loader itself. The Java ClassLoader violates loader isolation, making confinement of unexamined loaded code impossible.

--171.66.85.160 (talk) 20:56, 6 July 2009 (UTC)

^^^^ Spam by a well-known spammer banned years ago by ArbCom. It's doubtful the section even belongs here, unless WP:SECONDARY (non-Hewitt) sources actually discuss the relation between the two. For now, I've removed the outlandish claims the o-c model was based on the Actor model, when it preceded it by almost a decade. Someone not using his real name (talk) 17:26, 21 December 2013 (UTC)

^^^^^ Strange message as said Internet Protocol version 4 address belongs to Stanford Univeristy and has most likely been reassigned to someone else, special if that time period is taken into account. Obj-cap model isnt based on the Actor model as the latter came into being much later. More likely is that the Actor model was somewhat influenced by what we now call obj-cap model rahter than the other way around. (Specially the question if 'names' in Actor model are protected or not.) Zarutian (talk) 02:45, 1 January 2014 (UTC)

Merge proposals

I support a merge of both this page (Object-capability model) and Capability-based security with the RBAC article, which appears to be more abstract/theoretical/clean in its description. RBAC could benefit from the implmentation list here. prat (talk) 22:57, 6 December 2015 (UTC)

These are not the same and should not be merged. — Preceding unsigned comment added by 82.72.139.118 (talk) 23:20, 6 December 2015 (UTC)

Care to explain your reasoning? prat (talk) 23:29, 6 December 2015 (UTC)

Please see http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf, which describes in detail how capability-based security differs from identity-based access control mechanisms. RBAC is a mechanism for managing the mapping from identities to permissions; it is still identity-based, which makes it fundamentally different from capability-based security. Kenton Varda (talk) 01:03, 7 December 2015 (UTC)

I agree - RBAC is a different concept - the 2 should not be merged.--108.49.201.87 (talk) 02:05, 8 December 2015 (UTC)

No, they should not be merged, as they are very different concepts. Here are some of the significant differences:

- Roles are sets of permissions that are nearly always structured in a hierarchy. Capabilities, or keys, are not hierarchical.

- Capabilities/keys are exchanged between subjects/user programs to allow access. Roles explicitly cannot be passed from one program to another. Indeed doing so would break the RBAC model (except from the administrative program in setting up).

- RBAC allows for constraints such as mutual exclusion between roles, i.e., if a user has one role they are prohibited from another role. More general constraints can be specified as well.

- Capabilities are generally at the operating system level. Roles are generally at the application level because they are designed to reflect the permissions needed by users in various roles or positions in an organization. 108.18.237.135 (talk) 14:14, 8 January 2016 (UTC)

These should not be merged. They are different approaches to security. Pasado (talk) 02:11, 3 March 2016 (UTC)

VIPv6 (talk) 19:04, 2 April 2016 (UTC)NO, RBAC should not be merged with Object-Based Model or Capability-based model. Quoted text is from the on-topic Wikipedia articles:

"object-capability model is a computer security model"

"Capability-based security is a concept in the design of secure computing systems"

"Role-Based-Access-Control (RBAC) is a policy neutral access control mechanism"

Object-capability model and Capability-based security are concepts. RBAC is an implementation (at least two products are available: ).

"RBAC is sometimes referred to as role-based security." Role-based security might be considered a concept. As such, it could be included in an article that merges object-capability model and capability-based security. But, RBAC is a commonly used implementation of such a concept. As such, it should not be merged with the other concepts.VIPv6 (talk) 19:04, 2 April 2016 (UTC)

Disagree, sorry. "role-based access control ... is an approach to restricting system access to authorized users." It is used in various types of software and with various techniques. Different from this, this article "describes a transferable right to perform one (or more) operations on a given object". An object is not a role, and the two subjects are different in conceptual, systematic and practical perspective. Then again, Capability-based security is a special software technique that may or may not use one of the other two techniques. So it really makes sense to have different WP articles for these three topics. Or, if we imagine one article comprising them all, we would happily separate them. --Bernd.Brincken (talk) 10:46, 20 January 2017 (UTC)

Merge proposal declined

After reading through the comments, there was no support for the proposal to merge the articles, but several arguments against. So we can close this proposal and remove the template from the three articles. --Bernd.Brincken (talk) 10:51, 20 January 2017 (UTC)

---

References