Re: [Qemu-devel] chroot jailing...
immersive.ex...@gmail.com immersive.ex...@gmail.com writes: Thanks! So it sounds like you're saying selinux is the only meaningful thing to try? Or do people ever bother to place qemu in chroot jails?? I seem to have gotten the impression that people use qemu-static to do this, but it appears to be more for offering secured access of a guest folder to the host OS; not so much for security... chroot() by itself is not a useful security tool. https://lwn.net/Articles/252794/
Re: [Qemu-devel] chroot jailing...
immersive.ex...@gmail.com writes: Thanks! So it sounds like you're saying selinux is the only meaningful thing to try? Or do people ever bother to place qemu in chroot jails?? I seem to have gotten the impression that people use qemu-static to do this, but it appears to be more for offering secured access of a guest folder to the host OS; The qemu-static + chroot approach is mainly to avoid doing complex path manipulation between host/guest file-systems AFAICT. not so much for security... snip -- Alex Bennée
Re: [Qemu-devel] chroot jailing...
That's what I thought; just had to be sure. Thanks all... On 01/13/2014 09:38 AM, Alex Bennée wrote: immersive.ex...@gmail.com writes: Thanks! So it sounds like you're saying selinux is the only meaningful thing to try? Or do people ever bother to place qemu in chroot jails?? I seem to have gotten the impression that people use qemu-static to do this, but it appears to be more for offering secured access of a guest folder to the host OS; The qemu-static + chroot approach is mainly to avoid doing complex path manipulation between host/guest file-systems AFAICT. not so much for security... snip
[Qemu-devel] chroot jailing...
Would there be any security benefits, without suffering any considerable relative loss in performance, to (chroot) jailing qemu? Can it, practically speaking, be done?? Would that be a partial safeguard against virtual machine escapes? Or is it the case that if a virtual machine escape takes place, then all bets are probably off? (i.e., you probably have already pole-vaulted over any filesystem driver/partition access control mechanisms...) Are there any articles or discussions that I can be directed to about it? (my focus for now is 64 bit, Intel core i7...) Are there specific suggestions and/or guidelines for attempting to do so -or not??
Re: [Qemu-devel] chroot jailing...
On Sun, Jan 12, 2014 at 02:17:43PM -0500, immersive.ex...@gmail.com wrote: Would there be any security benefits, without suffering any considerable relative loss in performance, to (chroot) jailing qemu? Can it, practically speaking, be done?? Would that be a partial safeguard against virtual machine escapes? Or is it the case that if a virtual machine escape takes place, then all bets are probably off? (i.e., you probably have already pole-vaulted over any filesystem driver/partition access control mechanisms...) Are there any articles or discussions that I can be directed to about it? (my focus for now is 64 bit, Intel core i7...) Are there specific suggestions and/or guidelines for attempting to do so -or not?? Isolating QEMU can be useful to prevent exposing data on the host or from other guests. Production systems using libvirt often run QEMU unprivileged and use SELinux to restrict what resources the process has access to. This way a QEMU process that has been taken over still cannot get access to much besides the files it already has open, the network device it uses, etc. Stefan
Re: [Qemu-devel] chroot jailing...
Thanks! So it sounds like you're saying selinux is the only meaningful thing to try? Or do people ever bother to place qemu in chroot jails?? I seem to have gotten the impression that people use qemu-static to do this, but it appears to be more for offering secured access of a guest folder to the host OS; not so much for security... On 01/12/2014 11:11 PM, Stefan Hajnoczi wrote: On Sun, Jan 12, 2014 at 02:17:43PM -0500, immersive.ex...@gmail.com wrote: Would there be any security benefits, without suffering any considerable relative loss in performance, to (chroot) jailing qemu? Can it, practically speaking, be done?? Would that be a partial safeguard against virtual machine escapes? Or is it the case that if a virtual machine escape takes place, then all bets are probably off? (i.e., you probably have already pole-vaulted over any filesystem driver/partition access control mechanisms...) Are there any articles or discussions that I can be directed to about it? (my focus for now is 64 bit, Intel core i7...) Are there specific suggestions and/or guidelines for attempting to do so -or not?? Isolating QEMU can be useful to prevent exposing data on the host or from other guests. Production systems using libvirt often run QEMU unprivileged and use SELinux to restrict what resources the process has access to. This way a QEMU process that has been taken over still cannot get access to much besides the files it already has open, the network device it uses, etc. Stefan
