Re: [Xen-devel] [PATCH v2 1/6] docs/qemu-deprivilege: Revise and update with status and future plans

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

George Dunlap writes ("Re: [PATCH v2 1/6] docs/qemu-deprivilege: Revise and 
update with status and future plans"):
> On 09/24/2018 11:23 AM, Ian Jackson wrote:
> > You also need the tool `fishdescriptor' from src:chiark-utils to get
> > the descriptors out of qemu.  It is in chiark-utils-bin in Debian
> > buster and Debian stretch-backports.
> 
> This was meant to be a somewhat technical description of the mechanism
> of doing the testing (to be implemented by someone implementing the
> feature), rather than a how-to for keen users / testers to actually run
> the test.  What about:

Right.

> "Use `fishdescriptor` from [reference], to pull a file descriptor from a
> running QEMU, then check that it has the desired properties, and that
> hypercalls which are meant to fail do fail.  (The latter is implemented
> in `tools/test/depriv/depriv-fd-checker.c`)."

SGTM.  `[reference]' is `(in Debian this can be found in the binary
package chiark-scripts)'.

> On a related note: Is there any reason not to  move
> osstest-depriv-fd-collector into the tree, perhaps even merging it with
> the functionality in depriv-process-checker?

I would be entirely fine with that.  Its osstest-specific knowledge is
fairly limited.

> >> +## Namespaces for unused functionality (Linux only)
...
> >> +    unshare(CLONE_NEWNS | CLONE_NEWIPC)
...
> >> +    unshare(CLONE_NEWNET | CLONE_NEWNS | CLONE_NEWIPC)
...
> > The CLONE_NEWIPC overlaps with the IPC unshare discussed above.
> 
> This is the second time I've had to try to explain the difference
> between the above two items; I'm not sure what's not clear about what
> was written.

Your two unshare calls have overlapping flags.  That means they have
overlapping effects.  I think I saw that and then conflated the two
completely.  Sorry about that - but really, it doesn't make sense to
list two unshare calls with overlapping flags as if they were
separate.

> > If you are recording this kind of information here: this will of
> > course not work, because qemu binds and opens things at startup that
> > would be broken by this.  Maybe you want to give a url to a mailing
> > list posting instead of this un-referenced hearsay.
>
> The title of the first says: "...for unused functionaltiy".  IPC
> namespaces are for non-file-based IPCs (i.e., things which are not unix
> sockets).  QEMU does not use this functionality, nor does it use mount
> functionality.  The first restriction is in fact implemented in patch 4,
> and I haven't had any issues with it.

I think I was thinkng of CLONE_NEWNET when I wrote the words above.
Sorry for the confusion.

> >> +## Setting up a userid range
> > 
> > There was some discussion on a Debian list recently about some
> > container systems that encode a 16-bit within-container uid and a
> > 16-bit container number into the 32-bit uid.  I guess we don't need to
> > explicitly worry about clashes between our usage and those ?
> 
> Hmm, someone may run containers that use such things in dom0, at which
> point we may have a namespace collision.
> 
> But really I think this is a distro problem to solve -- we don't specify
> a >16-bit UID, we just give it as an example.  Debian could, for instance:
>  - Not use the system which uses the 16/16 split
>  - Enforce that Xen and the 16/16 split system are not installed at the
> same time
>  - Reserve 32k of UIDs in the 16-bit space somehow
>  - Reserve one of the "container ID" entries for Xen, so that there's
> never a collision

In practice even in Debian things are not this organised.  Currently
Debian's policy docs simply say that uids >2^16 are "reserved".  Work
will need to be done there to formalise this.

> > The limitations section should also say something like this:
> > 
> >  The currently implemented restrictions are thought to be a useful
> >  security improvement.  However, the design and implementation is
> >  preliminary and there is work left to do.  Accordingly we do not
> >  promise that they are sufficient to stop a rogue domain which takes
> >  control of its qemu from escaping into the host, let alone stop it
> >  from denying service to the host.
> 
> Isn't this what "Tech preview" means?  Or do you mean we'll keep this
> kind of warning in after we take it out of 'tech preview'?
> 
> >  Therefore, bugs which affect the effectiveness of the qemu depriv
> >  mechanisms will be treated as plain bugs, not security bugs; they
> >  would not result in a Xen Project Security Advisory.  However, bugs
> >  where the security of a system with dm_restrict=1 is worse than
> >  before, will be treated as security bugs.
> 
> This would be slightly different than 'tech preview'.

Both of these paragraphs are to be taken together.  And yes, it is
somewhat different than pure "tech preview", which is "if you use this
feature, all bets are off".  I am trying to write a sensible promise
which means that someone who turns on dm_restrict is not *weakening*
their security posture.

> Once this goes to "supported", I agree that we shouldn't issue an XSA
> for, say, a bug in Linux's implementation of RLIMIT_NPROC, or a bug in
> Linux that allows QEMU, while running as an unprivileged process, to do
> something it's not supposed to do (say, fill up our chroot, which is
> owned by root).
> 
> But I do think we should issue an XSA if there is code in libxl which
> claims to do something but failed.  For instance, if a change
> accidentally disables the `-runas` option to QEMU when dm_restrict=1,
> then that would merit an XSA in my opinion.

Yes.  But right now, I just want to say that we will issue an advisory
of dm_restrict is _worse_.  For example if using dm_restrict somehow
allowed a guest to write to read-only disks, or something.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel