Talk:Capability-based security

From Wikipedia, the free encyclopedia

Moved from Talk:Capability (computers) JDR

Might be a good idea, I have been staring at the capabilities page for 10 minutes and I still cannot see where it says what a capability is, looking at the other page...

Ok much better, defined in the first line no less !! I am for the merger.

--John van v 23:46, 22 August 2005 (UTC)

I agree with John , the passwd example in the page on capability-based security is crucial to understanding what capabilities are, a merge should be performed.

The equivalence "Capabilities (keys)" needs to be removed. It is a common, but problematic, mistake to equate capabilities with keys. Both a capability and a key carry authority to access a resource, but only a capability designates which resource it accesses. (Likewise, both a capability and a name designate a resource, but only a capability carries the authority to access the thing designated.) See "Capability Myths Demolished" which compares and constrasts keys with capabilities (as well as with ACLs, Unix file descriptors, and more). A very good external reference would be "Paradigm Regained" by Mark Miller and Jonathan Shapiro. What other page were you guys talking about? --zooko@zooko.com

Contents

[edit] Strong vs. weak capabilities

The article should have a discussion of the difference between strong and weak capability systems.

I agree, but they should be called "protected" and "unprotected" capability systems respectively. --DavidHopwood 18:36, 30 July 2007 (UTC)

Here are some notes:

[edit] Unprotected capabilities

In an unprotected capability system, holding a capability is equivalent to knowing a piece of data, which is a valid representation of the capability across multiple protection domains. This is usually implemented by choosing valid representations from a sparse namespace, either randomly (these representations are sometimes known as swiss numbers) or as the output of a cryptographic algorithm.

A swiss number is typically paired with a public key that identifies the machine serving the capability. (See "httpsy:" YURLs.)

Unprotected capabilities are easier to implement in decentralised systems that operate across a network.

Problems with unprotected capabilities:

  • They can be leaked over a covert channel.
  • Giving a process the ability to make requests of unprotected capabilities means that the process cannot be confined.
  • You must be careful about disclosing memory dumps of processes using unprotected capabilities, since the capability representations would be usable by others.

Advantages:

  • Unprotected capabilities can be stored in files, sent to other people in e-mails, etc.
  • The representation of an unprotected capability does not need to be changed when it is transferred.

Examples:

  • Unprotected capabilities are used in Amoeba.
  • "cap:" URLs in E.

Unprotected capabilities are also known as password capabilities. (You know the password you get access to the object password refers to) Zarutian (talk) 00:48, 14 March 2008 (UTC)

[edit] Protected capabilities

A protected capability system does not rely on unguessability of names; namespaces do not need to be sparse. A process is not given the opportunity to guess names.

With OS-based capability security, a process typically references capabilities via a C-list. The program manipulates indexes into the C-list, which are usually small integers.

With language-based capability security, this level of indirection is not present — it is an implementation detail. (However, one could regard variable names as C-list indexes, and environments as C-lists.)

A protected capability system is usually centralised (although it is possible to implement such a system in a decentralized way using cryptography, provided that capability representations are different across domains). In that case requests are made through some mediating entity that is relied upon for enforcing security (part of a TCB). This can be the OS kernel or the language implementation.

Examples:

[edit] Combining the two

Systems can combine protected and unprotected capabilities. E programs usually deal with protected capabilities. However, it is possible to convert a protected capability to an unprotected one (a "Sturdy Ref" or its representation as a "cap:" or "httpsy:" URL). The ability to do this is restricted (by requiring access to an "introducer" object), since being able to freely convert between the two capability types would introduce all the security weaknesses of unprotected capabilities for programs on each machine, where these weaknesses are unnecessary.

The c2.com wiki has a good page:

http://c2.com/cgi/wiki?CapabilityOrientedProgramming

It includes a contrast between Capability Oriented Programming and Object Oriented Programming, which is probably helpful for OO programmers to understand capabilities.

[edit] persistant vs unforgetable

... I can forget anything!

I think you mean persistent. —The preceding unsigned comment was added by 67.42.91.229 (talk) 01:40, 2 May 2007 (UTC).

[edit] This is totally hosed due to merging unrelated articles

The article on capability-based architectures/addressing that was originally written about Plessey System 250, System/38, et al, was apparently merged with the capability-based security article which is discussing something that is, while conceptually related, quite different in features and details.

They're not just conceptually related: capability-based addressing is nothing more than an implementation of capability-based security. The articles should be re-merged. --DavidHopwood 18:14, 30 July 2007 (UTC)

I don't know if the two articles should be split apart again or if this one should just be wordsmithed to make the two distinct concepts more obviously distinct. —The preceding unsigned comment was added by Danhicks (talk • contribs) 23:58, 5 May 2007 (UTC).

drh 23:59, 5 May 2007 (UTC)

[edit] Object-capability_model Merger Discussion

The Capability-based_security and Object-capability_model pages are very similar and seem to share the same primary topic: "Capability". Fatespeaks 14:16, 11 July 2007 (UTC)

Capability-based security is a broader term; not all capability systems conform to the object capability model, and the latter has its own terminology. These articles should not be merged (although they should reference each other). --DavidHopwood 18:16, 30 July 2007 (UTC)
I would oppose this move as well, on the grounds that Capability-based security is the more commonly used term; I know I saw it much more often than object-whatever. Eg. "capability-based+security"+-wiki&btnG=Search "capability-based security" -wiki vs "object-capability+model"+-wiki&btnG=Search "object-capability model" -wiki. --Gwern (contribs) 18:14 14 March 2008 (GMT)