view tools/security/policy.txt @ 7778:0b4596caf761

nloopbacks default is now 8. So vifnum of greater than 7 requires
an adjustment to nloopbacks. Warning comment updated.

Signed-off-by: Nivedita Singhvi (niv@us.ibm.com)
author kaf24@firebug.cl.cam.ac.uk
date Fri Nov 11 10:46:36 2005 +0100 (2005-11-11)
parents 06d84bf87159
children c7b9b8a64755
line source
1 ##
2 # policy.txt <description to the Xen access control architecture>
3 #
4 # Author:
5 # Reiner Sailer 08/15/2005 <sailer@watson.ibm.com>
6 #
7 #
8 # This file gives an overview of the security policies currently
9 # provided and also gives some reasoning about how to assign
10 # labels to domains.
11 ##
13 Xen access control policies
16 General explanation of supported security policies:
17 =====================================================
19 We have implemented the mandatory access control architecture of our
20 hypervisor security architecture (sHype) for the Xen hypervisor. It
21 controls communication (in Xen: event channels, grant tables) between
22 Virtual Machines (from here on called domains) and through this the
23 virtual block devices, networking, and shared memory are implemented
24 on top of these communication means. While we have implemented the
25 described policies and access control architecture for other
26 hypervisor systems, we will describe below specifically its
27 implementation and use in the Xen hypervisor. The policy enforcement
28 is called mandatory regarding user domains since the policy it is
29 given by the security administration and enforced independently of the
30 user domains by the Xen hypervisor in cooperation with the domain
31 management.
33 The access control architecture consists of three parts:
35 i) The access control policy determines the "command set" of the ACM
36 and the hooks with which they can be configured to constrain the
37 sharing of virtual resources. The current access control architecture
38 implemented for Xen supports two policies: Chinese Wall and Simple
39 Type Enforcement, which we describe in turn below.
42 ii) The actually enforced policy instantiation uses the policy
43 language (i) to configure the Xen access control in a way that suits
44 the specific application (home desktop environment, company desktop,
45 Web server system, etc.). We have defined an exemplary policy
46 instantiation for Chinese Wall (chwall policy) and Simple Type
47 Enforcement (ste policy) for a desktop system. We offer these policies
48 in combination since they are controlling orthogonal events.
51 iii) The access control module (ACM) and related hooks are part of the
52 core hypervisor and their controls cannot be bypassed by domains. The
53 ACM and hooks are the active security components. We refer to
54 publications that describe how access control is enforced in the Xen
55 hypervisor using the ACM (access decision) and the hooks (decision
56 enforcement) inserted into the setup of event channels and grant
57 tables, and into domain operations (create, destroy, save, restore,
58 migrate). These controls decide based on the active policy
59 configuration (see i. and ii.) if the operation proceeds of if the
60 operation is aborted (denied).
63 In general, security policy instantiations in the Xen access control
64 framework are defined by two files:
66 a) a single "policy-name"-security_policy.xml file that defines the
67 types known to the ACM and policy rules based on these types
69 b) a single "policy-name"-security_label_template.xml file that
70 defines labels based on known types
72 Every security policy has its own sub-directory under
73 "Xen-root"/tools/security/policies in order to simplify their
74 management and the security policy tools. We will describe those files
75 for our example policy (Chinese Wall and Simple Type Enforcement) in
76 more detail as we go along. Eventually, we will move towards a system
77 installation where the policies will reside under /etc.
81 ============
83 The Chinese Wall policy enables the user to define "which workloads
84 (domain payloads) cannot run on a single physical system at the same
85 time". Why would we want to prevent workloads from running at the same
86 time on the same system? This supports requirements that can (but
87 don't have to) be rooted in the measure of trust into the isolation of
88 different domains that share the same hardware. Since the access
89 control architecture aims at high performance and non-intrusive
90 implementation, it currently does not address covert (timing) channels
91 and aims at medium assurance. Users can apply the Chinese Wall policy
92 to guarantee an air-gap between very sensitive payloads both regarding
93 covert information channels and regarding resource starvation.
95 To enable the CW control, each domain is labeled with a set of Chinese
96 Wall types and CW Conflict Sets are defined which include those CW
97 types that cannot run simultaneously on the same hardware. This
98 interpretation of conflict sets is the only policy rule for the Chines
99 Wall policy.
101 This is enforced by controlling the start of domains according to
102 their assigned CW worload types. Domains with Chinese Wall types that
103 appear in a common conflict set are running mutually exclusive on a
104 platform, i.e., once a domain with one of the cw-types of a conflict
105 set is running, no domain with another cw-type of the same conflict
106 set can start until the first domain is destroyed, paused, or migrated
107 away from the physical system (this assumes that such a partition can
108 no longer be observed). The idea is to assign cw-types according to
109 the type of payload that a domain runs and to use the Chinese Wall
110 policy to ensure that payload types can be differentiated by the
111 hypervisor and can be prevented from being executed on the same system
112 at the same time. Using the flexible CW policy maintains system
113 consolidation and workload-balancing while introducing guaranteed
114 constraints where necessary.
117 Example of a Chinese Wall Policy Instantiation
118 ----------------------------------------------
120 The file chwall-security_policy.xml defines the Chinese Wall types as
121 well as the conflict sets for our example policy (you find it in the
122 directory "xen_root"/tools/security/policies/chwall).
124 It defines four Chinese Wall types (prefixed with cw_) with the
125 following meaning:
127 * cw_SystemsManagement is a type identifying workloads for systems
128 management, e.g., domain management, device management, or hypervisor
129 management.
131 * cw_Sensitive is identifying workloads that are critical to the user
132 for one reason or another.
134 * cw_Distrusted is identifying workloads a user does not have much
135 confidence in. E.g. a domain used for surfing in the internet without
136 protection( i.e., active-X, java, java-script, executing web content)
137 or for (Internet) Games should be typed this way.
139 * cw_Isolated is identifying workloads that are supposedly isolated by
140 use of the type enforcement policy (described below). For example, if
141 a user wants to donate cycles to seti@home, she can setup a separate
142 domain for a Boinc (http://boinc.ssl.berkeley.edu/) client, disable
143 this domain from accessing the hard drive and from communicating to
144 other local domains, and type it as cw_Isolated. We will look at a
145 specific example later.
147 The example policy uses the defined types to define one conflict set:
148 Protection1 = {cw_Sensitive, cw_Distrusted}. This conflict set tells
149 the hypervisor that once a domain typed as cw_Sensitive is running, a
150 domain typed as cw_Distrusted cannot run concurrently (and the other
151 way round). With this policy, a domain typed as cw_Isolated is allowed
152 to run simultaneously with domains tagged as cw_Sensitive.
154 Consequently, the access control module in the Xen hypervisor
155 distinguishes in this example policy 4 different workload types in
156 this example policy. It is the user's responsibility to type the
157 domains in a way that reflects the workloads of these domains and, in
158 the case of cw_Isolated, its properties, e.g. by configuring the
159 sharing capabilities of the domain accordingly by using the simple
160 type enforcement policy.
162 Users can define their own or change the existing example policy
163 according to their working environment and security requirements. To
164 do so, replace the file chwall-security_policy.xml with the new
165 policy.
169 =======================
171 The file ste-security_policy.xml defines the simple type enforcement
172 types for our example policy (you find it in the directory
173 "xen_root"/tools/security/policies/ste). The Simple Type Enforcement
174 policy defines which domains can share information with which other
175 domains. To this end, it controls
177 i) inter-domain communication channels (e.g., network traffic, events,
178 and shared memory).
180 ii) access of domains to physical resources (e.g., hard drive, network
181 cards, graphics adapter, keyboard).
183 In order to enable the hypervisor to distinguish different domains and
184 the user to express access rules, the simple type enforcement defines
185 a set of types (ste_types).
187 The policy defines that communication between domains is allowed if
188 the domains share a common STE type. As with the chwall types, STE
189 types should enable the differentiation of workloads. The simple type
190 enforcement access control implementation in the hypervisor enforces
191 that domains can only communicate (setup event channels, grant tables)
192 if they share a common type, i.e., both domains have assigned at least
193 on type in common. A domain can access a resource, if the domain and
194 the resource share a common type. Hence, assigning STE types to
195 domains and resources allows users to define constraints on sharing
196 between domains and to keep sensitive data confined from distrusted
197 domains.
199 Domain <--> Domain Sharing
200 ''''''''''''''''''''''''''
201 (implemented but its effective use requires factorization of Dom0)
203 a) Domains with a single STE type (general user domains): Sharing
204 between such domains is enforced entirely by the hypervisor access
205 control. It is independent of the domains and does not require their
206 co-operation.
208 b) Domains with multiple STE types: One example is a domain that
209 virtualizes a physical resource (e.g., hard drive) and serves it as
210 multiple virtual resources (virtual block drives) to other domains of
211 different types. The idea is that only a specific device domain has
212 assigned the type required to access the physical hard-drive. Logical
213 drives are then assigned the types of domains that have access to this
214 logical drive. Since the Xen hypervisor cannot distinguish between the
215 logical drives, the access control (type enforcement) is delegated to
216 the device domain, which has access to the types of domains requesting
217 to mount a logical drive as well as the types assigned to the
218 different available logical drives.
220 Currently in Xen, Dom0 controls all hardware, needs to communicate
221 with all domains during their setup, and intercepts all communication
222 between domains. Consequently, Dom0 needs to be assigned all types
223 used and must be completely trusted to maintain the separation of
224 informatio ncoming from domains with different STE types. Thus a
225 refactoring of Dom0 is recommended for stronger confinement
226 guarantees.
228 Domain --> RESOURCES Access
229 '''''''''''''''''''''''''''
230 (current work)
232 We define for each resource that we want to distinguish a separate STE
233 type. Each STE type is assigned to the respective resource and to
234 those domains that are allowed to access this resource. Type
235 enforcement will guarantee that other domains cannot access this
236 resource since they don't share the resource's STE type.
238 Since in the current implementation of Xen, Dom0 controls access to
239 all hardware (e.g., disk drives, network), Domain-->Resource access
240 control enforcement must be implemented in Dom0. This is possible
241 since Dom0 has access to both the domain configuration (including the
242 domain STE types) and the resource configuration (including the
243 resource STE types).
245 For purposes of gaining higher assurance in the resulting system, it
246 may be desirable to reduce the size of dom0 by adding one or more
247 "device domains" (DDs). These DDs, e.g. providing storage or network
248 access, can support one or more physical devices, and manage
249 enforcement of MAC policy relevant for said devices. Security benefits
250 come from the smaller size of these DDs, as they can be more easily
251 audited than monolithic device driver domains. DDs can help to obtain
252 maximum security benefit from sHype.
255 Example of a Simple Type Enforcement Policy Instantiation
256 ---------------------------------------------------------
258 We define the following types:
260 * ste_SystemManagement identifies workloads (and domains that runs
261 them) that must share information to accomplish the management of the
262 system
264 * ste_PersonalFinances identifies workloads that are related to
265 sensitive programs such as HomeBanking applications or safely
266 configured web browsers for InternetBanking
268 * ste_InternetInsecure identifies workloads that are very
269 function-rich and unrestricted to offer for example an environment
270 where internet games can run efficiently
272 * ste_DonatedCycles identifies workloads that run on behalf of others,
273 e.g. a Boinc client
275 * ste_PersistentStorage identifies workloads that have direct access
276 to persistent storage (e.g., hard drive)
278 * ste_NetworkAccess identifies workload that have direct access to
279 network cards and related networks
284 ========================
286 We introduce security label templates because it is difficult for
287 users to ensure tagging of domains consistently and since there are
288 --as we have seen in the case of isolation-- useful dependencies
289 between the policies. Security Label Templates define type sets that
290 can be addressed by more user-friendly label names,
291 e.g. dom_Homebanking describes a typical typeset tagged to domains
292 used for sensitive Homebanking work-loads. Labels are defined in the
293 file
295 Using Security Label Templates has multiple advantages:
296 a) easy reference of typical sets of type assignments
297 b) consistent interpretation of type combinations
298 c) meaningful application-level label names
300 The definition of label templates depends on the combination of
301 policies that are used. We will describe some of the labels defined
302 for the Chinese Wall and Simple Type Enforcement combination.
304 In the BoincClient example, the label_template file specifies that
305 this Label is assigned the Chinese Wall type cw_Isolated. We do this
306 assuming that this BoincClient is isolated against the rest of the
307 system infrastructure (no persistent memory, no sharing with local
308 domains). Since cw_Isolated is not included in any conflict set, it
309 can run at any time concurrently with any other domain. The
310 ste_DonatedCycles type assigned to the BoincClient reflect the
311 isolation assumption: it is only assigned to the dom_NetworkDomain
312 giving the BoincClient domain access to the network to communicate
313 with its BoincServer.
315 The strategy for combining types into Labels is the following: First
316 we define a label for each type of general user domain
317 (workload-oriented). Then we define a new label for each physical
318 resource that shall be shared using a DD domain (e.g., disk) and for
319 each logical resource offered through this physical resource (logical
320 disk partition). We define then device domain labels (here:
321 dom_SystemManagement, dom_StorageDomain, dom_NetworkDomain) which
322 include the types of the physical resources (e.g. hda) their domains
323 need to connect to. Such physical resources can only be accessed
324 directly by device domains types with the respective device's STE
325 type. Additionally we assign to such a device domain Label the STE
326 types of those user domains that are allowed to access one of the
327 logical resources (e.g., hda1, hda2) built on top of this physical
328 resource through the device domain.
331 Label Construction Example:
332 ---------------------------
334 We define here a storage domain label for a domain that owns a real
335 disk drive and creates the logical disk partitions hda1 and hda2 which
336 it serves to domains labeled dom_HomeBanking and dom_Fun
337 respectively. The labels we refer to are defined in the label template
338 file policies/chwall_ste/chwall_ste-security-label-template.xml.
340 step1: To distinguish different shared disk drives, we create a
341 separate Label and STE type for each of them. Here: we create a type
342 ste_PersistentStorageA for disk drive hda. If you have another disk
343 drive, you may define another persistent storage type
344 ste_PersistentStorageB in the chwall_ste-security_policy.xml.
346 step2: To distinguish different domains, we create multiple domain
347 labels including different types. Here: label dom_HomeBanking includes
348 STE type ste_PersonalFinances, label dom_Fun includes STE type
349 ste_InternetInsecure.
351 step3: The storage domain in charge of the hard drive A needs access
352 to this hard drive. Therefore the storage domain label
353 dom_StorageDomain must include the type assigned to the hard drive
354 (ste_PersistentStorageA).
356 step4: In order to serve dom hda1 to domains labeled dom_HomeBanking
357 and hda2 to domains labeled dom_Fun, the storage domain label must
358 include the types of those domains as well (ste_PersonalFinance,
359 ste_InternetInsecure).
361 step5: In order to keep the data for different types safely apart, the
362 different logical disk partitions must be assigned unique labels and
363 types, which are used inside the storage domain to extend the ACM
364 access enforcement to logical resources served from inside the storage
365 domain. We define labels "res_LogicalDiskPartition1 (hda1)" and assign
366 it to hda1 and "res_LogicalDiskPartition2 (hda2)" and assign it to
367 hda2. These labels must include the STE types of those domains that
368 are allowed to use them (e.g., ste_PersonalFinances for hda1).
370 The overall mandatory access control is then enforced in 3 different
371 Xen components and these components use a single consistent policy to
372 co-operatively enforce the policy. In the storage domain example, we
373 have three components that co-operate:
375 1. The ACM module inside the hypervisor enforces: communication between
376 user domains and the storage domain (only domains including types
377 ste_PersonalFinances or ste_InternetInsecure can communicate with the
378 storage domain and request access to logical resource). This confines
379 the sharing to the types assigned to the storage domain.
381 2. The domain management will enforce (work in progress): assignment of
382 real resources (hda) to domains (storage domain) that share a
383 type with the resource.
385 3. If the storage domain serves multiple STE types (as in our example),
386 it enforces (work in progress): that domains can access (mount)
387 logical resources only if they share an STE type with the respective
388 resource. In our example, domains with the STE type
389 ste_PersonalFinances can request access (mount) to logical resource
390 hda1 from the storage domain.
392 If you look at the virtual machine label dom_StorageDomain, you will
393 see the minimal set of types assigned to our domain manageing disk
394 drive hda for serving logical disk partitions exclusively to
395 dom_HomeBanking and dom_Fun.
397 Similary, network domains can confine access to the network or
398 network communication between user domains.
400 As a result, device domains (e.g., storage domain, network domain)
401 must be simple and small to ensure their correct co-operation in the
402 type enforcement model. If such trust is not possible, then hardware
403 should be assigned exclusively to a single type (or to a single
404 partition) in which case the hypervisor ACM enforcement enforces the
405 types independently.