Re: [Xen-devel] [PATCH v2 4/6] tools/dm_restrict: Unshare mount and IPC namespaces on Linux

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

George Dunlap writes ("Re: [PATCH v2 4/6] tools/dm_restrict: Unshare mount and 
IPC namespaces on Linux"):
> On 09/24/2018 11:40 AM, Ian Jackson wrote:
> > I think that this means we should explicitly write down that the qemu
> > depriv implementation is incomplete on FreeBSD.
> 
> I think theoretically, an unprivileged user locked in a chroot owned by
> root, and with the xenstore fds properly restricted, should be enough to
> prevent a guest from gaining control or reading data that it shouldn't
> be able to read.  All of the other restrictions are to add extra layers,
> in case that first layer should have a bug.

I think this is not true.  The first thing I can think of is that such
a process can probably make network connections in an inappropriate
context.  The second thing is that it can leave a copy of itself
behind to interfere with the next domain (eg with ptrace) (which is a
thing we already know about).

Stepping back, my point is that the review that our set of depriv
calls etc. is sufficient, before we declare this feature supported,
ought to be kernel-specific.  So depending on which things are
implemented at which time, the feature might be (security-) supported
on FreeBSD but not Linux, or vice versa.

And this should be reflected in the paperwork somehow so that we don't
inadvertently conduct the review for one kernel and then just declare
the feature `supported'.  (This is less likely now that I have drawn
our attention to the issue by writing about it so much...)

> > I wonder if maybe this output should be in subunit v1 format.
> 
> We could do that.
> 
> It doesn't look like the "official" subunit code [1] accumulates the
> failure and returns it as the status code of the script as a whole.  Is
> that something that's valuable, do you think?  Or should we have `status
> = OK` mean, "The script itself ran without errors, check the output for
> any test failures"?

I think the way you did it is better at least in the default case,
although an actual subunit v1 consumer will want the behaviour of
subunit.sh because then they know that a zero exit status means that
all intended tests have been reported.

I guess this is one reason why you might write your own little
wrappers.

Ian.

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