[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xenstore domains and XS_RESTRICT
On 18/01/17 19:26, Stefano Stabellini wrote: > On Wed, 18 Jan 2017, Juergen Gross wrote: >> On 18/01/17 12:03, Wei Liu wrote: >>> On Mon, Jan 16, 2017 at 05:47:15PM +0100, Juergen Gross wrote: >>>> On 07/12/16 08:44, Juergen Gross wrote: >>>>> Hi, >>>>> >>>>> today the XS_RESTRICT wire command of Xenstore is supported by >>>>> oxenstored only to drop the privilege of a connection to that of the >>>>> domid given as a parameter to the command. >>>>> >>>>> Using this mechanism with Xenstore running in a stubdom will lead to >>>>> problems as instead of only a dom0 process dropping its privileges >>>>> the privileges of dom0 will be dropped (all dom0 Xenstore requests >>>>> share the same connection). >>>>> >>>>> In order to solve the problem I suggest the following change to the >>>>> Xenstore wire protocol: >>>>> >>>>> struct xsd_sockmsg >>>>> { >>>>> - uint32_t type; /* XS_??? */ >>>>> + uint16_t type; /* XS_??? */ >>>>> + uint16_t domid; /* Use privileges of this domain */ >>>>> uint32_t req_id;/* Request identifier, echoed in daemon's response. >>>>> */ >>>>> uint32_t tx_id; /* Transaction id (0 if not related to a >>>>> transaction). */ >>>>> uint32_t len; /* Length of data following this. */ >>>>> >>>>> /* Generally followed by nul-terminated string(s). */ >>>>> }; >>>>> >>>>> domid will normally be zero having the same effect as today. >>>>> >>>>> Using XS_RESTRICT via a socket connection will run as today by dropping >>>>> the privileges of that connection. >>>>> >>>>> Using XS_RESTRICT via the kernel (Xenstore domain case) will save the >>>>> domid given as parameter in the connection specific private kernel >>>>> structure. All future Xenstore commands of the connection will have >>>>> this domid set in xsd_sockmsg. The kernel will never forward the >>>>> XS_RESTRICT command to Xenstore. >>>>> >>>>> A domid other than 0 in xsd_sockmsg will be handled by Xenstore to use >>>>> the privileges of that domain. Specifying a domid in xsd_sockmsg is >>>>> allowed for privileged domain only, of course. XS_RESTRICT via a >>>>> non-socket connection will be rejected in all cases. >>>>> >>>>> The needed modifications for Xenstore and the kernel are rather small. >>>>> As there is currently no Xenstore domain available supporting >>>>> XS_RESTRICT there are no compatibility issues to expect. >>>>> >>>>> Thoughts? >>>> >>>> As I don't get any further constructive responses even after asking for >>>> them: would patches removing all XS_RESTRICT support be accepted? >>>> >>> >>> We don't need to actually remove it, do we? If XS_RESTRICT is not supported >>> by >>> xenstored, the client would get meaningful error code. A patch to >>> deprecate that command should be good enough, right? >> >> Uuh, no. >> >> oxenstored does support XS_RESTRICT. The longer it stays the better the >> chances someone is using it. >> >>> And sorry for the late reply, I'm still mulling over your proposal, I >>> will try to respond as soon as possible. >> >> I thought a little bit further: the idea of XS_RESTRICT is to avoid qemu >> being capable to overwrite any Xenstore entries of other domains >> including dom0. >> >> I fail to see how this should work with qemu-based backends (qdisk, >> pvusb), as those rely on paths in Xenstore writable by dom0 only. > > It does not work. However, QEMU based backends can be run on a separate > QEMU. Patches were submitted by IanJ and me to run 2 QEMUs per domain, > one to provide emulation, the other to provide the backends. Not sure > what happen to them, but they were more then prototypes. > > >> We already have a mechanism to de-privilege the device model of a HVM >> domain without hurting the backends: ioemu-stubdom. So I believe we >> should try to make qmeu upstream usable in stubdom instead of >> introducing mechanisms limited in usability ("if you want a secure >> device model you can't use features x, y and z."). > > Yes, but ioemu-stubdoms have drawbacks that make them not viable in many > scenarios. There are reasons why they are not enabled by default. > XS_RESTRICT should not replace, but complement ioemu-stubdoms. If we > remove XS_RESTRICT, what's the plan to make QEMU in Dom0 secure by > default? Currently none. OTOH there is no plan how to make XS_RESTRICT work in other cases like Xenstore domain. We need to design a solution which has no such drawbacks. We don't have to implement them all from beginning, but we should know how to do it. Otherwise something like XS_RESTRICT will be the result which isn't activated as default as it isn't working for all cases. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |