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. 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 :|
