Talk:Capability-based security

Moved from Talk:Capability (computers)

 * 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

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:

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)

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 &mdash; 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:
 * Capabilities in KeyKOS and EROS
 * Unix file descriptors
 * Plash (which layers a capability-based object invocation protocol on top of Unix file descriptors)
 * Object references in capability-secure programming languages such as E

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.

References req every sentence ?
I think the edits between ~12 and 17th of july 2007 http://en.wikipedia.org/w/index.php?title=Capability-based_security&diff=145659178&oldid=144132203 (by BMF81) pertaining to adding a need for reference at almost every sentence of a well contained and systematically "flowing" paragraph looks a bit dubious to me. It's almost like asking a reference for saying something like "A computing machine needs some form of physical memory storage to hold the logical state representation of higher abstractions." This is at the base of the domain of knowledge (eg for my previous example, a ref to an intro textbook on computer architecture could be provided, but you can say that for every general info of all articles) and likewise, this paragraph seems self eloquent and logically flowing to me (?).

For example, indeed, the specs of file descriptors don't specify that those come supported with persistence. And without it, the assumed capability functionality is broken accross execution start/stop cycles, and thus, you're back to using ACL to grab back from the kernel an OS protected ref+access right data structure. (But we wanted to avoid ACL by assigning caps to entities from the start - hence the "obstacle to full benefits" allusion) The rest of the paragraph flows nicely from that.

I guess what I'm saying is, maybe you're (BMF81) trying to bring out subtilities not obvious from that paragraph, things that could be missed, if so, please comment on them, and if not, maybe these tags should be removed...

ps: good points that should be included on "protected" and "unprotected" caps. 70.81.15.136 (talk) 08:29, 18 June 2008 (UTC)

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).

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)

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 vs "object-capability model" -wiki. --Gwern (contribs) 18:14 14 March 2008 (GMT)


 * I would oppose the merge too 70.81.15.136 (talk) 08:05, 18 June 2008 (UTC)


 * Mr. Hopwood is correct.

L4 Kernel capabilities?
Accordings to the L4-Page, L4-support for hurd was dropped, because it did not support capabilities. Are there versions that do? —Preceding unsigned comment added by 129.13.186.1 (talk) 11:22, 14 July 2008 (UTC)

TrustedBSD link?
I was wondering if it'd be worth mentioning TrustedBSD. It's currently mentioned in the Computer Security article under the Capabilities vs. ACLs section.

''TrustedBSD is an example of an open source project with a goal, among other things, of building capability functionality into the FreeBSD operating system. Much of the work is already done.''

Legios (talk) 03:21, 2 March 2009 (UTC)

TrustedBSD and the Posix capabilities/Capsicum skirmish belong over at Security-focused operating system. — Preceding unsigned comment added by 68.228.67.204 (talk) 18:09, 5 September 2014 (UTC)

Token
The term token is much used today, for example in OAuth. Is this capability-based security? --JWB (talk) 17:35, 24 May 2013 (UTC)

External links modified
Hello fellow Wikipedians,

I have just modified one external link on Capability-based security. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive https://web.archive.org/web/20031029002231/http://www.eros-os.org/ to http://www.eros-os.org/

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Cheers.— InternetArchiveBot  (Report bug) 10:25, 30 July 2017 (UTC)

External links modified
Hello fellow Wikipedians,

I have just modified 2 external links on Capability-based security. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive https://archive.is/20130112225523/http://www.eros-os.org/essays/capintro.html to http://www.eros-os.org/essays/capintro.html
 * Added archive https://archive.is/20130414162939/http://www.eros-os.org/pipermail/cap-talk/2003-March/001133.html to http://www.eros-os.org/pipermail/cap-talk/2003-March/001133.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Cheers.— InternetArchiveBot  (Report bug) 03:11, 14 December 2017 (UTC)