Lines Matching refs:policy
7 one). FLASK defines a mandatory access control policy providing fine-grained
8 controls over Xen domains, allowing the policy writer to define what
47 This policy does not apply to bugs which affect stub device models,
57 to the normal security problem response policy
58 http://www.xenproject.org/security-policy.html.
89 Note that TMEM is also subject to a similar policy arising from
91 Due to this existing policy all TMEM Ops are already subject to
130 full security label of the newly created domain. If using the example policy,
135 FLASK policy overview
138 Most of FLASK policy consists of defining the interactions allowed between
143 The FLASK security framework is mostly configured using a security policy file.
145 policy will be compiled as part of the tools build. If hypervisor support for a
146 built-in policy is enabled ("Compile Xen with a built-in security policy"), the
147 policy will be built during the hypervisor build.
149 The policy is generated from definition files in tools/flask/policy. Most
150 changes to security policy will involve creating or modifying modules found in
151 tools/flask/policy/modules/. The modules.conf file there defines what modules
154 If not using the built-in policy, the XSM policy file needs to be copied to
158 the policy can be reloaded using "xl loadpolicy".
160 The example policy included with Xen demonstrates most of the features of FLASK
170 The example policy defines dm_dom_t for the device model of a domU_t domain;
196 as the target when the domain accesses itself. In the example policy, this
207 no type transition rule exists. In the example policy, these computed types are
229 The example policy also includes a resource type (nic_dev_t) for device
235 This command must be rerun on each boot or after any policy reload.
237 When first loading or writing a policy, you should run FLASK in permissive mode
241 default types for domains (domU_t), the example policy shipped with Xen should
245 MLS/MCS policy
248 If you want to use the MLS policy, then set TYPE=xen-mls in the policy Makefile
249 before building the policy. Note that the MLS constraints in policy/mls
257 policy, just like SELinux. For example, if the HVM rules are removed from the
272 The generated allow rules can then be fed back into the policy by adding them to
283 policy. Static labeling will make security policy machine-specific and may
290 There are examples commented out in tools/flask/policy/policy/device_contexts.