[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
- Re: [Qemu-devel] [RFC] Continuous work on sandboxing,
Paul Moore <=