* Daniel P. Berrangé (berra...@redhat.com) wrote: > On Fri, Aug 23, 2019 at 04:14:48PM +0100, Dr. David Alan Gilbert wrote: > > * Daniel P. Berrangé (berra...@redhat.com) wrote: > > > On Fri, Aug 23, 2019 at 03:56:34PM +0100, Dr. David Alan Gilbert wrote: > > > > * Daniel P. Berrangé (berra...@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.
Still, it doesn't mean we shouldn't be careful about anything new we add. Dave > 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 :| -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
