[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] Continuous work on sandboxing

From: Paul Moore
Subject: Re: [Qemu-devel] [RFC] Continuous work on sandboxing
Date: Wed, 01 May 2013 10:13:03 -0400
User-agent: KMail/4.10.2 (Linux/3.8.5-gentoo; KDE/4.10.2; x86_64; ; )

On Tuesday, April 30, 2013 04:28:54 PM Corey Bryant wrote:
> Just to be clear, I'm thinking you could launch guests in one of two
> different seccomp sandboxed environments:
> 1) Using the existing and more permissive whitelist where every QEMU
> feature works:
> qemu-kvm -sandbox on,default

In general, I like the comma delimited list of sandbox filters/methods/etc. 
but I'm not sure we need to explicitly specify "default", it seems like "on" 
would be sufficient.  It also preserved compatibility with what we have now.

> 2) A more restricted whitelist environment that doesn't allow all QEMU
> features to work.  It would be limited to the whitelist in 1 and it
> would also deny things like execve(), open(), socket(), certain ioctl()
> parameters, and may only allow reads/writes to specifc fds, and/or block
> anything else that could be dangerous:
> qemu-kvm -sandbox on,restricted
> I'm just throwing these command line options and syscalls out there.
> And maybe it makes more sense for libvirt to pass the syscalls and
> parameters to QEMU so that libvirt can determine the parameters to
> restrict, like fd's the guest is allowed to read/write.
> Here's another thread where this was discussed:
> http://www.redhat.com/archives/libvir-list/2013-April/msg01501.html

Seems reasonable to me.

paul moore
security and virtualization @ redhat

reply via email to

[Prev in Thread] Current Thread [Next in Thread]