Re: [Qemu-devel] [PATCH v2 0/2] Add dbus-vmstate

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, Aug 23, 2019 at 04:14:48PM +0100, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrangé (berrange@redhat.com) wrote:
> > On Fri, Aug 23, 2019 at 03:56:34PM +0100, Dr. David Alan Gilbert wrote:
> > > * Daniel P. Berrangé (berrange@redhat.com) wrote:
> > > > If two helpers are running as the same user ID, then can still
> > > > directly attack each other via things like ptrace or /proc/$PID/mem,
> > > > unless you've used SELinux to isolate them, or run each as a distinct
> > > > user ID.  If you do the latter, then we can still easily isolate
> > > > them using dbus.
> > > 
> > > You can lock those down pretty easily though.
> > 
> > How were you thinking ?
> > 
> > If you're not using SELinux or separate user IDs, then AFAICT you've
> > got a choice of using seccomp or containers.  seccomp is really hard
> > to get a useful policy out of with QEMU, and using containers for
> > each helper process adds a level of complexity worse than selinux
> > or separate user IDs, so isn't an obvious win over using dbus.
> 
> You can just drop the CAP_SYS_PTRACE on the whole lot for that;
> I thought there was something for /proc/.../mem as well.

If they're running the same user ID & not SELinux constrained, I don't
think that trying to block PRACTE / /proc/$PID/mem offers a reassuring
level of security separation, as there's still plenty of other files
that will be readable & writable to both vhostuser helper daemons which
can be leveraged as indirect attack vectors - auditing both helpers and
every library they link to to ensure nothing can be exploited is very
hard.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|