[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 Tue, Jan 19, 2016 at 01:44:53PM +0000, Ian Campbell wrote: > On Tue, 2016-01-19 at 13:24 +0000, Wei Liu wrote: > > 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 > > The actual implementation of this functionality would be OS specific and > therefore need to be in $os.c, where mini-os.c is under no obligation to > use an ioctl if it doesn't want to. > > The only reason it is done in the common code here is to avoid adding a > dozen stubs prior to even one OS actually implementing this. I could add a > norestrict.c to each lib, put the stub there and link it on all platforms, > that would reduce the churn when someone comes to add the actual > functionality. > I don't think you need to do that. Doing this in common code is fine by me. > > -- 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. > > The intention was to try and get enough confidence that we could include > the call in the initial implementation such that applications could > unconditionally use it in the future. > > If we can't manage a sufficient level of confidence in the proposed > interface then we should skip it for now of course. > Let's see what other people think about this particular function. Wei. > Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |