[For xense readers, please read the earlier mails in this
email-thread on xen-devel (Reiner)]
Keir Fraser <[hidden email]> 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
> -- 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.
Xense-devel mailing list
[hidden email] 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
> 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.
Xense-devel mailing list
In reply to this post by Reiner Sailer
> 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
Xense-devel mailing list
|Free forum by Nabble||Edit this page|