JustKernel
Ray Of Hope
secure Xen throught XSM
XSM (Xen Security Modules) is security frame provided by Xen to secure Xen domains. The implementation of the framework lies within FLASK (Flux Advanced Security Kernel) policies. XSM is the policy definition entity while FLASK is an enforcement engine.
Aspects of domain(s) that can be controlled:
1) interaction between domains (domU vs domU / dom0 / domU)
2) interaction between hypervisor and domains
3) grant maps between domains.
4) level of control itself that one domain can exert on another domain or on itself.
5) access to resources.
6) domain control based on the user’s role and permissions defined.
Compile and Create Policy:
Compile Xen with XSM enabled. XSM can be enabled in Config.kmk or via menuconfig.
Create XSM FLASK policy. A FLASK policy comprises of the following components.
— .te and .if files: contain types, attributes and rules based on those types and attributes. They also define the roles which are part of security label.
— constraints: Constraints are a safety net to specifically disallow undesired operations that the policy may allow otherwise.
— initial_sids (security identifiers): This file defines the defaults sids for undefined/unlabelled components (resources, domains etc.). for eg. “sid unlabeled
— gen_context(system_u:system_r:unlabeled_t,s0)” : an unlabeled domain willl have an sid of “system_u:system_r_unlabled_t”.
— users: This file defines the user parameter of the security policy. Permissions can also be based on the type of user i.e whether administrator or a guest user.
Sample policy can be found in upstream-xen/tools/flask/policy/policy/modules/xen. ‘checkpolicy’ compiler is used to create compile the policy. For eg to make a default xen policy on the upstream code : “make -C tools/flask/policy”
A policy is a simple text file which has to be in some standard formatSecond, a XSM FLASK policy must be created. Third and finally, the dom0 bootloader configuration must be updated to enable XSM at boot and load the policy.
Booting Xen with XSM
XSM can be enabled and enforced during boot time by modifying the grub entry or it can after the host has booted.
Enable at boot time :
“vi /boot/grub/grub.cfg
menuentry ‘XenServer (Serial)’ {
search –label –set root root-wurzoa
multiboot2 /boot/xen-debug.gz com1=115200,8n1 flask=
Following are the options:
–`permissive`: This is intended for development and is not suitable for use with untrusted guests. The policy can be changed to enforcing mode using “xl setenforce”.
–`enforcing`: This requires a security policy to be provided by the bootloader and will enter enforcing mode prior to the creation of domain 0. If a valid policy is not provided, the hypervisor will not continue booting.
— `late`: This disables loading of the security policy from the bootloader. FLASK will be enabled but will not enforce access controls until a policy is loaded by a domain using “xl loadpolicy”. Once a policy is loaded, FLASK will run in enforcing mode unless “xl setenforce” has changed that setting.
— `disabled`: This causes the XSM framework to revert to the dummy module. The dummy module provides the same security policy as is used when compiling the hypervisor without support for XSM. The xsm_op hypercall can also be used to switch to this mode after boot, but there is no way to re-enable FLASK once the dummy module is loaded.
Policy Enforcement:
FLASK uses only one domain configuration parameter, seclabel i.e security label which defines the security characteristics of a domain. Seclabel is composed of user:role:target domain . for eg “seclabel=’system_u:system_r:domU_t’ defines the permissions and access rights that a particular domain can enjoy.
XSM attaches security parameters to a domain based on its label and blocks all unlabeled domain. During operations involving multiple domains e.g. interdomain communication or management of one domain by another, XSM find the intersection of security policy of both domains based on the seclabel and permissible/prohibited set of operations for those domains.
Proposal for Approach and RFC :
User can be presented with the option to select the type of the domain he wants . For eg
Domain with PCI -Passthrough privileges.
Introspection domain
special privilege domain and privileges it requires.
role of the user using the domain
user of the domain.
XAPI takes this information stores it in its db and pass it on to Xen via hypercall to create domain. Xen needs to do the following
create a new domain with appropriate label.
load security policy.
Questions
1) Xen can select policy once during dom0 boot up. What happens if we need to change policy after that.
2) At present we can use only one system wide policy that should define rules and privileges for all the domains. Can this limitation suffice our requirements. Do we need multiple policy files. (we can have label introspection_domain and define rules specific to that. All the domains that are created for introspection need to have that label. This way we can avoid having multiple policy files for same type of domains.).
3) How XAPI , XEN communication will work.
4) Define the v1 requirements.
Dom0 Security :
Default policy that is currently being used in Xen (if XSM is enabled) restricts various operations that are required for its proper functioning. Below are the modifications that were done to the default policy for dom0:
Modifications required in default XSM policy to make Dom0 functional :
Set of hypercalls need to be enabled while creation of domUs .
get_runstate_info
setcorespersocket
get_runstate_info
setdomainhandle
Fix :
define(`create_domain_common’, `
allow $1 $2:domain {setdomainhandle
settime};
allow $1 $2:domain2 { get_runstate_info setcorespersocket};
allow $1 $2:security check_context;
allow $1 $2:event send;
allow $1 $2:resource use;
‘)
Sending events between dom0 and domU during domain creation.
Error Log: “[2016-04-05 10:12:53] (XEN) [66990.238649] avc: denied { send } for domid=1 scontext=system_u:system_r:domU_t tcontext=system_u:system_r:dom0_t tclass=event”
Fix: define(`create_domain_common’, `
allow $1 $2:domain {
allow $1 $2:event send;
‘)
Errors during gvtg testing
domU denied access of iomem resource during its creation. Error log: “avc: denied { use } for domid=0 range=0x829cc3-0x829cc3 scontext=system_u:system_r:domU_t tcontext=system_u:object_r:iomem_t tclass=resource
[ 222.587191] xen_domain_iomem_perm failed: -1”
Fix:
define(`create_domain_common’, `
allow $1 $2:domain { allow $1 $2:resource use;}
admin_device(domU_t, iomem_t)
dom0 denied access to send_irq hypercall : target class hvm
Fix:
define(`create_domain_common’, `
allow $1 $2:domain {
allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc
setparam pcilevel trackdirtyvram nested altp2mhvm altp2mhvm_op send_irq};
Errors during gpu-passthrough testing.
domU denied direct access to ioport resource. Error Log: “avc: denied { use } for domid=0 range=0xf000-0xf03f scontext=system_u:system_r:domU_t tcontext=system_u:object_r:ioport_t tclass=resource”
Fix:
# Allow it in case PCI passthrough. Can we make it conditional.
admin_device(domU_t, ioport_t)
domU denied direct access to device. Error Log: ” (XEN) [ 2113.831387] avc: denied { use } for domid=0 device=0x10 scontext=system_u:system_r:domU_t tcontext=system_u:object_r:device_t tclass=resource£
Fix:
# Allow it in case PCI passthrough. Put condition to check if PCI passthrough is getting used.
admin_device(domU_t, device_t)
Dom 0 Security and Introspection domain:
There is an ever increasing demand from the Antivirus vendors to provide access to their domain to introspect another domain in order to detect viruses. The workaround that we have at present is to grant dom0 privileges to their domain which, in my view, is a big security hole.
I am working on a solution and defining a security policy wherein introspection domain will be created as a separate domain from dom0 and will exert restricted control over other domains including dom 0. There is clear segregation of rights and privileges of dom0 and introspection domain.
Introspection domain privileges.
1) declare introspection_dom as domU_type
2) dom0 can create/manage/communicate with introspection_dom
3) introspection_dom can communicate and manage with other domUs
4) introspection_dom managing rights:
getdomaininfo getvcpuinfo getaffinity getaddrsize trigger setaffinity };
Does it need pause, resume, shutdown, restart privileges ???
Will continue to add more as I proceed with testing.
We can also create a separate class of domU type that can be introspected by the introspection_dom. So the question is whether we should bring all domUs under the management of introspection_dom or only special type of domUs ??
mail_to: anshul_makkar@justkernel.com
Leave a Reply