This document summarizes Xen security framework (XSM) which enables fine-grained control over interactions between domains, hypervisor, and resources. XSM uses mandatory access control based on security labels rather than discretionary access control. Permissions for subjects (processes or VMs) to interact with objects (files, ports, devices, etc.) are defined in security policies. The architecture includes security policies, a policy controlling entity, security server, access vector cache, and policy database. The decision making process involves checking the access vector cache, consulting the security server and policy database if needed, and returning the access decision. Challenges include ensuring atomic policy changes and consistency between security policy and runtime policy database.

1. XSM-Flask
XSM

2. Overview
 XSM: Xen Security Framework – enable administrator fine grained control.
 Defines permissible interactions between domains, hypervisor and resources.
 MAC : Mandatory access Control based mechanism rather than DAC.
 Decisions are based on Security Labels rather than users. Labelling defines security
attributes for entities.
 Permissions for “Subject” interacts with “Objects” via policy
 Subject: processes in the system or VMs.
 Object: files, sockets, ports, Devices, IO resources.
 Objects controlled by security policy are labelled with set of attributes: security
context.
 Defined as:
 Scontext = system_u:system_r:dom0_t (user:role:source_type) -- SSID
 Tcontext = system_u:system_r:domU_t (user:role:target_type) -- TSID

3.  Target Class
 Subject and object belong to a class.
 Each Class can have upto 32 permissions represented as bitmask in 32 bit int.
 Source Context
 Target Context
Eg . #define SECCLASS_XEN 1
#define SECCLASS_XEN2 2
#define SECCLASS_DOMAIN 3
#define SECCLASS_DOMAIN2 4
Eg. av_permissions.h
#define XEN_SETTIME (1UL << 0)
#define XEN2_RESOURCE_Op (1UL << 0)
#define DOMAIN_SETVCPU_CONTEXT (1UL << 0)
#define DOMAIN_CREATE (1UL << 4)

4. Architecture
 Aim:
 Defence in depth
 Minimal performance impact.
 Flexibility
 Components:
 Policy: Policy is a set of rules governing access and labelling decisions that are
specified in the configuration files.
 Allow dom0_t domU_t:domain { setvcpucontext maxvcpus, setdomainmaxmem}
 Allow dom0_t domU_t:resource {add, remove }
 Policy Controlling Entity/ Object Manger: that requests permissions.
 Security Server: provides a centralized point where all the security decisions are
made

5.  Access Vector Cache: Stores previously computed access decisions.
 Consuleted only on Cache misses.
 Used to speed up performance.
 Components form rules in policy.
 We try to Answer: Its about answering the question “ Can x do y to z” and
enforcing the result.
 PolciyDB: DB to hold the permissions based on policy. Referred by the security
Server.
 Separation of policy decision making logic and policy enforcement logic .
Client
Policy Enforcement.
Policy DB
Security Server

6. Decision Making Control flow
 Access rules defined.
 Policy compiled and loaded using toolstack.
 Domains created with appropriate security label.
 Access made, permission requested.
 AVC is checked
 If cached hit, return the access decision.
 If cache miss, consult Security Server
 Security Server consults policy decision and hands out Access Vector
consisting of all possible results.
 Result returned to the requester.
 Access vector cached in the cache.

7. “
”
Representation : Decision Making process can be thought of as based on a table
with subject running down on left edge, object across top and each cell
represent an action that a subject can take on object.
SID 1 PCI (tSID 4) domU (tSID 5) IO Mem(tSID 6) Object n
SID1 Action Action
Dom0 (sSID2) Create Action
domU (sSID3) Access Read
Subject n(sSID n) Action Action Action

8. Decision Making Control Flow
Policy Enforcement
Code.
Request Access
TSID
Policy
DB
Access Vector Cache
Stores decisions made by
the security server
Domain Created with
SecLabel
Security Server
Makes decision based on
the security policy.
Security Policy
Query
permissions
Cache Miss
Permissions
Answers
permissions

9. A bit of code structure.
 Eg .
Initial_sids
sid dom0 gen_context (system_u:system_r:dom0_t, s0)
sid domU gen_context (system_u:system_domU_t, s0)
 How we define a Class and its relevant permissions : access_vector
class xen
{
# XENPF_settime
settime
# XEN_SYSCTL_tbuf_op
tbufcontrol
# CONSOLEIO_read, XEN_SYSCTL_readconsole
readconsole
}

10. class domain
{
# XEN_DOMCTL_setvcpucontext
setvcpucontext
# XEN_DOMCTL_pausedomain
pause
# XEN_DOMCTL_unpausedomain
unpause
# XEN_DOMCTL_create
create }
 Eg. hooks.c flask_domain_create()
 {
 avc_current_has_perm(ssid, tsid, SECCLASS_DOMAIN, DOMAIN_CREATE)
 }
 //ssid : sid for the requesting domain
 //tsid : sid of target domain i.e domain to be created
 //SECCLASS_DOMAIN: target class
 //DOMAIN_CREATE: Permissions

11. Dom0.te
#allow dom0 to use these domctls on itself. For domctls acting on other
#domains, see the definitions of create_domain and manage_domain.
allow dom0_t dom0_t:domain { setvcpucontext max_vcpus setaffinity getaffinity getscheduler
getdomaininfo …. }
allow dom0_t dom0_t:resource { add remove };
domU.te
create_domain(dom0_t, domU_t)
define(`create_domain', `
allow $1 $2:domain { create max_vcpus setdomainmaxmem setaddrsize ..}’
allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim.. };
allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op updatemp };
…
')

12. Problem Statement
 All subjects or objects are grouped into “types” eg.
 dom_t for domain
 resource_t for resources
 Event_t for events.
 Security label includes “type”.
 Xen defines number of operations that are common across domains e.g.
 Memory mapping
 Pci passthrough
 Resource access
 But these are undesirable to allow every domain to perform on other.

13.  To enforce isolation, we have two approaches.
 declare different type for each domain.
 Or to duplicate permissions for each domain.
 Both approaches restricts flexibility or make XSM hooks complex.
 Lets take few examples
 New type as intr_dom_t; //introspection domain.
 Allowed pci_passthrough and introspection capability.
 But every introspection domain doesn’t need pci_passthrough capability.
 Only solution: Create a new type which doesn’t have PCI Passthrough capability but has
only introspection domain.
 All resource sharing domain doesn’t need access to all the resources. S
 Left again with only option to create a new type for each resource sharing domain.
 A big static monolithic blob of policy. Not amendable at runtime.

14. Proposed Solution
 Two Way Approach
 Be restrictive and more specific.
 Flexible policy:
 Supporting wide variety of security policy
 Each policy catering to specific set of requirements.
 Dynamically grant and revoke privileges
 Support policy changes Dynamically.

15.  Be restrictive and more specific.
 Restrict under the umbrella policy so that you don’t violate it.
 Be specific to a domain within a type.
 Example: Umbrella policy: allow domU_t domu_t:resource { add, del }
Sub policy : allow domU_t domU_t:uuid:resource { add }
Subset Subset
Umbrella Policy

16.  Runtime Grant and revoke privileges.
 We have single big monolithic policy
 Not possible to runtime grant, share or revoke permissions.
 Requires compilation and reload of whole policy whenever change in permission is
needed.
 xl grant <Source SID> <Source UUID>
<Target SID> <Target UUID>
<Target Class> grant <resource> <permissions>
Source SID Source UUID Target SID Target UUID Resource Grant
x xUUID Z zUUID Iomem 0xA
– 0xE
1

17. High level approach
 Introduce uuid which will be unique to each domain.
 Toolstack assigns uuid to each domain.
 Uuid to be part of the security context and label along with a type.
 <user:role:type:uud>
 Uuid to be considered while security server takes it decision.
 Xl loadpolicy <Source SID> <Source UUID>
<Target SID> <Target UUID>
<Target Class> restrict <resource >
 Modify the access bitmap to update the permissions
 Clear the AVC .
 (Security Server must provide interfaces to change policy)

18. Toolstackt XAPI DB
Set the security
label based on the
type of domain to
be created.
Dynamically load
the policy based
on the domain
XenServer
CommunicatewithXenserverfordomaincreationand
managementvihypercalls. Decision Making
Machine (Security
Server)

19. Challenges
 Ensure effective atomicity in interleaving policy changes : old access rights
are discarded. (“atomicity,” i.e., the ability of the system to ensure that all
operations in the system are controlled with respect to the current security
policy. )
 Revocation mechanism must guarantee that all the migrated permissions are
revoked.
 Revocation more difficult to control for operations in progress.
 Inconsistency between security policy and runtime policyDB.
 Distributed environments.

20. Comments / Questions ??