DEL HECHO DE TRÁNSITO

In the caas design, the system has stopped relying on dom0for domain building, and thus dom0 _{is evicted from the tcb. However, unless the hypervisor} is modified to reflect this, dom0 still has the privileges to execute attacks. Therefore, it is critical that the hypervisor’s access control reflects the new division of work between the dom0 _{and domt domains.}

In vanilla Xen there exists by default a very basic access control, which is nothing more than a boolean privileged versus unprivileged status flag. This

:consumer _:dom0 :domt :tpm

d := FDE(d, s) mcv := m ++c ++v

mcv := AES(mcv, s)

verify(PKBIND, CBIND)

s :=hTspi_iData_Bind(PKBIND, s)

h := HMAC(u ++mcv ++s, s) b := u ++mcv ++s ++h

createVM(d, b)

createDomain(b, . . . )

hTPM_iLoadKey2(PKBIND, ESKBIND)

HBIND

hTPM_iUnbind(s, key=HBIND)

s

assert h ⇐⇒ HMAC(. . . , s) assert c ⇐⇒ ReadVCounter(u)

create domain (cf. appendix B.5)

return code return code

u: uuid s: symmetric master key

m: merkle tree h: hmac

c: counter value mcv: group of properties

v: _vtpm-nv

d: vm disk b: vmcb

Figure B.5: The interactions between the entities for deploying a vm.

B. Implementation details

suffices only for the most simple scenario in which there is one domain which fulfills all of the privileged tasks. Fortunately, there already exist a more expressive development in this area on which we can build.

B.3.1. The XSMframework

The xsm framework, also known as sHype, is a framework for writing security modules for Xen[Sai+05]._{The xsm framework design is an application of manda-}

tory access control at hypervisor level. The discussion of mandatory access control is out of scope as it is a large topic; however, its application here is simple, it allows to express strict regulations which curb the free deployment of vms more than what is possible in vanilla Xen. For instance, one might desire a strict Chinese wall policy such that customers Alice and Bob are never co-resident on a single machine. Another example is the desire to prevent the vms from Alice and Charley to communicate with each other under any circumstance.

The xsm framework is implemented as modifications to the hypervisor source code. To allow for the expressiveness of aforementioned example policies, the xsm framework adds many hooks throughout the hypervisor source code via which a xsm security module can regulate the control to hypercalls.

Xen comes with two available implementations which hook into the xsm framework: the access control module (acm) and Flask.

1. The acm framework, which appears unmaintained, is oriented at imple- menting Chinese Wall or simple type enforcement policies, both limited in expressiveness.

2. The Flask system borrows much from selinux. One compiles a policy using a selinux policy compiler in which one describes how to act at all the hook points. This policy is then compiled to a binary format which is passed to the Xen hypervisor at boot time.

For each vm that is started, the vm configuration file will hold information on which category the vm belongs to. For instance:

access_control = ["policy=,label=system_u:system_r:domU_t"] Expresses that the booted domain is a pv guest.

B.3.2. The CaaSsecurity module

Neither of the two distributed xsm plugins satisfied our needs. While acm is limited in expressiveness, the Flask approach did not compile for us and did

not cover all the hooks we wanted.1 (Though if these problems did not exist, Flask might have been a good candidate.) On the other hand, we were required to make numerous changes to the xsm hooks as they were laid out by default. • For example, many hooks would record the target of a certain hypercall, but only a few hooks would record the invoking domain. This is a reflection of the original design of xsm where it serves as an addition to the existing privileged vs. unprivileged access control — i.e., it bluntly assumes the invoker is dom0_{for certain hypercalls. Hence, we expanded many xsm} hooks to allow for our disaggregation of dom0 privileges.

• Furthermore, not all hypercalls were fitted with xsm hooks.

As a result of these considerations, we decided to create our own xsm module which we simply named the caas xsm (or security) module.

From one to two privileged domains. For our xsm module, we first asked ourselves the question what the division of responsibilities between dom0and domt is. In vanilla Xen, dom0is many different roles at the same time. However, in our design we discern the following division of privileges.

• Dom0_{: disk and network emulation, vm management, platform configura-} tion (e.g., system clock, power management).

• Domt: domain building, controlling the tpm.

Our conclusion is that the situation is not black-and-white, rather, dom0and domt together share the privileged hypercalls (with the critical notion that, for our requirements, domt exclusively controls the memory). With the assignment of roles laid out, the next step was to investigate all the hypercalls found in the Xen source code. The result of this large analysis is found in appendix F — for each hypercall we analyzed under which responsibility the hypercall falls. In summary, there are four categories:

1. hypercalls belonging to dom0; 2. hypercalls belonging to domt; 3. hypercalls assigned to both; 4. hypercalls assigned to neither.

B. Implementation details

Finally, in the implementation step of our caas security module, we im- plemented our security module using the xsm hooks. A detailed overview of which xsm hooks we used is presented in appendix G. For each xsm hook, we applied the category restriction defined in the assignment of hypercalls found in Table F.1.

In our design, the caas security module is compiled into Xen and enabled at all times. We remark that removing the module from the compilation will lead, obviously, to a different hash of the Xen hypervisor, and thus be detected as tampering by the appraising party.

Remarks regardingCaaSsecurity module.

• Since domt is part of the tcb, we could have decided to make domt omnipotent and give domt access to all available hypercalls. However, this would not correspond with the principle of least privilege; moreover, we clearly defined the responsibilities for domt, so it is sensible to restrict domt to only those hypercalls that it needs to fulfill its duties.

• We removed a set of privileged hypercalls by assigning them to neither dom0_{nor domt. The removal of these hypercalls follows from the division} of responsibilities — for instance, we did not assign the responsibility of “debugging vms” to any of the domains, hence, these hypercalls do not need to be enabled in a production environment. The small set of shared hypercalls are composed of overlapping hypercalls (e.g., unpausing a vm is needed for dom0’s management taks as well as for the domain builder in domt) or due to the innate nature of both work domains (e.g., writing to the Xen debug console is desired for all helper domains, both dom0 and domt).

• Implementing all the xsm hooks in correspondence with how we assigned the responsibilities is a considerable amount of work; in particular for those hooks which are not yet in the form desired for expressing our policy or for those hypercalls for which xsm hooks are vacant. Therefore, we chose to restrict our implementation to only the current available hooks. Notwithstanding that our caas security module can be improved, all the dangerous hypercalls — such as those used for introspection — have been curtailed properly in this implementation. For all intents and purposes, the caas security module provides full security against the adversary from the attacker model (section 3.1). Trial runs with our provisional caas security module did not lead to any instabilities, however, we cannot rule

out the possibility that our hypercall and xsm analysis in appendices F and G can be improved.