[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH XEN v8 28/29] tools/libs/*: Introduce APIs to restrict handles to a specific domain.
On Fri, Jan 15, 2016 at 01:23:07PM +0000, Ian Campbell wrote: > These are intended to allow user space processes (in particular QEMU) > to lock down all the handles at start of day and then drop the > privileges which would allow them to open any new unrestricted handles > (e.g. setuid or similar). This will reduce the privileges which taking > over such a process would gain an attacker wrt other domains in the > system. > > These are currently unimplemented on all platforms, however the API > semantics are defined as the basis for discussion, and so that > consumers can rely on this interface always having been present rather > than requiring compile time API checks. > > It is expected that these will be implemented by adding new ioctl > calls on the underlying driver and that the restrictions will be > enforced at the kernel interface layer (most likely by the kernel > itself). > > For evtchn, foreignmemory, gnttab and gntshr this is hopefully > reasonably straightforward. > > For call it is not so clear cut. Clearly the kernel cannot enforce > these restrictions for hypercalls which are not stable (domctl et al) > so they can never be on the whitelist. It may also be that potential > users would like to restrict the handle further than just a given > target domain, i.e. to a specific set of functionality (e.g. "things a > device model might reasonably do"). I think we will also need some way > to discover whether a given set of interfaces is available to a > restricted handle, in order to support the addition of new > functionality. > > Notes: > > - On many (all?) platforms libxencall and libxenforeignmemory are > implemented by the same underlying privcmd driver. The platform > level ioctl interface should support restricting the handle to only > one or the other. IIRC mini-os doesn't have ioctl. That would require some special handling -- if we want to use the new API in qemu-trad, too. We shall cross the bridge when we get there. > - On platforms with multiple privilege mapping ioctl variants should > consider only allowing the newest/currently preferred one on a > restricted handle. e.g. on Linux this would allow > IOCTL_PRIVCMD_MMAPBATCH_V2 but not IOCTL_PRIVCMD_MMAPBATCH. (Of > course any subsequently introduced _V3 would be subject to > compatibility concerns) > > Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx> [...] > /* > + * Attempt to restrict the given xcall handle to only be able to > + * target the given domain. > + * > + * On success returns 0, after which only hypercalls which are on a > + * platform specific whitelist can be called and the arguments will be > + * audited by the platform to ensure that the target domain is > + * domid. > + * > + * Subsequent attempts to call any hypercall not on the platform > + * specific whitelist will return -1 setting errno to ENOSYS. > + * > + * Subsequent attempts to call any hypercall on the platform specific > + * whitelist with any other target domain return -1 setting errno to > + * EPERM. > + * > + * These restrictions will be implemented by the platform in a way > + * which cannot be circumvented by a userspace process. Further > + * privilege drops (such as using setuid(2) etc) may also be required > + * to prevent a compromised process from simply opening a second > + * handle > + * > + * XXX which hypercalls are restricted, per platform list, do we need > + * a way to probe? Do we want to be able to restrict to particular > + * subsets of whitelisted hypercalls? > + * TBH given the semantics of this call is not yet clear I don't think we should rush committing this interface. Wei. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |