|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH][ACM] kernel enforcement of vbd policies via blkback driver
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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |