[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [RFC] Device sandboxing
From: |
Corey Bryant |
Subject: |
[Qemu-devel] [RFC] Device sandboxing |
Date: |
Wed, 07 Dec 2011 13:25:21 -0500 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 |
A group of us are starting to work on sandboxing QEMU device emulation
code. We're just getting started investigating various approaches, and
want to engage the community to gather input.
Following are the design points that we are currently considering:
* Decompose QEMU into multiple processes:
* This could be done such that QEMU devices execute in separate
processes based on device type, e.g. all block devices in one
process and all network devices in a second process. Another
alternative is executing a separate process per device.
* Decomposition would not only afford a level of security inherent
in process separation, it would also allow development of stricter
sVirt/SELinux policy for the decomposed QEMU processes (e.g. a
block device specific policy). This would enable a true sandbox
with layers of defense.
* Decompose the device emulation process further into an untrusted and
trusted thread:
* The untrusted thread would be restricted by seccomp mode 1 and
would contain the device emulation code.
* The trusted helper thread would run beside the untrusted thread,
enabling the untrusted thread to make syscalls beyond read(),
write(), exit(), and sigreturn().
* IPC communication mechanisms:
* An IPC mechanism will be required to enable communication between
untrusted and trusted threads.
* An IPC mechanism will also be required to enable communication
between the main QEMU process and device processes.
* The communication mechanisms must provide secure communication,
be low overhead (easy to generate, parse, and validate), and must
play well with sVirt/LSMs.
* Some thoughts for IPC mechanisms are Unix sockets, pipes, virtio,
Google Native Client's IMC, and shared memory.
* If seccomp mode 2 support becomes available, decomposition of device
emulation into untrusted/trusted threads may not be necessary. This
could result in improved performance (no IPC overhead between trusted
and untrusted thread) and reduced complexity (no need for trusted
helper thread).
* Execution of QEMU with the sandboxed device support should be an
optional run-time specification.
* We will be focusing on legacy devices first, both for performance and
risk reasons.
Once we settle on a direction, we will develop a proof of concept to
share with the community.
We appreciate your input.
Regards,
Ashley Lai
Corey Bryant
Eduardo Otubo
Michael Halcrow
Paul Moore
Richa Marwaha
- [Qemu-devel] [RFC] Device sandboxing,
Corey Bryant <=
- Re: [Qemu-devel] [RFC] Device sandboxing, Anthony Liguori, 2011/12/07
- Re: [Qemu-devel] [RFC] Device sandboxing, Corey Bryant, 2011/12/07
- Re: [Qemu-devel] [RFC] Device sandboxing, Anthony Liguori, 2011/12/07
- Re: [Qemu-devel] [RFC] Device sandboxing, Michael Halcrow, 2011/12/07
- Re: [Qemu-devel] [RFC] Device sandboxing, Corey Bryant, 2011/12/07
- Re: [Qemu-devel] [RFC] Device sandboxing, Eric Paris, 2011/12/07
- Re: [Qemu-devel] [RFC] Device sandboxing, Stefan Hajnoczi, 2011/12/08
- Re: [Qemu-devel] [RFC] Device sandboxing, Dor Laor, 2011/12/11
- Re: [Qemu-devel] [RFC] Device sandboxing, Will Drewry, 2011/12/12
- Re: [Qemu-devel] [RFC] Device sandboxing, Stefan Hajnoczi, 2011/12/08