view tools/security/policy.txt @ 21067:b4a1832a916f

Update Xen version to 4.0.0-rc6
author Keir Fraser <>
date Tue Mar 09 18:18:05 2010 +0000 (2010-03-09)
parents 16f1f8ac8902
line source
1 ##
2 # policy.txt <description to the sHype/Xen access control architecture>
3 #
4 # Author:
5 # Reiner Sailer 08/30/2006 <>
6 #
7 #
8 # This file gives an overview of the example security policies.
9 ##
11 Example of a Chinese Wall Policy Instantiation
12 ----------------------------------------------
14 The file client_v1-security_policy.xml defines the Chinese Wall types
15 as well as the conflict sets for our example policy (you find it in
16 the directory "policy_root"/example/chwall).
18 It defines four Chinese Wall types (prefixed with cw_) with the
19 following meaning:
21 * cw_SystemsManagement is a type identifying workloads for systems
22 management, e.g., domain management, device management, or hypervisor
23 management.
25 * cw_Sensitive is identifying workloads that are critical to the user
26 for one reason or another.
28 * cw_Distrusted is identifying workloads a user does not have much
29 confidence in. E.g. a domain used for surfing in the internet without
30 protection( i.e., active-X, java, java-script, executing web content)
31 or for (Internet) Games should be typed this way.
33 * cw_Isolated is identifying workloads that are supposedly isolated by
34 use of the type enforcement policy (described below). For example, if
35 a user wants to donate cycles to seti@home, she can setup a separate
36 domain for a Boinc ( client, disable
37 this domain from accessing the hard drive and from communicating to
38 other local domains, and type it as cw_Isolated. We will look at a
39 specific example later.
41 The example policy uses the defined types to define one conflict set:
42 Protection1 = {cw_Sensitive, cw_Distrusted}. This conflict set tells
43 the hypervisor that once a domain typed as cw_Sensitive is running, a
44 domain typed as cw_Distrusted cannot run concurrently (and the other
45 way round). With this policy, a domain typed as cw_Isolated is allowed
46 to run simultaneously with domains tagged as cw_Sensitive.
48 Consequently, the access control module in the Xen hypervisor
49 distinguishes in this example policy 4 different workload types in
50 this example policy. It is the user's responsibility to type the
51 domains in a way that reflects the workloads of these domains and, in
52 the case of cw_Isolated, its properties, e.g. by configuring the
53 sharing capabilities of the domain accordingly by using the simple
54 type enforcement policy.
56 Users can define their own or change the existing example policy
57 according to their working environment and security requirements. To
58 do so, replace the file chwall-security_policy.xml with the new
59 policy.
63 =======================
65 The file client_v1-security_policy.xml defines the simple type
66 enforcement types for our example policy (you find it in the directory
67 "policy_root"/example/ste). The Simple Type Enforcement policy defines
68 which domains can share information with which other domains. To this
69 end, it controls
71 i) inter-domain communication channels (e.g., network traffic, events,
72 and shared memory).
74 ii) access of domains to physical resources (e.g., hard drive, network
75 cards, graphics adapter, keyboard).
77 In order to enable the hypervisor to distinguish different domains and
78 the user to express access rules, the simple type enforcement defines
79 a set of types (ste_types).
81 The policy defines that communication between domains is allowed if
82 the domains share a common STE type. As with the chwall types, STE
83 types should enable the differentiation of workloads. The simple type
84 enforcement access control implementation in the hypervisor enforces
85 that domains can only communicate (setup event channels, grant tables)
86 if they share a common type, i.e., both domains have assigned at least
87 on type in common. A domain can access a resource, if the domain and
88 the resource share a common type. Hence, assigning STE types to
89 domains and resources allows users to define constraints on sharing
90 between domains and to keep sensitive data confined from distrusted
91 domains.
93 Domain <--> Domain Sharing
94 ''''''''''''''''''''''''''
95 (implemented but its effective use requires factorization of Dom0)
97 a) Domains with a single STE type (general user domains): Sharing
98 between such domains is enforced entirely by the hypervisor access
99 control. It is independent of the domains and does not require their
100 co-operation.
102 b) Domains with multiple STE types: One example is a domain that
103 virtualizes a physical resource (e.g., hard drive) and serves it as
104 multiple virtual resources (virtual block drives) to other domains of
105 different types. The idea is that only a specific device domain has
106 assigned the type required to access the physical hard-drive. Logical
107 drives are then assigned the types of domains that have access to this
108 logical drive. Since the Xen hypervisor cannot distinguish between the
109 logical drives, the access control (type enforcement) is delegated to
110 the device domain, which has access to the types of domains requesting
111 to mount a logical drive as well as the types assigned to the
112 different available logical drives.
114 Currently in Xen, Dom0 controls all hardware, needs to communicate
115 with all domains during their setup, and intercepts all communication
116 between domains. Consequently, Dom0 needs to be assigned all types
117 used and must be completely trusted to maintain the separation of
118 information coming from domains with different STE types. Thus a
119 refactoring of Dom0 is recommended for stronger confinement
120 guarantees.
122 Domain --> RESOURCES Access
123 '''''''''''''''''''''''''''
125 We define for each resource that we want to distinguish a separate STE
126 type. Each STE type is assigned to the respective resource and to
127 those domains that are allowed to access this resource. Type
128 enforcement will guarantee that other domains cannot access this
129 resource since they don't share the resource's STE type.
131 Since in the current implementation of Xen, Dom0 controls access to
132 all hardware (e.g., disk drives, network), Domain-->Resource access
133 control enforcement must be implemented in Dom0. This is possible
134 since Dom0 has access to both the domain configuration (including the
135 domain STE types) and the resource configuration (including the
136 resource STE types).
138 For purposes of gaining higher assurance in the resulting system, it
139 may be desirable to reduce the size of dom0 by adding one or more
140 "device domains" (DDs). These DDs, e.g. providing storage or network
141 access, can support one or more physical devices, and manage
142 enforcement of MAC policy relevant for said devices. Security benefits
143 come from the smaller size of these DDs, as they can be more easily
144 audited than monolithic device driver domains. DDs can help to obtain
145 maximum security benefit from sHype.
148 Example of a Simple Type Enforcement Policy Instantiation
149 ---------------------------------------------------------
150 The example policies define the following types:
152 * ste_SystemManagement identifies workloads (and domains that runs
153 them) that must share information to accomplish the management of the
154 system
156 * ste_PersonalFinances identifies workloads that are related to
157 sensitive programs such as HomeBanking applications or safely
158 configured web browsers for InternetBanking
160 * ste_InternetInsecure identifies workloads that are very
161 function-rich and unrestricted to offer for example an environment
162 where internet games can run efficiently
164 * ste_DonatedCycles identifies workloads that run on behalf of others,
165 e.g. a Boinc client
167 * ste_PersistentStorage identifies workloads that have direct access
168 to persistent storage (e.g., hard drive)
170 * ste_NetworkAccess identifies workload that have direct access to
171 network cards and related networks
176 ========================
178 We introduce security label templates because it is difficult for
179 users to ensure tagging of domains consistently and since there are
180 --as we have seen in the case of isolation-- useful dependencies
181 between the policies. Security Label Templates define type sets that
182 can be addressed by more user-friendly label names,
183 e.g. dom_Homebanking describes a typical typeset tagged to domains
184 used for sensitive Homebanking work-loads. Labels are defined in the
185 file
187 Using Security Label Templates has multiple advantages:
188 a) easy reference of typical sets of type assignments
189 b) consistent interpretation of type combinations
190 c) meaningful application-level label names
192 The definition of label templates depends on the combination of
193 policies that are used. We will describe some of the labels defined
194 for the Chinese Wall and Simple Type Enforcement combination.
196 In the BoincClient example, the label_template file specifies that
197 this Label is assigned the Chinese Wall type cw_Isolated. We do this
198 assuming that this BoincClient is isolated against the rest of the
199 system infrastructure (no persistent memory, no sharing with local
200 domains). Since cw_Isolated is not included in any conflict set, it
201 can run at any time concurrently with any other domain. The
202 ste_DonatedCycles type assigned to the BoincClient reflect the
203 isolation assumption: it is only assigned to the dom_NetworkDomain
204 giving the BoincClient domain access to the network to communicate
205 with its BoincServer.
207 The strategy for combining types into Labels is the following: First
208 we define a label for each type of general user domain
209 (workload-oriented). Then we define a new label for each physical
210 resource that shall be shared using a DD domain (e.g., disk) and for
211 each logical resource offered through this physical resource (logical
212 disk partition). We define then device domain labels (here:
213 dom_SystemManagement, dom_StorageDomain, dom_NetworkDomain) which
214 include the types of the physical resources (e.g. hda) their domains
215 need to connect to. Such physical resources can only be accessed
216 directly by device domains types with the respective device's STE
217 type. Additionally we assign to such a device domain Label the STE
218 types of those user domains that are allowed to access one of the
219 logical resources (e.g., hda1, hda2) built on top of this physical
220 resource through the device domain.
223 Label Construction Example:
224 ---------------------------
226 We define here a storage domain label for a domain that owns a real
227 disk drive and creates the logical disk partitions hda1 and hda2 which
228 it serves to domains labeled dom_HomeBanking and dom_Fun
229 respectively. The labels we refer to are defined in the label template
230 file policies/chwall_ste/chwall_ste-security-label-template.xml.
232 step1: To distinguish different shared disk drives, we create a
233 separate Label and STE type for each of them. Here: we create a type
234 ste_PersistentStorageA for disk drive hda. If you have another disk
235 drive, you may define another persistent storage type
236 ste_PersistentStorageB in the chwall_ste-security_policy.xml.
238 step2: To distinguish different domains, we create multiple domain
239 labels including different types. Here: label dom_HomeBanking includes
240 STE type ste_PersonalFinances, label dom_Fun includes STE type
241 ste_InternetInsecure.
243 step3: The storage domain in charge of the hard drive A needs access
244 to this hard drive. Therefore the storage domain label
245 dom_StorageDomain must include the type assigned to the hard drive
246 (ste_PersistentStorageA).
248 step4: In order to serve dom hda1 to domains labeled dom_HomeBanking
249 and hda2 to domains labeled dom_Fun, the storage domain label must
250 include the types of those domains as well (ste_PersonalFinance,
251 ste_InternetInsecure).
253 step5: In order to keep the data for different types safely apart, the
254 different logical disk partitions must be assigned unique labels and
255 types, which are used inside the storage domain to extend the ACM
256 access enforcement to logical resources served from inside the storage
257 domain. We define labels "res_LogicalDiskPartition1 (hda1)" and assign
258 it to hda1 and "res_LogicalDiskPartition2 (hda2)" and assign it to
259 hda2. These labels must include the STE types of those domains that
260 are allowed to use them (e.g., ste_PersonalFinances for hda1).
262 The overall mandatory access control is then enforced in 3 different
263 Xen components and these components use a single consistent policy to
264 co-operatively enforce the policy. In the storage domain example, we
265 have three components that co-operate:
267 1. The ACM module inside the hypervisor enforces: communication
268 between user domains and the storage domain (only domains including
269 types ste_PersonalFinances or ste_InternetInsecure can communicate
270 with the storage domain and request access to logical resource). This
271 confines the sharing to the types assigned to the storage domain.
273 2. The domain management enforces: assignment of real resources (hda)
274 to domains (storage domain) that share a type with the resource.
276 3. If the storage domain serves multiple STE types (as in our
277 example), it enforces: that domains can access (mount) logical
278 resources only if they share an STE type with the respective
279 resource. In our example, domains with the STE type
280 ste_PersonalFinances can request access (mount) to logical resource
281 hda1 from the storage domain.
283 If you look at the virtual machine label dom_StorageDomain, you will
284 see the minimal set of types assigned to our domain manageing disk
285 drive hda for serving logical disk partitions exclusively to
286 dom_HomeBanking and dom_Fun.
288 Similary, network domains can confine access to the network or network
289 communication between user domains.
291 As a result, device domains (e.g., storage domain, network domain)
292 must be simple and small to ensure their correct co-operation in the
293 type enforcement model. If such trust is not possible, then hardware
294 should be assigned exclusively to a single type (or to a single
295 partition) in which case the hypervisor ACM enforcement enforces the
296 types independently.