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
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
|
Rainbow: Designing an Isolation Shell for Bitfrost
==================================================
:Author
Michael Stone
michael@laptop.org
:Acknowledgments
Ivan Krstić, Noah Kantrowitz, Michael Burns, Bernardo Innocenti, Reynaldo
Verdejo, Mitch Bradley (OLPC), James Cameron (Hewlett-Packard), Dave
Woodhouse (Red Hat), Herbert Pötzl (Linux-VServer), Marcus Leech (Nortel),
and Harry George (Boeing), all contributed to the design proposed in this
this document.
Steve Bellovin (Columbia), Daniel J. Bernstein (UIC), Eric S. Raymond, and
the Plan 9 security team (Russ Cox, Eric Grosse, Rob Pike, Dave Presotto,
and Sean Quinlan) all designed or documented software which inspired this
proposal.
:Metadata
Revision: Draft-1 - release 1
Timestamp: Fri Oct 26 18:50:00 UTC 2007
Feedback URL: http://mailman.laptop.org/mailman/listinfo/security
Authoritative version of this document: http://wiki.laptop.org/go/Rainbow
We welcome feedback on this document, preferably to the public OLPC
security mailing list, for which you can sign up at the feedback URL given
above. If you strongly prefer to keep your comments private, you may mail
the author of the document at the provided e-mail address.
This is NOT the final version of the design. The contents of this document
accurately reflect OLPC's thinking about security at the time of writing,
but certain aspects of the security model may change before production.
This document will be updated to reflect any such changes. The latest
version of this document may be found at the authoritative version URL.
1. Foreword
-----------
In early 2007, Ivan Krstić wrote that:
"The 1971 version of UNIX supported the following security permissions on
user files... what's deeply troubling... [is that] a user can choose
to protect her files from other people on the system, but has no control
whatsoever over what her own programs are able to do with her files."
He further wrote that "the crux of the problem lies in the assumption that any
program executing on a system on the user's behalf should have the exact same
abilities and permissions as any other program executing on behalf of the same
user."
The task of implementing the security vision described in Bitfrost therefore
devolves into (among others) the task of implementing an "isolation shell" -
i.e. a shell that is capable of isolating programs running on the user's
behalf from the full authority vested in that user.
2. Isolation Mechanisms
-----------------------
There are two basic mechanisms for implementing isolation - namespaces and
access checks. Namespace-derived isolation operates on the principle that
agents are unable to manipulate resources that they cannot name. Access checks
are simply attempts to discharge proof obligations of the form "agent A can
manipulate resource R by method M". (While the proof obligations do not
usually refer to other obligations, the assertions made by the system about
the processes, resources, and methods in question are frequently
higher-order.)
Unix systems use both of these mechanisms to isolate agents (groups of
processes) from named resources (memory pages, files, network interfaces,
audio and video devices, other processes) that can be manipulated by several
means including, most prominently, reading from them and writing to them.
Its fundamental vehicle for both namespace isolation and access-control is the
filesystem, wherein name visibility is controlled by both chroot() and
directory read/execute bits, where the authority requirements that access
control checks are recorded in tags attached to names, and where the authority
to satisfy those access control checks is vested primarily in "user ids".
3. An Isolation Shell
---------------------
Claim: Every protection described in Bitfrost §8 (excerpted below) can be
implemented by a shell which generates a new uid for each privilege boundary
it is asked to enforce.
Justification:
8.1. P_BIOS_CORE: core BIOS protection
8.2. P_BIOS_COPY: secondary BIOS protection
Pre-kernel protections.
8.3. P_SF_CORE: core system file protection
Can be implemented by standard Unix file permissions and a mandatory
request for the root password.
8.4. P_SF_RUN: running system file protection
Can be implemented via a snapshotting filesystem (perhaps implemented on
top of a CoW link primitive) or via unionfs.
8.5. P_NET: network policy protection
Can be implemented with the "OWNER" netfilter match extension.
8.6. P_NAND_RL: NAND write/erase protection
8.7. P_NAND_QUOTA: NAND quota
These require upstream support in JFFS2 regardless of which privilege
delimiter is chosen.
8.8. P_MIC_CAM: microphone and camera protection
These require upstream support, either in the IO subsystem (to close
specified file descriptors) or in the camera and microphone drivers (to
add a per-user/container on/off switch.)
8.9. P_CPU_RL: CPU rate limiting
This can be hacked together with cputime limits and a stateful daemon or
by patching the scheduler (as VServer does).
8.10. P_RTC: real time clock protection
This can be implemented by protecting kernel memory and root.
8.11. P_DSP_BG: background sound permission
This could be implemented in-driver or by directing all audio through a
mixer.
8.12. P_X: X window system protection
I believe but have not confirmed that XACE will be able to enforce
authorization decisions made on a per-user basis.
8.13. P_IDENT: identity service
This is unaffected by privilege separation.
8.14. P_SANDBOX: program jails
This can be implemented either by being very careful with filesystem
permissions or with hardened chroots.
8.15. P_DOCUMENT: file store service
8.16. P_DOCUMENT_RO: file store scanning
This can be implemented by gating directory listing and traversal on a
directory containing the stored documents. Stored documents can be made
available to running activities either with hardlinks or bindmounts.
8.17. P_DOCUMENT_RL: file store rate limiting
8.18. P_DOCUMENT_BACKUP: file store backup service
8.19. P_THEFT: anti-theft protection
8.20. P_SERVER_AUTH: transparent strong authentication to trusted server
8.21. (For later implementation) P_PASSWORD: password protection
All these permissions are unaffected by the privilege separation
mechanism.
4. Conclusion
-------------
A shell that, on human direction, isolates programs in the ways described by
Bitfrost can be implemented solely on top of standard Unix permissions by
carefully designing the permissions recorded in the initial filesystem, by
controlling access to root's authority, and by inserting several uid/gid-based
access checks in systems that currently lack them.
|
