xense-devel-bounces@lists.xensource.com 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@lists.xensource.com
http://lists.xensource.com/xense-devel