(→How To Test)
|Line 38:||Line 38:|
== How To Test ==
== How To Test ==
<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this feature is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be.
Revision as of 12:42, 6 January 2012
This feature provides a tool 'virt-sandbox' which can be used to run applications inside a sandbox built with one or more of the libvirt virtualization drivers. It will allow sandboxing applications inside an LXC container, or a QEMU/KVM virtual machine. The interface and capabilities are intended to be broadly similar to the existing SELinux 'sandbox' command, simply using a different sandboxing technique.
- Name: Daniel Berrange
- Email: berrange-at-redhat-dot-com
- Targeted release: Fedora 17
- Last updated: (06-01-2012)
- Percentage of completion: 75%
Existing Fedora releases ship with the "sandbox" command line tool. This allows applications to be run, strictly confined/isolated by SELinux policy. It can optionally make use of some kernel filesystem namespace features to provide a custom view of the filesystem.
The libvirt daemon includes an LXC driver which exposing a native Linux container virtualization capability. This includes integration with nearly all Linxu cgroups controllers and nearly all Linux namespace features. This can be leveraged to provide a means to sandbox individual applications inside a container. To escape the sandbox, applications would have to break out of the Linux container and the SELinux policy.
The libvirt daemon also includes QEMU driver which provides KVM accelerated full machine virtualization. This recently gained the ability to support passthrough of filesystems from the host OS. With this new capability, it becomes pratical to sandbox individual applications inside a full virtual machine, without the overhead of maintaining an additional OS installation image. To escape the sandbox, applications would have to break out of the guest Linux kernel, the host virtualization hypervisor and the host sVirt SELinux policy.
Benefit to Fedora
With the introduction of a 'virt-sandbox' command to support these two technologies, Fedora users will have a broader range of options for sandboxing applications which tradeoff system utilization overhead against layers of security, as best suits their security needs.
The virtualization sandbox will involve work in two areas
- libvirt - Add sVirt support to the LXC driver - Add support for multiple guest consoles - Add support for automatic VM death on client disconnect - Add support for filesystem relabelling control for filesystem passthrough - virt-sandbox - A completely new package
How To Test
Upstream has a doc describing basic cases to be tested
This will be fleshed out into a number of 'virt-sandbox' commands that should be executed, under either LXC or KVM.
For testing an LXC based sandbox, no special hardware will be required. Testing KVM sandboxes will require x86 Intel or AMD CPUs with hardware virt.
Users interested in confining applications inside sandboxes will have new options for sandboxing applications inside LXC containers, or KVM virtual machines. In future Fedora releases, this may be extended to other hypervisors supported by libvirt (VMWare, Xen, etc)
Completion of this feature requirements work on two projects
- The libvirt project. This has monthly releases upstream and is on track to support the neccessary functionality - The virt-sandbox project. This is a new project maintained by the author of this Feature.
In the event of the virt-sandbox command not progressing to a suitable level of development, this Feature can be postponed to Fedora 17, without any existing Fedora functionality being impacted.
* TBD. * virt-sandbox will contain an extensive manpage
Comments and Discussion
I've moved this feature back to FeaturePageIncomplete as it will not be ready in time for F16.