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

[Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

On Thu, 2006-07-27 at 13:53 -0400, Reiner Sailer wrote:
> 
> 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. 

_If_ you want to trust the whole chain from the device driver through an
unaudited binary blob on your motherboard or controller card to the disk
drive to map logical volumes into hardware storage devices _then_ the
separation / confinement can happen on the logical level.
If not then you can do the kind of encryption that I suggested.

> 
> Your argumentation appears to be about "how highly assured can you
> get".

No, I'm really thinking about a practically useful level of assurance.
RAID controller errors are a real problem in real life.  There is a need
to encrypt data written to disk for confidentiality purposes.  CPUs are
rapidly gaining cores that might take on encryption tasks.  It all seems
entirely reasonable to me.

> 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 lose a drive without RAID, you'll lose all your data.  If you
lose a drive with RAID, you'll get most of it back.  The RAID
implementation doesn't have to be perfect to achieve that.  A lot of
RAID implementations aren't perfect but they still have market share.
It's not black and white.

> 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?  

You have to trust the CPU to maintain isolation between domains so you
might as well use that, right?

> 
> 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. 

On the one hand there are different kinds of applications and on the
other, the different level of assurance you might want in your data
centre.

Say you have a cluster of xen machines with a single point of management
for the cluster.  If any individual domain goes down then you lose one
server but if the cluster as a whole goes down then you lose a big chunk
of your data centre.  You might be inclined to run the software that is
managing your data centre inside a domain with very high levels of
protection from, for example, erroneous devices.  It's not particularly
performance critical so you might as well.

Similarly, if someone gains access to the single point of management
that controls your data centre then they gain access to all your servers
and all your data so that's another reason why you might choose to run
that kind of code inside a domain with very high levels of assurance.

Harry.


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