* [Qemu-devel] chroot jailing...
@ 2014-01-12 19:17 immersive.excel
2014-01-13 4:11 ` Stefan Hajnoczi
0 siblings, 1 reply; 6+ messages in thread
From: immersive.excel @ 2014-01-12 19:17 UTC (permalink / raw)
To: qemu-devel
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??
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] chroot jailing...
2014-01-12 19:17 [Qemu-devel] chroot jailing immersive.excel
@ 2014-01-13 4:11 ` Stefan Hajnoczi
2014-01-13 4:22 ` immersive.excel
0 siblings, 1 reply; 6+ messages in thread
From: Stefan Hajnoczi @ 2014-01-13 4:11 UTC (permalink / raw)
To: immersive.excel@gmail.com; +Cc: qemu-devel
On Sun, Jan 12, 2014 at 02:17:43PM -0500, immersive.excel@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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] chroot jailing...
2014-01-13 4:11 ` Stefan Hajnoczi
@ 2014-01-13 4:22 ` immersive.excel
2014-01-13 10:28 ` Markus Armbruster
2014-01-13 14:38 ` Alex Bennée
0 siblings, 2 replies; 6+ messages in thread
From: immersive.excel @ 2014-01-13 4:22 UTC (permalink / raw)
To: Stefan Hajnoczi; +Cc: qemu-devel
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.excel@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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] chroot jailing...
2014-01-13 4:22 ` immersive.excel
@ 2014-01-13 10:28 ` Markus Armbruster
2014-01-13 14:38 ` Alex Bennée
1 sibling, 0 replies; 6+ messages in thread
From: Markus Armbruster @ 2014-01-13 10:28 UTC (permalink / raw)
To: immersive.excel@gmail.com; +Cc: Stefan Hajnoczi, qemu-devel
"immersive.excel@gmail.com" <immersive.excel@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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] chroot jailing...
2014-01-13 4:22 ` immersive.excel
2014-01-13 10:28 ` Markus Armbruster
@ 2014-01-13 14:38 ` Alex Bennée
2014-01-13 17:07 ` immersive.excel
1 sibling, 1 reply; 6+ messages in thread
From: Alex Bennée @ 2014-01-13 14:38 UTC (permalink / raw)
To: immersive.excel@gmail.com; +Cc: Stefan Hajnoczi, qemu-devel
immersive.excel@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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] chroot jailing...
2014-01-13 14:38 ` Alex Bennée
@ 2014-01-13 17:07 ` immersive.excel
0 siblings, 0 replies; 6+ messages in thread
From: immersive.excel @ 2014-01-13 17:07 UTC (permalink / raw)
To: Alex Bennée, Stefan Hajnoczi, Markus Ambruster; +Cc: qemu-devel
That's what I thought; just had to be sure.
Thanks all...
========================
On 01/13/2014 09:38 AM, Alex Bennée wrote:
> immersive.excel@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>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-01-13 17:07 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-12 19:17 [Qemu-devel] chroot jailing immersive.excel
2014-01-13 4:11 ` Stefan Hajnoczi
2014-01-13 4:22 ` immersive.excel
2014-01-13 10:28 ` Markus Armbruster
2014-01-13 14:38 ` Alex Bennée
2014-01-13 17:07 ` immersive.excel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).