1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
|
[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2013 Free Software
Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]
A capability is a protected reference. It is a reference in that
it designates an object; it is protected in that in cannot be
forged. A capability both designates the object it refers to and
carries the authority to manipulate it.
By binding [[designation]] and [[authorization]] together, capabilities
simplify [[delegation]]. Imagine that program instance A wants to
tell program B to use a particular file to store some data.
Further imagine that A and B are running in different [[trust_domains]]
(e.g., with different UIDs). If A sends B just the name
of the file, B needs to first ensure that he does not accidentally
enable A to access the file on his own authority. That is, B wants
to protect against A hijacking his authority. (This problem is
refused to the [[confused_deputy]] problem.) Also, since A likely
sent a string to identify the file to B, the identifier lacks a
[[naming_context]] and therefore may resolve to a different object
than A intended. By ensuring that [[designation]] and [[authorization]] are
always bound together, these problems are avoided.
Capability-based system architectures strive to meet the *principle of least
privilege* ({{$wikipedia_polp}}).
[[!tag open_issue_documentation]] <!--
Revoking capabilities: destroy Mach port, invalidates *all* send rights. See
shapiro_capintro_1999. To be more fine-grained, need separate instances, for
example, valet key vs. door key. Proxy objects (that can be destroyed
individually); attenuation design pattern, membranes
(wikipedia_object-capability_model)?
-->
A capability mechanism is typically implemented in software by the operating
system kernel (typically a [[microkernel]]). The computing cost (as compared to
a hardware implementation) is neglectable.
[[!tag open_issue_documentation]] <!--
References. shapiro_capintro_1999 has a bit.
-->
[[!tag open_issue_documentation]] <!--
# Advantages
* increased security; POLP
* easy exchanging of functionality
* support modular design and encapsulation
* easy collaboration (in theory; need real example)
-->
# UNIX
[[UNIX file descriptors|unix/file_descriptor]] can be viewed as capabilities.
They do not survive reboot, that is, they are not [[persistent|persistency]].
To work around this, [[ACL]]s are used to recover authority.
# GNU/Hurd
In the GNU/Hurd system, a capability is represented by a [[Mach
port|microkernel/mach/port]]. As in UNIX (see above), they are not
[[persistent|persistency]].
## IRC, freenode, #hurd, 2013-07-01
<nlightnfotis> I have read plenty of documents, and wrapped my head around
most Hurd concepts, but I still have not understood well what
capabilities are.
<youpi> Mmm, which capabilities?
<youpi> AIUI, the Hurd doesn't really have a notion of capabilites, just a
notion of owning a port right
<nlightnfotis> From what I have understood (from the critique) they
reference ports so they objects can be referenced via them
<youpi> (which provides processes a way for doing things)
<youpi> ok, so we are talking about the same thing, I guess
<nlightnfotis> ahh, that's cool. I thought there was more to the story that
I couldn't understand
# Further Reading
* [[Mach port|microkernel/mach/port]]
[[!toggleable id=shapiro_capintro_1999 text="""[[!template id=note
text="*[[shapiro\_capintro\_1999|capability]]*:
{{$capability#shapiro_capintro_1999}}.
{{$capability#shapiro_capintro_1999_text}}."]]"""]]
* [[!toggle id=shapiro_capintro_1999 text="[shapiro\_capintro\_1999]"]]
* {{$wikipedia_capability-based_security}}
* {{$wikipedia_object-capability_model}}
* {{$wikipedia_polp}}
[[!tag open_issue_documentation]] <!--
<http://www.eros-os.org/essays/wherefrom.html>,
<http://www.eros-os.org/essays/ACLSvCaps.html>,
<http://www.cap-lore.com/CapTheory/index.html>,
<http://www.cap-lore.com/CapTheory/tddCap.html>
<http://www.skyhunter.com/marcs/capabilityIntro/>
-->
[[!ymlfront data="""
shapiro_capintro_1999:
"[What *is* a Capability,
Anyway?](http://www.eros-os.org/essays/capintro.html), Jonathan Shapiro,
1999"
shapiro_capintro_1999_text:
"This is an easily readable introduction with good examples. In the author's
own words, the text *provides a layman's introduction to capabilities,
describing what they are, what they do, and why they result in better
security than today's computer systems*"
wikipedia_capability-based_security:
"[[!wikipedia Capability-based_security desc=\"Wikipedia, capability-based
security\"]]"
wikipedia_object-capability_model:
"[[!wikipedia Object-capability_model desc=\"Wikipedia, object-capability
model\"]]"
wikipedia_polp:
"[[!wikipedia Principle_of_least_privilege desc=\"Wikipedia, principle of
least privilege\"]]"
"""]]
|
