Re: [Xen-devel] [PATCH][ACM] kernel enforcement of vbd policies via blkback driver

[Reiner Sailer <sailer@xxxxxxxxxx>]

Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
wrote on 07/27/2006 01:19:17 PM:

> On Thu, 2006-07-27 at 18:06 +0100, Harry Butterworth wrote:
> > Even with local devices there is no security on the device side
of the
> > device driver.  Consider the case of a locally attached
sata drive
> > containing 2 partitions, one for each of two domains.  It's
not unheard
> > of for disk drives to write the data in the wrong place.  Or
read and
> > return the wrong block.  Happens all the time.
> 
> And there's all that unaudited code in the motherboard RAID
> implementation.  What's to say that isn't going to shuffle your
data
> between partitions?
> 

The separation / confinement can happen on the logical
level. You must trust the raid software mapping logical volumes into hardware
storage devices.

Your argumentation appears to be about "how highly
assured can you get". Since using RAID offers some security (redundancy..>),
people use it actually to store data they care about. If raid software
proves so bad that it messes up the data on its drives that it basically
wipes out the redundancy benefit, then one would imagine that it cannot
be successful in the market place (looking back at the few economic lessens
I enjoyed).

If you go to the end: on what hardware do you implement
your trusted proxy? Do you use a highly-assured independent cryptographic
coprocessor with tamper response/protection? 

There are application environments where one better
cares about this assurance level (abolutely!). It seems not (yet?) to be
a major application environment for Xen.

What this discussion teaches me is that we must be careful to enable different
trust models (and assurance goals) within Xen. Security for military or
high-assurance environments will likely look different from security for
commercial environments due to the differently motivated trade-offs.

Reiner
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel