WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xense-devel

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

To: mkang@xxxxxxxxxxxxxxxx
Subject: Re: [Xense-devel] Xen/sHype Access Control
From: Reiner Sailer <sailer@xxxxxxxxxx>
Date: Thu, 19 Jan 2006 22:58:01 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Stefan Berger <stefanb@xxxxxxxxxx>, xense-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 20 Jan 2006 04:05:44 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <003b01c61d46$73511e10$1c02000a@Myong1>
List-help: <mailto:xense-devel-request@lists.xensource.com?subject=help>
List-id: "A discussion list for those developing security enhancements for Xen." <xense-devel.lists.xensource.com>
List-post: <mailto:xense-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xense-devel>, <mailto:xense-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xense-devel>, <mailto:xense-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xense-devel-bounces@xxxxxxxxxxxxxxxxxxx

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
<Prev in Thread] Current Thread [Next in Thread>