view tools/security/policy.txt @ 11330:3e54734e55f3

[IA64] Remove extraneous verbose output to clean up Fedora boot.

Signed-off-by: Aron Griffis <>
date Wed Aug 23 13:26:46 2006 -0600 (2006-08-23)
parents c7b9b8a64755
children 16f1f8ac8902
line source
1 ##
2 # policy.txt <description to the Xen access control architecture>
3 #
4 # Author:
5 # Reiner Sailer 08/15/2005 <>
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).
62 In general, security policy instantiations in the Xen access control
63 framework are defined by XML policy files. Each security policy has
64 exactly one file including all the information the hypervisor needs to
65 enforce the policy.
67 The name of a policy is unique and consists of a colon-separated list
68 of names, which can be translated into the location (subtree) where
69 this policy must be located. The last part of the name is the file
70 name pre-fix for the policy xml file. The preceding name parts are
71 translated into the local path relative to the global policy root
72 (/etc/xen/acm-security/policies) pointing to the policy xml file. For
73 example: example.chwall_ste.client_v1 denotes the policy file
74 example/chwall_ste/client_v1-security_policy.xml relative to the
75 global policy root directory.
77 Every security policy has its own sub-directory under the global
78 policy root directory /etc/xen/acm-security/policies, which is
79 installed during the Xen installation or can be manually installed
80 (when switching from a "security disabled" Xen to a "security enabled"
81 Xen AFTER configuring security, see install.txt) by the command
82 sequence:
84 cd "Xen-root"/tools/security/policies; make install
86 We will describe those files for our example policy (Chinese Wall and
87 Simple Type Enforcement) in more detail as we go along. Eventually, we
88 will move towards a system installation where the policies will reside
89 under /etc.
93 ============
95 The Chinese Wall policy enables the user to define "which workloads
96 (domain payloads) cannot run on a single physical system at the same
97 time". Why would we want to prevent workloads from running at the same
98 time on the same system? This supports requirements that can (but
99 don't have to) be rooted in the measure of trust into the isolation of
100 different domains that share the same hardware. Since the access
101 control architecture aims at high performance and non-intrusive
102 implementation, it currently does not address covert (timing) channels
103 and aims at medium assurance. Users can apply the Chinese Wall policy
104 to guarantee an air-gap between very sensitive payloads both regarding
105 covert information channels and regarding resource starvation.
107 To enable the CW control, each domain is labeled with a set of Chinese
108 Wall types and CW Conflict Sets are defined which include those CW
109 types that cannot run simultaneously on the same hardware. This
110 interpretation of conflict sets is the only policy rule for the Chines
111 Wall policy.
113 This is enforced by controlling the start of domains according to
114 their assigned CW worload types. Domains with Chinese Wall types that
115 appear in a common conflict set are running mutually exclusive on a
116 platform, i.e., once a domain with one of the cw-types of a conflict
117 set is running, no domain with another cw-type of the same conflict
118 set can start until the first domain is destroyed, paused, or migrated
119 away from the physical system (this assumes that such a partition can
120 no longer be observed). The idea is to assign cw-types according to
121 the type of payload that a domain runs and to use the Chinese Wall
122 policy to ensure that payload types can be differentiated by the
123 hypervisor and can be prevented from being executed on the same system
124 at the same time. Using the flexible CW policy maintains system
125 consolidation and workload-balancing while introducing guaranteed
126 constraints where necessary.
129 Example of a Chinese Wall Policy Instantiation
130 ----------------------------------------------
132 The file client_v1-security_policy.xml defines the Chinese Wall types
133 as well as the conflict sets for our example policy (you find it in
134 the directory "policy_root"/example/chwall).
136 It defines four Chinese Wall types (prefixed with cw_) with the
137 following meaning:
139 * cw_SystemsManagement is a type identifying workloads for systems
140 management, e.g., domain management, device management, or hypervisor
141 management.
143 * cw_Sensitive is identifying workloads that are critical to the user
144 for one reason or another.
146 * cw_Distrusted is identifying workloads a user does not have much
147 confidence in. E.g. a domain used for surfing in the internet without
148 protection( i.e., active-X, java, java-script, executing web content)
149 or for (Internet) Games should be typed this way.
151 * cw_Isolated is identifying workloads that are supposedly isolated by
152 use of the type enforcement policy (described below). For example, if
153 a user wants to donate cycles to seti@home, she can setup a separate
154 domain for a Boinc ( client, disable
155 this domain from accessing the hard drive and from communicating to
156 other local domains, and type it as cw_Isolated. We will look at a
157 specific example later.
159 The example policy uses the defined types to define one conflict set:
160 Protection1 = {cw_Sensitive, cw_Distrusted}. This conflict set tells
161 the hypervisor that once a domain typed as cw_Sensitive is running, a
162 domain typed as cw_Distrusted cannot run concurrently (and the other
163 way round). With this policy, a domain typed as cw_Isolated is allowed
164 to run simultaneously with domains tagged as cw_Sensitive.
166 Consequently, the access control module in the Xen hypervisor
167 distinguishes in this example policy 4 different workload types in
168 this example policy. It is the user's responsibility to type the
169 domains in a way that reflects the workloads of these domains and, in
170 the case of cw_Isolated, its properties, e.g. by configuring the
171 sharing capabilities of the domain accordingly by using the simple
172 type enforcement policy.
174 Users can define their own or change the existing example policy
175 according to their working environment and security requirements. To
176 do so, replace the file chwall-security_policy.xml with the new
177 policy.
181 =======================
183 The file client_v1-security_policy.xml defines the simple type
184 enforcement types for our example policy (you find it in the directory
185 "policy_root"/example/ste). The Simple Type Enforcement policy defines
186 which domains can share information with which other domains. To this
187 end, it controls
189 i) inter-domain communication channels (e.g., network traffic, events,
190 and shared memory).
192 ii) access of domains to physical resources (e.g., hard drive, network
193 cards, graphics adapter, keyboard).
195 In order to enable the hypervisor to distinguish different domains and
196 the user to express access rules, the simple type enforcement defines
197 a set of types (ste_types).
199 The policy defines that communication between domains is allowed if
200 the domains share a common STE type. As with the chwall types, STE
201 types should enable the differentiation of workloads. The simple type
202 enforcement access control implementation in the hypervisor enforces
203 that domains can only communicate (setup event channels, grant tables)
204 if they share a common type, i.e., both domains have assigned at least
205 on type in common. A domain can access a resource, if the domain and
206 the resource share a common type. Hence, assigning STE types to
207 domains and resources allows users to define constraints on sharing
208 between domains and to keep sensitive data confined from distrusted
209 domains.
211 Domain <--> Domain Sharing
212 ''''''''''''''''''''''''''
213 (implemented but its effective use requires factorization of Dom0)
215 a) Domains with a single STE type (general user domains): Sharing
216 between such domains is enforced entirely by the hypervisor access
217 control. It is independent of the domains and does not require their
218 co-operation.
220 b) Domains with multiple STE types: One example is a domain that
221 virtualizes a physical resource (e.g., hard drive) and serves it as
222 multiple virtual resources (virtual block drives) to other domains of
223 different types. The idea is that only a specific device domain has
224 assigned the type required to access the physical hard-drive. Logical
225 drives are then assigned the types of domains that have access to this
226 logical drive. Since the Xen hypervisor cannot distinguish between the
227 logical drives, the access control (type enforcement) is delegated to
228 the device domain, which has access to the types of domains requesting
229 to mount a logical drive as well as the types assigned to the
230 different available logical drives.
232 Currently in Xen, Dom0 controls all hardware, needs to communicate
233 with all domains during their setup, and intercepts all communication
234 between domains. Consequently, Dom0 needs to be assigned all types
235 used and must be completely trusted to maintain the separation of
236 informatio ncoming from domains with different STE types. Thus a
237 refactoring of Dom0 is recommended for stronger confinement
238 guarantees.
240 Domain --> RESOURCES Access
241 '''''''''''''''''''''''''''
242 (current work)
244 We define for each resource that we want to distinguish a separate STE
245 type. Each STE type is assigned to the respective resource and to
246 those domains that are allowed to access this resource. Type
247 enforcement will guarantee that other domains cannot access this
248 resource since they don't share the resource's STE type.
250 Since in the current implementation of Xen, Dom0 controls access to
251 all hardware (e.g., disk drives, network), Domain-->Resource access
252 control enforcement must be implemented in Dom0. This is possible
253 since Dom0 has access to both the domain configuration (including the
254 domain STE types) and the resource configuration (including the
255 resource STE types).
257 For purposes of gaining higher assurance in the resulting system, it
258 may be desirable to reduce the size of dom0 by adding one or more
259 "device domains" (DDs). These DDs, e.g. providing storage or network
260 access, can support one or more physical devices, and manage
261 enforcement of MAC policy relevant for said devices. Security benefits
262 come from the smaller size of these DDs, as they can be more easily
263 audited than monolithic device driver domains. DDs can help to obtain
264 maximum security benefit from sHype.
267 Example of a Simple Type Enforcement Policy Instantiation
268 ---------------------------------------------------------
270 We define the following types:
272 * ste_SystemManagement identifies workloads (and domains that runs
273 them) that must share information to accomplish the management of the
274 system
276 * ste_PersonalFinances identifies workloads that are related to
277 sensitive programs such as HomeBanking applications or safely
278 configured web browsers for InternetBanking
280 * ste_InternetInsecure identifies workloads that are very
281 function-rich and unrestricted to offer for example an environment
282 where internet games can run efficiently
284 * ste_DonatedCycles identifies workloads that run on behalf of others,
285 e.g. a Boinc client
287 * ste_PersistentStorage identifies workloads that have direct access
288 to persistent storage (e.g., hard drive)
290 * ste_NetworkAccess identifies workload that have direct access to
291 network cards and related networks
296 ========================
298 We introduce security label templates because it is difficult for
299 users to ensure tagging of domains consistently and since there are
300 --as we have seen in the case of isolation-- useful dependencies
301 between the policies. Security Label Templates define type sets that
302 can be addressed by more user-friendly label names,
303 e.g. dom_Homebanking describes a typical typeset tagged to domains
304 used for sensitive Homebanking work-loads. Labels are defined in the
305 file
307 Using Security Label Templates has multiple advantages:
308 a) easy reference of typical sets of type assignments
309 b) consistent interpretation of type combinations
310 c) meaningful application-level label names
312 The definition of label templates depends on the combination of
313 policies that are used. We will describe some of the labels defined
314 for the Chinese Wall and Simple Type Enforcement combination.
316 In the BoincClient example, the label_template file specifies that
317 this Label is assigned the Chinese Wall type cw_Isolated. We do this
318 assuming that this BoincClient is isolated against the rest of the
319 system infrastructure (no persistent memory, no sharing with local
320 domains). Since cw_Isolated is not included in any conflict set, it
321 can run at any time concurrently with any other domain. The
322 ste_DonatedCycles type assigned to the BoincClient reflect the
323 isolation assumption: it is only assigned to the dom_NetworkDomain
324 giving the BoincClient domain access to the network to communicate
325 with its BoincServer.
327 The strategy for combining types into Labels is the following: First
328 we define a label for each type of general user domain
329 (workload-oriented). Then we define a new label for each physical
330 resource that shall be shared using a DD domain (e.g., disk) and for
331 each logical resource offered through this physical resource (logical
332 disk partition). We define then device domain labels (here:
333 dom_SystemManagement, dom_StorageDomain, dom_NetworkDomain) which
334 include the types of the physical resources (e.g. hda) their domains
335 need to connect to. Such physical resources can only be accessed
336 directly by device domains types with the respective device's STE
337 type. Additionally we assign to such a device domain Label the STE
338 types of those user domains that are allowed to access one of the
339 logical resources (e.g., hda1, hda2) built on top of this physical
340 resource through the device domain.
343 Label Construction Example:
344 ---------------------------
346 We define here a storage domain label for a domain that owns a real
347 disk drive and creates the logical disk partitions hda1 and hda2 which
348 it serves to domains labeled dom_HomeBanking and dom_Fun
349 respectively. The labels we refer to are defined in the label template
350 file policies/chwall_ste/chwall_ste-security-label-template.xml.
352 step1: To distinguish different shared disk drives, we create a
353 separate Label and STE type for each of them. Here: we create a type
354 ste_PersistentStorageA for disk drive hda. If you have another disk
355 drive, you may define another persistent storage type
356 ste_PersistentStorageB in the chwall_ste-security_policy.xml.
358 step2: To distinguish different domains, we create multiple domain
359 labels including different types. Here: label dom_HomeBanking includes
360 STE type ste_PersonalFinances, label dom_Fun includes STE type
361 ste_InternetInsecure.
363 step3: The storage domain in charge of the hard drive A needs access
364 to this hard drive. Therefore the storage domain label
365 dom_StorageDomain must include the type assigned to the hard drive
366 (ste_PersistentStorageA).
368 step4: In order to serve dom hda1 to domains labeled dom_HomeBanking
369 and hda2 to domains labeled dom_Fun, the storage domain label must
370 include the types of those domains as well (ste_PersonalFinance,
371 ste_InternetInsecure).
373 step5: In order to keep the data for different types safely apart, the
374 different logical disk partitions must be assigned unique labels and
375 types, which are used inside the storage domain to extend the ACM
376 access enforcement to logical resources served from inside the storage
377 domain. We define labels "res_LogicalDiskPartition1 (hda1)" and assign
378 it to hda1 and "res_LogicalDiskPartition2 (hda2)" and assign it to
379 hda2. These labels must include the STE types of those domains that
380 are allowed to use them (e.g., ste_PersonalFinances for hda1).
382 The overall mandatory access control is then enforced in 3 different
383 Xen components and these components use a single consistent policy to
384 co-operatively enforce the policy. In the storage domain example, we
385 have three components that co-operate:
387 1. The ACM module inside the hypervisor enforces: communication between
388 user domains and the storage domain (only domains including types
389 ste_PersonalFinances or ste_InternetInsecure can communicate with the
390 storage domain and request access to logical resource). This confines
391 the sharing to the types assigned to the storage domain.
393 2. The domain management will enforce (work in progress): assignment of
394 real resources (hda) to domains (storage domain) that share a
395 type with the resource.
397 3. If the storage domain serves multiple STE types (as in our example),
398 it enforces (work in progress): that domains can access (mount)
399 logical resources only if they share an STE type with the respective
400 resource. In our example, domains with the STE type
401 ste_PersonalFinances can request access (mount) to logical resource
402 hda1 from the storage domain.
404 If you look at the virtual machine label dom_StorageDomain, you will
405 see the minimal set of types assigned to our domain manageing disk
406 drive hda for serving logical disk partitions exclusively to
407 dom_HomeBanking and dom_Fun.
409 Similary, network domains can confine access to the network or
410 network communication between user domains.
412 As a result, device domains (e.g., storage domain, network domain)
413 must be simple and small to ensure their correct co-operation in the
414 type enforcement model. If such trust is not possible, then hardware
415 should be assigned exclusively to a single type (or to a single
416 partition) in which case the hypervisor ACM enforcement enforces the
417 types independently.