"Daniel P. Berrange" <berrange@xxxxxxxxxx> writes: > On Thu, Sep 29, 2011 at 11:42:47PM +0530, M. Mohan Kumar wrote: >> On Wednesday, September 28, 2011 08:29:06 PM Daniel P. Berrange wrote: [...] >> > If we assume that QEMU gets exploited, and that QEMU can find some flaw >> > in the proxy_helper that it can exploit, what damage can the proxy_helper >> > do ? Clearly we want it to not be able to read/write any files other >> > than those exported, even when it becomes compromised, ideally also >> > without requiring SELinux/AppArmour to make it safe. If proxy_helper >> > is running as root with full capabilities, it can trivially escape >> > the chroot[1], so this isn't all that nice for overall system security. >> >> When proxy helper process is forked, its made sure that all open file >> descriptor are closed except the socket descriptor, so that proxy helper can't >> escape chroot jail. > > Unfortunately that is not sufficient. Even if you have closed all > file descriptors except the socket, you can still escape the chroot > jail. There is a nice demo program for escaping from a chroot on > this webpage: > > http://www.bpfh.net/simes/computing/chroot-break.html [...] > Basically if the process inside the chroot, is still running as > root, then it is not securely contained. As Alan Cox observed, "chroot is not and never has been a security tool." It's a tool to configure the root of absolute path names. [...] -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list