"Daniel P. Berrange" <berra...@redhat.com> 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@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to