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

[Wei Liu <wei.liu2@citrix.com>]

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@citrix.com>
[...]
>  /*
> + * 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.