Re: [Xen-devel] [PATCH XEN v8 28/29] tools/libs/*: Introduce APIs to restrict handles to a specific domain.

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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.

>  -- 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.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel