Xen devel - Jul 2006 - [PATCH][ACM] kernel enforcement of vbd policies via blkback driver

This patch modifies the blkback driver to perform a security check 
(via an ACM get_decision hypercall) before connecting a vbd to a 
domain.  While the security checks performed in the xm tools are 
convenient for the users, the check added here is intended to 
strengthen the security guarantees.

Note that the security check in blkback is only enabled when 
ACM_SECURITY=y in Config.mk.

Signed-off-by: Bryan D. Payne <bdpayne@us.ibm.com>
Signed-off-by: Reiner Sailer <sailer@us.ibm.com>






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

On 24 Jul 2006, at 17:23, Bryan D. Payne wrote:
> This patch modifies the blkback driver to perform a security check 
> (via an ACM get_decision hypercall) before connecting a vbd to a 
> domain.  While the security checks performed in the xm tools are 
> convenient for the users, the check added here is intended to 
> strengthen the security guarantees.
>
> Note that the security check in blkback is only enabled when 
> ACM_SECURITY=y in Config.mk.
>
> Signed-off-by: Bryan D. Payne <bdpayne@us.ibm.com>
> Signed-off-by: Reiner Sailer <sailer@us.ibm.com>
Wouldn''t this be better checked in the tool stack, rather than the 
particular block device driver (which is as likely to be blktap as 
blkback in future -- control tools would provide a point of common 
infrastructure to make this check, regardless of choice of actual 
backend driver)?

  -- Keir


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

> Wouldn''t this be better checked in the tool stack, rather than the
> particular block device driver (which is as likely to be blktap as
> blkback in future -- control tools would provide a point of common
> infrastructure to make this check, regardless of choice of actual
> backend driver)?
We decided to perform the check at this level based on the philosophy that
enforcement is most secure when it occurs closest to the point of access.
The code path from the xm tools to the point of access for a vbd is
substantial.  Most notably, data travels through the XenStore, where the
backend driver obtains the information used to connect the vbd to a domain.
If the only enforcement was in xm tools, then any other process could add
data to the XenStore, effectively bypassing the security enforcement.

You probably noticed that our previous patch to xm tools also performs this
security check.  The motivation for performing the check at the xm tools
level is to provide meaningful feedback to users.  If we didn''t perform
the
check at the xm tools level, the user would only notice that the vbd failed
to connect and would have to look into /var/log/messages to discover the
reason.  This is because it is hard to pass an error condition (e.g.,
access denied) from the backend driver to the xm tools.

For these reasons, we feel that it is most appropriate to perform the check
in xm tools *and* at the point of access.  If you envision users using
blktap to replace blkback, then I believe that we should add similar hooks
to blktap.

-bryan


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

Bryan D Payne/Watson/IBM wrote on 07/24/2006 04:09:52 PM:
> > Wouldn''t this be better checked in the tool stack, rather
than the
> > particular block device driver (which is as likely to be blktap as 
> > blkback in future -- control tools would provide a point of common 
> > infrastructure to make this check, regardless of choice of actual 
> > backend driver)?
> We decided to perform the check at this level based on the 
> philosophy that enforcement is most secure when it occurs closest to
> the point of access.  The code path from the xm tools to the point 
> of access for a vbd is substantial.  Most notably, data travels 
> through the XenStore, where the backend driver obtains the 
> information used to connect the vbd to a domain.  If the only 
> enforcement was in xm tools, then any other process could add data 
> to the XenStore, effectively bypassing the security enforcement.
> 
> You probably noticed that our previous patch to xm tools also 
> performs this security check.  The motivation for performing the 
> check at the xm tools level is to provide meaningful feedback to 
> users.  If we didn''t perform the check at the xm tools level, the 
> user would only notice that the vbd failed to connect and would have
> to look into /var/log/messages to discover the reason.  This is 
> because it is hard to pass an error condition (e.g., access denied) 
> from the backend driver to the xm tools.
Bryan''s differentiation makes sense to me. The hooks serve different 
purposes:

The xm tools hook is the "usability hook" that ensures users that
domains
that get started actually can access their resources.

The block-backend hook is the "enforcement hook" that independently 
enforces access control at the time when a resource is mounted.

Right now, both hooks are in the ''large'' Domain0. I can
imagine that the
xm create resource validation hook eventually moves into a Xen management 
GUI that verifies at management time if a domain configuration is 
"policy-conform". The block-backend hook could eventually move
together
with the block-backend device into a block device domain for run-time 
policy enforcement.

Reiner

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

On 25 Jul 2006, at 01:21, Reiner Sailer wrote:
> Bryan''s differentiation makes sense to me. The hooks serve
different
> purposes:
>
> The xm tools hook is the "usability hook" that ensures users that
> domains that get started actually can access their resources.
>
> The block-backend hook is the "enforcement hook" that
independently
> enforces access control at the time when a resource is mounted.
>
> Right now, both hooks are in the ''large'' Domain0. I can
imagine that
> the xm create resource validation hook eventually moves into a Xen 
> management GUI that verifies at management time if a domain 
> configuration is "policy-conform". The block-backend hook could 
> eventually move together with the block-backend device into a block 
> device domain for run-time policy enforcement.
The tools hook is not just a usability/conformity check. The check 
ensures that the tools will not set up entries in xenstore that would 
allow blkback to create a non-conformant vbd. So there is no way for a 
guest to trick blkback into creating a non-conformant vbd: it can only 
connect to vbds specified in its config file or added later via the 
vbd-add xm hotplug command. The tools stack should perform its 
compiance checks on both ''xm create'' and ''xm
vbd-add'', and that should
be sufficient.

You have a point about it being nice to check things at the lowest 
possible level, but I''m not inclined to add extra crud into the device 
drivers for this unless more people scream for it. :-)

  -- Keir


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

> The tools hook is not just a usability/conformity check. The check
> ensures that the tools will not set up entries in xenstore that would
> allow blkback to create a non-conformant vbd. So there is no way for a
> guest to trick blkback into creating a non-conformant vbd: it can only
> connect to vbds specified in its config file or added later via the
> vbd-add xm hotplug command. The tools stack should perform its
> compiance checks on both ''xm create'' and ''xm
vbd-add'', and that should
> be sufficient.
My concern is that security is now relying on the correctness of all code
that can write to the xenstore.  The quantity of code that does this will
likely continue to grow, and even include third party tools.  If any of
this code attachs a vbd to a domain without performing a security check,
then the security would be bypassed.

Of course, the situation should be good for now because the xm tools patch
that we recently provided does perform the necessary security checks for
''xm create'' and ''xm block-attach''.  However,
we will need to continuously
be aware of changes that could bypass these checks.
> You have a point about it being nice to check things at the lowest
> possible level, but I''m not inclined to add extra crud into the
device
> drivers for this unless more people scream for it. :-)
Ok, I can certainly understand this viewpoint.  Given your concerns, I
think that it makes sense to not include the patch at this time.  If the
security concerns that I mentioned above turn into reality, we can always
take a second look at this lower-level enforcement.

Thanks,
bryan


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

>> The tools hook is not just a usability/conformity check. The check
>> ensures that the tools will not set up entries in xenstore that would
>> allow blkback to create a non-conformant vbd. So there is no way for a
>> guest to trick blkback into creating a non-conformant vbd: it can only
>> connect to vbds specified in its config file or added later via the
>> vbd-add xm hotplug command. The tools stack should perform its
>> compiance checks on both ''xm create'' and ''xm
vbd-add'', and that should
>> be sufficient.
>
>My concern is that security is now relying on the correctness of all code
>that can write to the xenstore.  The quantity of code that does this will
>likely continue to grow, and even include third party tools.  If any of
>this code attachs a vbd to a domain without performing a security check,
>then the security would be bypassed.
There still a major dependency on xenstore; it''s pretty much part of
the
TCB at present. I know some folks have been thinking about how to
''secure''
it more comprehensively while allowing integration with whatever ACM 
policy is in force. I think this is a more promising approach than an ad 
hoc extra check in blkback. 


cheers,

S.

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

Keir Fraser wrote:
> 
> The tools hook is not just a usability/conformity check. The check 
> ensures that the tools will not set up entries in xenstore that would 
> allow blkback to create a non-conformant vbd. So there is no way for a 
> guest to trick blkback into creating a non-conformant vbd: it can only 
> connect to vbds specified in its config file or added later via the 
> vbd-add xm hotplug command. The tools stack should perform its compiance 
> checks on both ''xm create'' and ''xm
vbd-add'', and that should be sufficient.
Yes, but that relies on the tools being correct and invulnerable to 
attacks like buffer overflow. Further, it does not disallow an 
alternative tool from bypassing or corrupting the conformance and 
authorization policy. Any program with the ability to open a socket to 
xenstore can open the way. Allowing the checks within the hypervisor is 
much safer against these types of attacks or errors.


Mike

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

On 26 Jul 2006, at 14:25, Mike D. Day wrote:
>> The tools hook is not just a usability/conformity check. The check 
>> ensures that the tools will not set up entries in xenstore that would 
>> allow blkback to create a non-conformant vbd. So there is no way for 
>> a guest to trick blkback into creating a non-conformant vbd: it can 
>> only connect to vbds specified in its config file or added later via 
>> the vbd-add xm hotplug command. The tools stack should perform its 
>> compiance checks on both ''xm create'' and ''xm
vbd-add'', and that
>> should be sufficient.
>
> Yes, but that relies on the tools being correct and invulnerable to 
> attacks like buffer overflow. Further, it does not disallow an 
> alternative tool from bypassing or corrupting the conformance and 
> authorization policy. Any program with the ability to open a socket to 
> xenstore can open the way. Allowing the checks within the hypervisor 
> is much safer against these types of attacks or errors.
If an attacker has access to the control plane (essentially anything 
with root privileges in domain0) what is to stop him from creating his 
own domain, with security credentials allowing it to communicate with 
domains A and B, and with its own proxy comms driver for circumventing 
any Xen checks that are intended to prevent communication between A and 
B?

  -- Keir


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

[For xense readers, please read the earlier mails in this
 email-thread on xen-devel (Reiner)]

Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote on 07/26/2006 09:49:46 AM:
> 
> On 26 Jul 2006, at 14:25, Mike D. Day wrote:
> 
> >> The tools hook is not just a usability/conformity check. The check
> >> ensures that the tools will not set up entries in xenstore that
would
> >> allow blkback to create a non-conformant vbd. So there is no way
for
> >> a guest to trick blkback into creating a non-conformant vbd: it
can
> >> only connect to vbds specified in its config file or added later
via
> >> the vbd-add xm hotplug command. The tools stack should perform its
> >> compiance checks on both ''xm create'' and
''xm vbd-add'', and that
> >> should be sufficient.
> >
> > Yes, but that relies on the tools being correct and invulnerable to 
> > attacks like buffer overflow. Further, it does not disallow an 
> > alternative tool from bypassing or corrupting the conformance and 
> > authorization policy. Any program with the ability to open a socket to
> > xenstore can open the way. Allowing the checks within the hypervisor 
> > is much safer against these types of attacks or errors.
> 
> If an attacker has access to the control plane (essentially anything 
> with root privileges in domain0) what is to stop him from creating his 
> own domain, with security credentials allowing it to communicate with 
> domains A and B, and with its own proxy comms driver for circumventing 
> any Xen checks that are intended to prevent communication between A and 
> B?
> 
>   -- Keir
this is not necessarily about attackers. It is simply that we anticipate 
many tools that manage the configuration/life-cycle management of domains 
and it is very difficult for us to screen all these developments to make 
sure that such tools do not introduce commands that forget about the 
labeling/label checking accidentally. If they do, resource access control 
can silently fail.

For example, the Xen hypervisor always checks that a domain has a valid 
security label when it is started on an ACM-enabled Xen or no label if it 
is started on Xen with ACM off. The hypervisor layer can however not check 
resource labels but relies on the VMM resource virtualization to do this 
(currently Domain0, in general the resource hosting domain).

I understand Keir''s current decision (relying on resource label checks
far
in the user space of the resource hosting domain) to be the result of a 
trade-off between (a) minimizing the Xen linux-sparse tree (the burdens 
related to getting Xen support quickly into Linux) and (b) the size of 
"the code required to do the right thing"  to achieve policy compliant
resource access control.

Thanks
Reiner

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

Keir Fraser wrote:
> 
> On 26 Jul 2006, at 14:25, Mike D. Day wrote:
> 
>>> The tools hook is not just a usability/conformity check. The check 
>>> ensures that the tools will not set up entries in xenstore that
would
>>> allow blkback to create a non-conformant vbd. So there is no way
for
>>> a guest to trick blkback into creating a non-conformant vbd: it can
>>> only connect to vbds specified in its config file or added later
via
>>> the vbd-add xm hotplug command. The tools stack should perform its 
>>> compiance checks on both ''xm create'' and
''xm vbd-add'', and that
>>> should be sufficient.
>>
>> Yes, but that relies on the tools being correct and invulnerable to 
>> attacks like buffer overflow. Further, it does not disallow an 
>> alternative tool from bypassing or corrupting the conformance and 
>> authorization policy. Any program with the ability to open a socket to 
>> xenstore can open the way. Allowing the checks within the hypervisor 
>> is much safer against these types of attacks or errors.
> 
> If an attacker has access to the control plane (essentially anything 
> with root privileges in domain0) what is to stop him from creating his 
> own domain, with security credentials allowing it to communicate with 
> domains A and B, and with its own proxy comms driver for circumventing 
> any Xen checks that are intended to prevent communication between A and B?
It''s all about defense in depth. It shouldn''t be possible for
a
privilege escalation on dom0 to automatically compromise all the running 
domains. There should be hypervisor-level access control that authorizes 
changes to the access policy of a running domU. With the ability to 
store domain configuration remotely (coming in xend) we can then prevent 
a privilege escalation and a restart from compromising user domains.

Mike


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

On 26 Jul 2006, at 18:46, Mike D. Day wrote:
>> If an attacker has access to the control plane (essentially anything 
>> with root privileges in domain0) what is to stop him from creating 
>> his own domain, with security credentials allowing it to communicate 
>> with domains A and B, and with its own proxy comms driver for 
>> circumventing any Xen checks that are intended to prevent 
>> communication between A and B?
>
> It''s all about defense in depth. It shouldn''t be possible
for a
> privilege escalation on dom0 to automatically compromise all the 
> running domains. There should be hypervisor-level access control that 
> authorizes changes to the access policy of a running domU. With the 
> ability to store domain configuration remotely (coming in xend) we can 
> then prevent a privilege escalation and a restart from compromising 
> user domains.
Not sure I understand your answer, but if you have root on domain0 
there''s nothing to stop you circumventing xend entirely. The problem 
here is that dom0 is in the TCB: solutions might be either to lock down 
domain0 (very restricted remote access) to reduce risk of privilege 
escalation, or move the core control logic elsewhere (a mini-domain of 
some sort) and reduce the privileges of domain0 (the biggest part of 
the TCB). In the current situation with dom0: you show me a ''hack 
proof'' set of access-control checks and I''m sure I can
describe a
workaround for a privileged attacker in dom0. For example, dom0 can map 
any other domain''s memory, so it''s trivial for an attacker to
steal
secrets.

  -- Keir


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

Keir Fraser wrote:
> 
> On 26 Jul 2006, at 18:46, Mike D. Day wrote:
> 
>>> If an attacker has access to the control plane (essentially
anything
>>> with root privileges in domain0) what is to stop him from creating 
>>> his own domain, with security credentials allowing it to
communicate
>>> with domains A and B, and with its own proxy comms driver for 
>>> circumventing any Xen checks that are intended to prevent 
>>> communication between A and B?
>>
>> It''s all about defense in depth. It shouldn''t be
possible for a
>> privilege escalation on dom0 to automatically compromise all the 
>> running domains. There should be hypervisor-level access control that 
>> authorizes changes to the access policy of a running domU. With the 
>> ability to store domain configuration remotely (coming in xend) we can 
>> then prevent a privilege escalation and a restart from compromising 
>> user domains.
> 
> Not sure I understand your answer, but if you have root on domain0 
> there''s nothing to stop you circumventing xend entirely. The
problem
> here is that dom0 is in the TCB: solutions might be either to lock down 
Eventually we need to make authorization role-based instead of just the 
superuser and everyone else. In addition the hypervisor should not 
automatically trust dom0. Also, running domains should not automatically 
trust dom0. I realize that this is a lot of evolution from now 
(including changes to the dom0 hypercalls) but putting access control 
hooks into the hypervisor and its drivers is a small step in this 
direction. Not arguing for accepting the patch today, just suggesting we 
start to think about a different approach.

Mike
> domain0 (very restricted remote access) to reduce risk of privilege 
> escalation, or move the core control logic elsewhere (a mini-domain of 
> some sort) and reduce the privileges of domain0 (the biggest part of the 
> TCB). In the current situation with dom0: you show me a ''hack
proof'' set
> of access-control checks and I''m sure I can describe a workaround
for a
> privileged attacker in dom0. For example, dom0 can map any other 
> domain''s memory, so it''s trivial for an attacker to steal
secrets.


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

I''m unconvinced that access control checks in the drivers are really a
good, or even a necessarily low-level solution.  From a security
perspective, I think that we should then of xenstore to be a
lower-level entity than drivers, which are effectively just
applications that use interdomain comms mechanisms offered by the
hypervisor.

You''re got in-hypervisor checks for primitives like grant tables and
event channels.  These on their own let you enforce very general
policy, e.g. "domain a isn''t allowed to communicate with domain
b".
The checks that you want to put into the block drivers aim to do a
more specific thing: specifically check that dom a and dom b are
allowed to communicate for block devices.  The problem is that (as
keir mentioned) failing an access control check here certainly doesn''t
stop me from building an alternate comms driver that
does block and doesn''t have the AC check.  The lack of hooks in
blocktap in the patch are an illustration of this.

I think that the correct way to tackle this one is to treat XenStore
as having a high-level-semantic understanding of inter-VM comms, and
that it is the place where a lot of this sort of fine-grained AC
should be driven.  A security policy for block devices integrated with
xenstore would be able to (a) aprove split block drivers for use in
the first place by allowing /vbd subdirectories to be created and
watches to be attached to them, (b) enforce that the block protocol
met a security-policy, potentially even validating messages to avoid
things like buffer overflow, and (c) drive lower-level access control,
for instance by triggering access clearance to the specific granted
shared emeory page to be used for block comms.

Disagregating the store from the rest of dom0 is also an obvious step
along this path.

The current in-hypervisor AC checks make sense as the hypervisor
interfaces are narrow.  Using the store as the next level of AC allows
us to still do things in a os- and tools- agnostic manner.  Hacking AC
checks piecemeal into drivers seems like a harder thing to make
comprehensive.

a.

On 7/26/06, Mike D. Day <ncmike@us.ibm.com> wrote:
> Keir Fraser wrote:
> >
> > On 26 Jul 2006, at 18:46, Mike D. Day wrote:
> >
> >>> If an attacker has access to the control plane (essentially
anything
> >>> with root privileges in domain0) what is to stop him from
creating
> >>> his own domain, with security credentials allowing it to
communicate
> >>> with domains A and B, and with its own proxy comms driver for
> >>> circumventing any Xen checks that are intended to prevent
> >>> communication between A and B?
> >>
> >> It''s all about defense in depth. It shouldn''t be
possible for a
> >> privilege escalation on dom0 to automatically compromise all the
> >> running domains. There should be hypervisor-level access control
that
> >> authorizes changes to the access policy of a running domU. With
the
> >> ability to store domain configuration remotely (coming in xend) we
can
> >> then prevent a privilege escalation and a restart from
compromising
> >> user domains.
> >
> > Not sure I understand your answer, but if you have root on domain0
> > there''s nothing to stop you circumventing xend entirely. The
problem
> > here is that dom0 is in the TCB: solutions might be either to lock
down
>
> Eventually we need to make authorization role-based instead of just the
> superuser and everyone else. In addition the hypervisor should not
> automatically trust dom0. Also, running domains should not automatically
> trust dom0. I realize that this is a lot of evolution from now
> (including changes to the dom0 hypercalls) but putting access control
> hooks into the hypervisor and its drivers is a small step in this
> direction. Not arguing for accepting the patch today, just suggesting we
> start to think about a different approach.
>
> Mike
>
> > domain0 (very restricted remote access) to reduce risk of privilege
> > escalation, or move the core control logic elsewhere (a mini-domain of
> > some sort) and reduce the privileges of domain0 (the biggest part of
the
> > TCB). In the current situation with dom0: you show me a ''hack
proof'' set
> > of access-control checks and I''m sure I can describe a
workaround for a
> > privileged attacker in dom0. For example, dom0 can map any other
> > domain''s memory, so it''s trivial for an attacker to
steal secrets.
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

andrew.warfield@gmail.com wrote on 07/26/2006 02:50:10 PM:
> I''m unconvinced that access control checks in the drivers are
really a
> good, or even a necessarily low-level solution.  From a security
> perspective, I think that we should then of xenstore to be a
> lower-level entity than drivers, which are effectively just
> applications that use interdomain comms mechanisms offered by the
> hypervisor.
> 
> You''re got in-hypervisor checks for primitives like grant tables
and
> event channels.  These on their own let you enforce very general
> policy, e.g. "domain a isn''t allowed to communicate with
domain b".
> The checks that you want to put into the block drivers aim to do a
> more specific thing: specifically check that dom a and dom b are
> allowed to communicate for block devices.  The problem is that (as
> keir mentioned) failing an access control check here certainly
doesn''t
> stop me from building an alternate comms driver that
> does block and doesn''t have the AC check.  The lack of hooks in
> blocktap in the patch are an illustration of this.
The original patch does not cover blocktrap. This might as well illustrate 
that there is another patch to be done (and that we are not done yet, also 
consider netback). If the current patch doesn''t get in because there is
no
similar patch to blocktrap, then this can be fixed. I know about blocktrap 
but I''d like first to know if working on the patch makes sense, i.e.,
if
it will be acceptable in general (leaving room for rejecting bad code of 
course).

This was not the original argumentation and the effect of not having 
blocktrap security support could be mitigated by compiling the kernel with 
only blockback support until this support is established. While Xen is in 
rapid development, it will now and then happen that new critical sharing 
mechanisms are introduced; those will always need to be examined and 
equipped with the appropriate security hook to consistently enforce the 
security goals.

It is much easier to ensure that a "supported " kernel is running
(e.g.,
using authenticated or secure boot) in a device domain than to establish 
these properties in domain0 user space management code.

As Andrew mentions correctly, other security mechanisms can be applied 
independently on top of the hypervisor security policy; e.g., by a 
security policy inside Domain0 to ''lock it down'' (layering
security is one
principle of building secure systems). However, keeping policies of 
different layers (fine-grained OS vs coarse grained VMM policies) separate 
is one of our major goals.

Moving the resource hooks exclusively into domain0 will not help the 
disaggregation today and indeed might result in a movement into the 
opposite direction: it ensures that the confinement capabilities remain 
dependent on the whole management environment. Introducing enforcement 
hooks in the kernel drivers (at least block[trap/back] and netback) 
reduces dependencies on domain0, even if today other dependencies persist.

As Keir encouraged earlier: please don''t hesitate to join in if you
have
some viewpoint you''d like to discuss. This seems broader than the
simple
patch discussion that started it. And please try to keep
''xense-devel'' in
the cc because this topic is interesting to the security list.

Reiner

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

On Wed, 2006-07-26 at 11:50 -0700, Andrew Warfield
wrote:
> I''m unconvinced that access control checks in the drivers are
really a
> good, or even a necessarily low-level solution.  From a security
> perspective, I think that we should then of xenstore to be a
> lower-level entity than drivers, which are effectively just
> applications that use interdomain comms mechanisms offered by the
> hypervisor.
Agree.
> 
> You''re got in-hypervisor checks for primitives like grant tables
and
> event channels.  These on their own let you enforce very general
> policy, e.g. "domain a isn''t allowed to communicate with
domain b".
> The checks that you want to put into the block drivers aim to do a
> more specific thing: specifically check that dom a and dom b are
> allowed to communicate for block devices.  The problem is that (as
> keir mentioned) failing an access control check here certainly
doesn''t
> stop me from building an alternate comms driver that
> does block and doesn''t have the AC check.  The lack of hooks in
> blocktap in the patch are an illustration of this.
Agree.
> 
> I think that the correct way to tackle this one is to treat XenStore
> as having a high-level-semantic understanding of inter-VM comms, and
> that it is the place where a lot of this sort of fine-grained AC
> should be driven.  A security policy for block devices integrated with
> xenstore would be able to (a) aprove split block drivers for use in
> the first place by allowing /vbd subdirectories to be created and
> watches to be attached to them, (b) enforce that the block protocol
> met a security-policy, potentially even validating messages to avoid
> things like buffer overflow, and (c) drive lower-level access control,
> for instance by triggering access clearance to the specific granted
> shared memory page to be used for block comms.
Mostly agree.

I think it ought to be possible to create a machine description of any
interdomain protocol including the guarantees provided by all the
parties.  The combination of xenstore, xen and the parties involved can
then police that the protocol is observed.

The policing has to be designed such that it can''t be subverted so xen
must provide the foundation but as little as possible.  Xenstore
provides the trusted configuration information to xen to configure the
primitives (for example, xenstore holds the reference to the correct
machine description of the protocol).  Then the front-end and back-end
try to use the protocol.  If the FE or the BE detect a protocol
violation, the primitives are sufficient to be able to reliably
distinguish which party was in error so it can be forcibly reset.
We might want to be able to detect and reset in the case when one or
both parties are in error but neither complain too.

I think I spent about 2 mins on this with Ian about a year ago.

This is what you are saying above except that I''d want to do it without
embedding any protocol specific knowledge in the tools apart from a
protocol description file for each supported protocol.

So, in my version xenstore doesn''t have any high-level semantic
understanding of the protocols, just a generic mechanism for handling
any protocol.

Also, I think that role based access control can be done on a general
concept of a "resource" available in xenstore and the different
resource
classes can all reuse the same foundation.

This kind of thinking is another reason why there is a need for a small
library to sit between the hypervisor interdomain comms primitives and
the driver interdomain comms API.  We want that library to do the driver
resident part of policing the interdomain protocols since we can''t hope
that the driver authors are going to reimplement it correctly each time.
> Disagregating the store from the rest of dom0 is also an obvious step
> along this path.
Agree.
> 
> The current in-hypervisor AC checks make sense as the hypervisor
> interfaces are narrow.  Using the store as the next level of AC allows
> us to still do things in a os- and tools- agnostic manner.  Hacking AC
> checks piecemeal into drivers seems like a harder thing to make
> comprehensive.
Agree.

So basically, the xenstore++ is in a stripped down secured domain and
someone with role-based access privileges communicates with xenstore++
to connect a resource to a domain.  Xenstore++ checks the permissions
and sets up the connection where the protocol description to use is an
attribute of the resource class.  The protocol is policed and if it''s
violated then either the resource provider (BE) or consumer (FE) or both
get blown away.

There can be generic mechanisms in xenstore++ for colouring resources
and grouping roles etc to do fancy MAC stuff.


...or something like that.

Harry.
> 
> a.
> 
> On 7/26/06, Mike D. Day <ncmike@us.ibm.com> wrote:
> > Keir Fraser wrote:
> > >
> > > On 26 Jul 2006, at 18:46, Mike D. Day wrote:
> > >
> > >>> If an attacker has access to the control plane
(essentially anything
> > >>> with root privileges in domain0) what is to stop him from
creating
> > >>> his own domain, with security credentials allowing it to
communicate
> > >>> with domains A and B, and with its own proxy comms driver
for
> > >>> circumventing any Xen checks that are intended to prevent
> > >>> communication between A and B?
> > >>
> > >> It''s all about defense in depth. It
shouldn''t be possible for a
> > >> privilege escalation on dom0 to automatically compromise all
the
> > >> running domains. There should be hypervisor-level access
control that
> > >> authorizes changes to the access policy of a running domU.
With the
> > >> ability to store domain configuration remotely (coming in
xend) we can
> > >> then prevent a privilege escalation and a restart from
compromising
> > >> user domains.
> > >
> > > Not sure I understand your answer, but if you have root on
domain0
> > > there''s nothing to stop you circumventing xend entirely.
The problem
> > > here is that dom0 is in the TCB: solutions might be either to
lock down
> >
> > Eventually we need to make authorization role-based instead of just
the
> > superuser and everyone else. In addition the hypervisor should not
> > automatically trust dom0. Also, running domains should not
automatically
> > trust dom0. I realize that this is a lot of evolution from now
> > (including changes to the dom0 hypercalls) but putting access control
> > hooks into the hypervisor and its drivers is a small step in this
> > direction. Not arguing for accepting the patch today, just suggesting
we
> > start to think about a different approach.
> >
> > Mike
> >
> > > domain0 (very restricted remote access) to reduce risk of
privilege
> > > escalation, or move the core control logic elsewhere (a
mini-domain of
> > > some sort) and reduce the privileges of domain0 (the biggest part
of the
> > > TCB). In the current situation with dom0: you show me a
''hack proof'' set
> > > of access-control checks and I''m sure I can describe a
workaround for a
> > > privileged attacker in dom0. For example, dom0 can map any other
> > > domain''s memory, so it''s trivial for an
attacker to steal secrets.
> >
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> >
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

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

> 
> So basically, the xenstore++ is in a stripped down secured domain and
> someone with role-based access privileges communicates with xenstore++
> to connect a resource to a domain.  Xenstore++ checks the permissions
> and sets up the connection where the protocol description to use is an
> attribute of the resource class.  The protocol is policed and if
it''s
> violated then either the resource provider (BE) or consumer (FE) or both
> get blown away.
> 
> There can be generic mechanisms in xenstore++ for colouring resources
> and grouping roles etc to do fancy MAC stuff.
> 
> 
> ...or something like that.
> 
> Harry.
> 
Hmm... this is not how I see xenstore today. Did you discuss what it takes 
to implement the "++"?
(especially the part where you suggest moving xenstore in its on secured 
domain sounds very interesting)

Would this be a non-intrusive change to Xen?

Reiner


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

> I think it ought to be possible to create a machine description of any
> interdomain protocol including the guarantees provided by all the
> parties.  The combination of xenstore, xen and the parties involved can
> then police that the protocol is observed.
>
> The policing has to be designed such that it can''t be subverted so
xen
> must provide the foundation but as little as possible.  Xenstore
> provides the trusted configuration information to xen to configure the
> primitives (for example, xenstore holds the reference to the correct
> machine description of the protocol).  Then the front-end and back-end
> try to use the protocol.  If the FE or the BE detect a protocol
> violation, the primitives are sufficient to be able to reliably
> distinguish which party was in error so it can be forcibly reset.
> We might want to be able to detect and reset in the case when one or
> both parties are in error but neither complain too.
>
> I think I spent about 2 mins on this with Ian about a year ago.
>
> This is what you are saying above except that I''d want to do it
without
> embedding any protocol specific knowledge in the tools apart from a
> protocol description file for each supported protocol.
>
> So, in my version xenstore doesn''t have any high-level semantic
> understanding of the protocols, just a generic mechanism for handling
> any protocol.
I certainly didn''t mean to imply that this had to be a part of
xenstore itself.  But yes, I think we both agree.  In short, some
policy enforcement foo could sit along-side xenstore and validate the
way it is used to allow interdomain comms.  This foo could be largely
be based on access control checks of access to xenstore (creating
keys/directories, adding watches, etc.).  If this foo was actually the
system-wide policy engine, it could use things that it sees happening
in the store to admit lower-level operations.
> So basically, the xenstore++ is in a stripped down secured domain and
> someone with role-based access privileges communicates with xenstore++
> to connect a resource to a domain.  Xenstore++ checks the permissions
> and sets up the connection where the protocol description to use is an
> attribute of the resource class.  The protocol is policed and if
it''s
> violated then either the resource provider (BE) or consumer (FE) or both
> get blown away.
Sounds good.  Although, as we''ve both posited above, xenstore
doesn''t
really need to change except to have some AC checks and to be broken
off into a stub domain.  And the stub domain is really bonus points at
this stage, as a lot of what we''re discussing could proceed in
parallel with disaggregation.

Your points about resource colouring are interesting, but I think they
may a few steps down the road.  Once two VMs are allowed to do shared
memory communication it''s a little moot as to what they are using it
for -- disk/net/sweet nothings -- so the real benefit to AC in
xenstore is in tool-independent per-resource admission control, and
making sure that VMs follow established driver protocols.  (This
facility would be generally useful as a means of shaking out split
driver protocol bugs too by the way. ;) )

Getting back to Reiner''s point about block AC checks in the backend
drivers:  I think that if you trust the backend code sufficiently to
_have_ the AC check in the first place, then you trust it implicitly
to make correct use of page sharing etc.  So why not implement the
tests for (a) permission to talk to the specified frontend, and (b)
permission for that frontend to talk to the specified disk at the
store level (which is where the two drivers are negotiating things
anyway), and just use existing in-hypervisor AC mechanisms to control
whether the backend is allowed to map the comms page and connect event
channels.

a.

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

On Wed, 2006-07-26 at 16:04 -0700, Andrew Warfield
wrote:
> I certainly didn''t mean to imply that this had to be a part of
> xenstore itself.  But yes, I think we both agree.  In short, some
> policy enforcement foo could sit along-side xenstore and validate the
> way it is used to allow interdomain comms.  This foo could be largely
> be based on access control checks of access to xenstore (creating
> keys/directories, adding watches, etc.).  If this foo was actually the
> system-wide policy engine, it could use things that it sees happening
> in the store to admit lower-level operations.
I don''t think I see it quite like that.  I think there should be a set
of low level primitives which are necessary and sufficient to implement
the generic resource access control and protocol policing functions and
the primitives that actually get used should be a function of the
protocol description which is in turn an attribute of the resource
class.  So essentially the security stuff falls out in the wash in the
implementation of the manipulations of the resource configuration rather
than being a bolt-on on the side that is watching what is going on
(having any kind of `watcher` necessarily involves duplication of effort
and bad coupling since both the doer and the watcher must contain
knowledge of the task at hand).

So I''m sort of turning xenstore inside out: currently xenstore is a
generic mechanism with content defined by the clients in the FE and BE
and I''d say that xenstore instead needs to define a fixed set of
primitives that support generic protocol description and access control
mechanisms.

This for example implies a standard set of high-level interdomain
communication mechanisms of which any particular protocol would use a
subset.  This is to be contrasted with the current implementation where
the FE and BE can define an arbitrary manipulation of xenstore to
establish a bespoke high-level interdomain communication mechanism.

I think we do agree about the high level picture though.
> Your points about resource colouring are interesting, but I think they
> may a few steps down the road.  Once two VMs are allowed to do shared
> memory communication it''s a little moot as to what they are using
it
> for -- disk/net/sweet nothings 
A resource colouring example would be something like having a group of
''red'' resources including ''red'' domains and
a set of ''green'' resources
including ''green'' domains and perhaps a global policy to fail
any
attempt to connect anything red to anything green even via a resource of
another colour.  This probably has some mapping onto an ACL concept.
I''m not really into this stuff.
> -- so the real benefit to AC in
> xenstore is in tool-independent per-resource admission control, and
> making sure that VMs follow established driver protocols.  (This
> facility would be generally useful as a means of shaking out split
> driver protocol bugs too by the way. ;) )
Designing the protocol independently of the implementation and having a
specification would also be an improvement over having to reverse
engineer it from the existing code only to find that it was broken ;)
> Getting back to Reiner''s point about block AC checks in the
backend
> drivers:  I think that if you trust the backend code sufficiently to
> _have_ the AC check in the first place, then you trust it implicitly
> to make correct use of page sharing etc.  So why not implement the
> tests for (a) permission to talk to the specified frontend, and (b)
> permission for that frontend to talk to the specified disk at the
> store level (which is where the two drivers are negotiating things
> anyway), and just use existing in-hypervisor AC mechanisms to control
> whether the backend is allowed to map the comms page and connect event
> channels.
I might be missing the point in the above paragraph.

I''m not sure that we have to trust the BE at all.  It''s
possible to
insert a trusted intermediate encrypt/decrypt/versioning/digital
signature layer so we don''t have to trust the BE with resource
isolation
or returning the right data and the FE can use mirroring for redundancy
against data lost by the BE.

So I think it''s better for both a and b to be done by a trusted third
party which is smaller, easier to verify and subject to less frequent
change than a whole kernel.

Harry.


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

On Wed, 2006-07-26 at 18:51 -0400, Reiner Sailer wrote:
> 
> 
> > 
> > So basically, the xenstore++ is in a stripped down secured domain
> and
> > someone with role-based access privileges communicates with xenstore
> ++
> > to connect a resource to a domain.  Xenstore++ checks the
> permissions
> > and sets up the connection where the protocol description to use is
> an
> > attribute of the resource class.  The protocol is policed and if
> it''s
> > violated then either the resource provider (BE) or consumer (FE) or
> both
> > get blown away.
> > 
> > There can be generic mechanisms in xenstore++ for colouring
> resources
> > and grouping roles etc to do fancy MAC stuff.
> > 
> > 
> > ...or something like that.
> > 
> > Harry.
> > 
> 
> Hmm... this is not how I see xenstore today. Did you discuss what it
> takes to implement the "++"? 
> (especially the part where you suggest moving xenstore in its on
> secured domain sounds very interesting) 
No.  I didn''t discuss what it would take to implement it.

Personally I''d start by defining a fault-tolerant cluster architecture
and then build it inside that.  That would be a fair bit of work
up-front but I think a lot of the significant use-cases demand it and it
would have a discriminating impact on the implementation.
> 
> Would this be a non-intrusive change to Xen? 
Probably not with my approach :-)
> 
> Reiner 

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

> > Getting back to Reiner''s point about block AC checks in the
backend
> > drivers:  I think that if you trust the backend code sufficiently to
> > _have_ the AC check in the first place, then you trust it implicitly
> > to make correct use of page sharing etc.  So why not implement the
> > tests for (a) permission to talk to the specified frontend, and (b)
> > permission for that frontend to talk to the specified disk at the
> > store level (which is where the two drivers are negotiating things
> > anyway), and just use existing in-hypervisor AC mechanisms to control
> > whether the backend is allowed to map the comms page and connect event
> > channels.
> 
> I might be missing the point in the above paragraph.
> 
> I''m not sure that we have to trust the BE at all.  It''s
possible to
> insert a trusted intermediate encrypt/decrypt/versioning/digital
> signature layer so we don''t have to trust the BE with resource
isolation
> or returning the right data and the FE can use mirroring for redundancy
> against data lost by the BE.
> 
> So I think it''s better for both a and b to be done by a trusted
third
> party which is smaller, easier to verify and subject to less frequent
> change than a whole kernel.
> 
> Harry.
> 
Regarding the suggestion not to trust BE/device domain (this seems to be a 
very interesting discussion point):

I encourage to build BE/device domains so that they are trusted. To start 
the discussion, I state some of MY PERSONAL thoughts regarding the 
attacker model/trust model for sHype/ACM that support trusted BE/device 
domains.

Simplified Commercial-grade Guarantees:
i.  Confine workloads and resources so that viruses or other integrity 
problems don''t swap from one workload type into another
ii. Confine workloads and resources so that data does not leak from one 
workload to another
iii.Confinement will be no better or worse than the core hypervisor 
isolation (depends on the hypervisor/hardware sHype operates on, here Xen)

Simplified Attacker model / trust model for above guarantees:
i. Do not rely on cooperation of any user domain (ensure confinement even 
if user domains go rogue)
ii.Rely/trust on device domains and other domains that host multiple 
workload types to keep them separate

Risk management:
i. if a trusted domain becomes compromised, this affects only the workload 
types that it handles
ii.if a trusted domain becomes compromised, the workload types it handles 
can no longer be guaranteed to be confined against each other

So I am actually encouraging to trust minimal device domains that are 
carefully engineered if they serve different workloads.

Why? Here are my reasons (for discussion):

a) guest domains shall not be trusted (this is the whole point of having 
hypervisor level coarse grained security; it does not assume security in 
guest OS)
b) device domains can be generic and used by many guest domains, they run 
a very limited number of processes
   --> evaluation in the long-term seems most feasible for small domains 
with limited functionality that doesn''t change often
c) IF you don''t trust the device domain, then it can see only 
encrypted/signed data and you don''t get availability (assuming you
don''t
trust any device domain, then replication does not help availability 
because all can deny access at will in coordinated attacks)
   --> you need for each workload type another (trusted) domain that 
encrypts/signs
   --> you inherit performance overhead and key/other management overhead
   --> you introduce multiple trusted domains instead of a single one

My feeling is:
a) trusting a small number of specialized domains (device domains, 
security domains) scales because such domains should remain pretty stable 
and can run minimally configured kernels etc.
b.1) when people write backend drivers, they manage to handle much more 
complex things than a function that resolves access control
b.2) starting to get people to handle security the same way they handle 
memory management in their code seems a good step towards consolidating 
security (this is probably a quite controversial statement and valid 
mainly in the context of commercial COTS systems)

Concluding/summarizing: the device domain (BE) IS a trusted third party 
hosting shared hardware. I encourage discussions about why or under which 
circumstances moving the trust into yet another third party helps.

Reiner

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

On Thu, 2006-07-27 at 11:37 -0400, Reiner Sailer wrote:
> 
> 
> > > Getting back to Reiner''s point about block AC checks in
the
> backend
> > > drivers:  I think that if you trust the backend code sufficiently
> to
> > > _have_ the AC check in the first place, then you trust it
> implicitly
> > > to make correct use of page sharing etc.  So why not implement
the
> > > tests for (a) permission to talk to the specified frontend, and
> (b)
> > > permission for that frontend to talk to the specified disk at the
> > > store level (which is where the two drivers are negotiating
things
> > > anyway), and just use existing in-hypervisor AC mechanisms to
> control
> > > whether the backend is allowed to map the comms page and connect
> event
> > > channels.
> > 
> > I might be missing the point in the above paragraph.
> > 
> > I''m not sure that we have to trust the BE at all. 
It''s possible to
> > insert a trusted intermediate encrypt/decrypt/versioning/digital
> > signature layer so we don''t have to trust the BE with
resource
> isolation
> > or returning the right data and the FE can use mirroring for
> redundancy
> > against data lost by the BE.
> > 
> > So I think it''s better for both a and b to be done by a
trusted
> third
> > party which is smaller, easier to verify and subject to less
> frequent
> > change than a whole kernel.
> > 
> > Harry.
> >  
> 
> Regarding the suggestion not to trust BE/device domain (this seems to
> be a very interesting discussion point): 
I wasn''t suggesting not to have any trusted BE domains I was suggesting
that it might be useful to have some untrusted BE domains.
> 
> I encourage to build BE/device domains so that they are trusted. To
> start the discussion, I state some of MY PERSONAL thoughts regarding
> the attacker model/trust model for sHype/ACM that support trusted
> BE/device domains. 
> 
> Simplified Commercial-grade Guarantees: 
> i.  Confine workloads and resources so that viruses or other integrity
> problems don''t swap from one workload type into another 
> ii. Confine workloads and resources so that data does not leak from
> one workload to another 
> iii.Confinement will be no better or worse than the core hypervisor
> isolation (depends on the hypervisor/hardware sHype operates on, here
> Xen) 
> 
> Simplified Attacker model / trust model for above guarantees: 
> i. Do not rely on cooperation of any user domain (ensure confinement
> even if user domains go rogue) 
> ii.Rely/trust on device domains and other domains that host multiple
> workload types to keep them separate 
> 
> Risk management: 
> i. if a trusted domain becomes compromised, this affects only the
> workload types that it handles 
> ii.if a trusted domain becomes compromised, the workload types it
> handles can no longer be guaranteed to be confined against each other 
> 
> So I am actually encouraging to trust minimal device domains that are
> carefully engineered if they serve different workloads. 
I agree it is necessary to trust some minimal BE domains.  The question
is what kind of BE domains we want to trust.

I''d argue that domains doing complex device driver stuff and talking to
hardware devices tend to be full of code which is particularly difficult
to verify.  Say the domain decides to program the hardware to DMA over
the code which is performing the MAC checks for example.

I''d much prefer to only have to trust domains which are doing very pure
software only tasks that are simple and provably correct.  In the
example I gave, an intermediate domain which was doing some encryption
and decryption, versioning and digital encryption work.  It''s much
easier to prove that a domain like this is correct than a domain which
contains a hairy device driver.
> 
> Why? Here are my reasons (for discussion): 
> 
> a) guest domains shall not be trusted (this is the whole point of
> having hypervisor level coarse grained security; it does not assume
> security in guest OS) 
> b) device domains can be generic and used by many guest domains, they
> run a very limited number of processes 
>    --> evaluation in the long-term seems most feasible for small
> domains with limited functionality that doesn''t change often 
> c) IF you don''t trust the device domain, then it can see only
> encrypted/signed data and you don''t get availability (assuming you
> don''t trust any device domain, then replication does not help
> availability because all can deny access at will in coordinated
> attacks) 
>    --> you need for each workload type another (trusted) domain that
> encrypts/signs 
>    --> you inherit performance overhead and key/other management
> overhead 
>    --> you introduce multiple trusted domains instead of a single one 
> 
> My feeling is: 
> a) trusting a small number of specialized domains (device domains,
> security domains) scales because such domains should remain pretty
> stable and can run minimally configured kernels etc. 
> b.1) when people write backend drivers, they manage to handle much
> more complex things than a function that resolves access control 
No.  Generally they _almost_ manage to handle much more complex things.
> b.2) starting to get people to handle security the same way they
> handle memory management in their code seems a good step towards
> consolidating security (this is probably a quite controversial
> statement and valid mainly in the context of commercial COTS systems) 
Not a good idea to assume you are going to educate the world.  Better to
work with a solution that reduces the complexity of the work performed
by the majority of developers and then get someone who knows what they
are doing to do the hard bit.  Memory management is an interesting
choice of example on your part.  All of the Xen memory management is
broken as far as I''m concerned because there isn''t an up-front
resource
reservation strategy which, for example, allows some operations to fail
if memory is allocated by something else while the operation is in
progress.  So the developers we are working with don''t have a rigorous
approach for memory management and aren''t likely to do security
rigorously either.  (No offence intended!)
> Concluding/summarizing: the device domain (BE) IS a trusted third
> party hosting shared hardware. I encourage discussions about why or
> under which circumstances moving the trust into yet another third
> party helps. 
So, I think we mostly agree but I''d move the security checks into a
pure-software third party domain and have other pure-software domains
doing things like encryption etc and I''d try to minimise the amount of
trust given to any domain containing a real device driver.

I.e. try to only place trust in code which is actually easy to audit.


Also, if you look at how my solution scales...

untrusted driver domain <-> trusted encryption domain <-> FE-domain
                           hypervisor
                   trusted access control domain

...you''ll see that when you create a new be device driver you
don''t have
to audit any more code at all.  Which is optimal.

I''d still want to do all this analysis in the context of a FT cluster
architecture because the conclusions may be slightly different.

Harry.


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

On Thu, 2006-07-27 at 17:26 +0100, Harry Butterworth wrote:
> untrusted driver domain <-> trusted encryption domain <->
FE-domain
>                            hypervisor
>                    trusted access control domain
Another argument in favour of this kind of approach is that if your BE
is something like a fibrechannel driver for a SAN, there isn''t actually
any security on the SAN side of it so any guarantees provided by the
driver domain are pretty much worthless.

Harry.


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

Harry Butterworth <harry@hebutterworth.freeserve.co.uk> wrote on 
07/27/2006 12:36:43 PM:
> On Thu, 2006-07-27 at 17:26 +0100, Harry Butterworth wrote:
> 
> > untrusted driver domain <-> trusted encryption domain <->
FE-domain
> >                            hypervisor
> >                    trusted access control domain
> 
> Another argument in favour of this kind of approach is that if your BE
> is something like a fibrechannel driver for a SAN, there isn''t
actually
> any security on the SAN side of it so any guarantees provided by the
> driver domain are pretty much worthless.
> 
> Harry.
> 
We are talking about scalable, secure, and efficient local device 
virtualization. 

The argumentation for network devices is very different and also 
interesting. There is a whole new discussion about how to establish trust 
into remote parties.

Reiner

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

On Thu, 2006-07-27 at 12:58 -0400, Reiner Sailer wrote:
> 
> 
> Harry Butterworth <harry@hebutterworth.freeserve.co.uk> wrote on
> 07/27/2006 12:36:43 PM:
> 
> > On Thu, 2006-07-27 at 17:26 +0100, Harry Butterworth wrote:
> > 
> > > untrusted driver domain <-> trusted encryption domain
<->
> FE-domain
> > >                            hypervisor
> > >                    trusted access control domain
> > 
> > Another argument in favour of this kind of approach is that if your
> BE
> > is something like a fibrechannel driver for a SAN, there
isn''t
> actually
> > any security on the SAN side of it so any guarantees provided by the
> > driver domain are pretty much worthless.
> > 
> > Harry.
> > 
> 
> We are talking about scalable, secure, and efficient local device
> virtualization.  
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.
> 
> The argumentation for network devices is very different and also
> interesting. There is a whole new discussion about how to establish
> trust into remote parties. 
> 
> Reiner
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

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?


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

Harry Butterworth <harry@hebutterworth.freeserve.co.uk> wrote on 
07/27/2006 01:06:50 PM:
> On Thu, 2006-07-27 at 12:58 -0400, Reiner Sailer wrote:
> > 
> > 
> > Harry Butterworth <harry@hebutterworth.freeserve.co.uk> wrote on
> > 07/27/2006 12:36:43 PM:
> > 
> > > On Thu, 2006-07-27 at 17:26 +0100, Harry Butterworth wrote:
> > > 
> > > > untrusted driver domain <-> trusted encryption domain
<->
> > FE-domain
> > > >                            hypervisor
> > > >                    trusted access control domain
> > > 
> > > Another argument in favour of this kind of approach is that if
your
> > BE
> > > is something like a fibrechannel driver for a SAN, there
isn''t
> > actually
> > > any security on the SAN side of it so any guarantees provided by
the
> > > driver domain are pretty much worthless.
> > > 
> > > Harry.
> > > 
> > 
> > We are talking about scalable, secure, and efficient local device
> > virtualization. 
> 
> 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.
> 
If you can''t trust your hardware, then you cant trust a domain built on
top of it. There is no need to convince me. If this is not a "fixable"
problem, then such devices cannot be assumed trused. 

Either they are not shared or the risk must be mitigated (e.g., as you 
suggested by encryption/signing and another trusted proxy).

Is this undeterministic/uncontrollable behavior considered "normal" 
operation?

Thanks
Reiner

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

On Thu, 2006-07-27 at 13:38 -0400, Reiner Sailer wrote:
> 
> Harry Butterworth <harry@hebutterworth.freeserve.co.uk> wrote on
> 07/27/2006 01:06:50 PM:
> 
> > On Thu, 2006-07-27 at 12:58 -0400, Reiner Sailer wrote:
> > > 
> > > 
> > > Harry Butterworth <harry@hebutterworth.freeserve.co.uk>
wrote on
> > > 07/27/2006 12:36:43 PM:
> > > 
> > > > On Thu, 2006-07-27 at 17:26 +0100, Harry Butterworth wrote:
> > > > 
> > > > > untrusted driver domain <-> trusted encryption
domain <->
> > > FE-domain
> > > > >                            hypervisor
> > > > >                    trusted access control domain
> > > > 
> > > > Another argument in favour of this kind of approach is that
if
> your
> > > BE
> > > > is something like a fibrechannel driver for a SAN, there
isn''t
> > > actually
> > > > any security on the SAN side of it so any guarantees
provided by
> the
> > > > driver domain are pretty much worthless.
> > > > 
> > > > Harry.
> > > > 
> > > 
> > > We are talking about scalable, secure, and efficient local device
> > > virtualization.  
> > 
> > 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.
> > 
> 
> If you can''t trust your hardware, then you cant trust a domain
built
> on top of it. There is no need to convince me. If this is not a
> "fixable" problem, then such devices cannot be assumed trused.  
> 
> Either they are not shared or the risk must be mitigated (e.g., as you
> suggested by encryption/signing and another trusted proxy). 
> 
> Is this undeterministic/uncontrollable behavior considered
"normal"
> operation? 
It''s obviously unusual but we do see it in real life, for example, when
we test 3rd party storage controllers.
> 
> Thanks 
> Reiner

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

Harry Butterworth <harry@hebutterworth.freeserve.co.uk> 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@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, 2006-07-27 at 13:53 -0400, Reiner Sailer wrote:
> 
> Harry Butterworth <harry@hebutterworth.freeserve.co.uk> 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@lists.xensource.com
http://lists.xensource.com/xen-devel