Re: [Xense-devel] Xen/sHype Access Control

[Reiner Sailer <sailer@xxxxxxxxxx>]

xense-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 01/19/2006
05:19:44 PM:

> Xen 3.0/sHype provides a way to control access between domains. Simple
types
> can be associated with a domain that can be the basis for enforcing
an
> access control policy.

> Controlling access to physical devices is another important area because
> many of covert channels stem from sharing resources (physical devices
in
> this case). 

Yes. This is "unfinished" but necessary
work.

> Also such mechanism may provide an opportunity
to simplify
> assurance arguments. For example, if we create a mechanism to associate
> simple types to a physical device, sHype ACM can enforce an access
control
> policy.

This is an excellent observation. 

We discussed on the Xen summit the last two days also
the future work with regard to the ACM and your suggestions fits in there
very well.

While we have mostly completed the enforcement and
labeling inside the Xen hypervisor (domain structs, event-channels, shared
memory/grant tables), we now must move towards labeling resources outside
the direct control of the hypervisor because domains can share and communicate
through such devices indirectly.

There are two types of resources: physical resources (network card, disk,
etc.) and virtualized resources (virtual network interface, virtual block
device, ...) built on top of physical resources. I'll treat them separately
below:

Physical devices/resources:
---------------------------
Currently in Xen, physical resources are hosted exclusively
by domain 0. One reason is that if a virtual machine owned a network card
or disk, then by configuring the DMA in a manipulative way would allow
that user domain to overwrite memory anywhere in the system. With the foreseeable
upcoming of IO-MMU on Intel and AMD platforms, the DMA space for devices
can be restricted to memory owned by a domain and THEN, any user domain
can be allowed to own physical resources.

Therefore, labeling physical resources is necessary
in the long-term and it is good to start doing this early. While the example
policies already include labels for resources, the respective resources
are currently unlabeled.

Virtualized resources:
----------------------
To prevent overprovisioning of system peripherals,
the Xen/ACM security framework envisions that small trusted domains (today
domain 0) host a physical resource (say a network card or a storage device)
and create isolated virtual resources based on this physical resource,
e.g., some virtual disks. The virtualized resources can then be exclusively
assigned to different coalitions. The trusted hosting domain is responsible
to
a) isolate the virtual devices (e.g. virtual disks);
the stronger this isolation, the better it preserves the isolation between
coalitions using such virtual disks
b) enforce ACM security policy when domains request
access a virtual device (e.g., mount a virtual disk)

For this reason, such isolated virtual devices must
be labeled and can only be assigned to a single coalition. The hosting
domain then must decide if a domain requesting to mount a virtual disk
is authorized to do so based on the domain ID of the requesting domain
and the security label attached to the virtual disk. Explicit policies
must be followed when re-labeling disks (e.g., externally backup and then
securely delete all information on a virtual disk before re-labeling) to
ensure correct object-reuse (a well-known but still common security problem
that applies to any re-used resource with storage capacity).

Xen/ACM offer a hypervisor call by which a (privileged)
domain can retrieve an access control decision from the xen hypervisor
based on the currently enforced security policy. An example application
deploying this hypercall can be found in tools/security/get_decision.c.
Sample "in" parameters are a domain ID and a security reference
ssidref. The "out" parameter is the access control decision based
on the ssidref of the domain with id ID and the submitted ssidref with
regard to the currently enforced acm security policy.

> I would like to hear your comments on the above idea and the feasibility
of
> implementing the idea.

I believe this is a great idea and a necessary step.
It is feasible to implement labeling of physical and virtual resources.
Some working items that come to mind:

a) where to store the ssidref (label) for a physical
/ virtual resource ?
b) where to include the access control checks ?
    i. for virtual resources, netback and
blockback seem appropriate candidates for enforcement
   ii. for physical resources, xm create
(or who ever will enable the mapping of a physical device into a user domain)
might be a candidate for enforcement
c) caching of access control decisions required ?
   (depends on the application: mounting virtual block devices seems
not very performance critical)

Any ideas / comments / corrections ?

> Myong  
> 

Thanks
Reiner
_______________________________________________
Xense-devel mailing list
Xense-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xense-devel