From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sasha Levin Subject: Secure KVM Date: Sun, 06 Nov 2011 22:40:20 +0200 Message-ID: <1320612020.3299.22.camel@lappy> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm To: Andrea Arcangeli , Avi Kivity , Marcelo Tosatti , Ingo Molnar , Pekka Enberg , Cyrill Gor Return-path: Received: from mail-fx0-f46.google.com ([209.85.161.46]:60682 "EHLO mail-fx0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752544Ab1KFUmL (ORCPT ); Sun, 6 Nov 2011 15:42:11 -0500 Received: by faao14 with SMTP id o14so4503485faa.19 for ; Sun, 06 Nov 2011 12:42:10 -0800 (PST) Sender: kvm-owner@vger.kernel.org List-ID: Hi all, I'm planning on doing a small fork of the KVM tool to turn it into a 'Secure KVM' enabled hypervisor. Now you probably ask yourself, Huh? The idea was discussed briefly couple of months ago, but never got off the ground - which is a shame IMO. It's easy to explain the problem: If an attacker finds a security hole in any of the devices which are exposed to the guest, the attacker would be able to either crash the guest, or possibly run code on the host itself. The solution is also simple to explain: Split the devices into different processes and use seccomp to sandbox each device into the exact set of resources it needs to operate, nothing more and nothing less. Since I'll be basing it on the KVM tool, which doesn't really emulate that many legacy devices, I'll focus first on the virtio family for the sake of simplicity (and covering 90% of the options). This is my basic overview of how I'm planning on implementing the initial POC: 1. First I'll focus on the simple virtio-rng device, it's simple enough to allow us to focus on the aspects which are important for the POC while still covering most bases (i.e. sandbox to single file - /dev/urandom and such). 2. Do it on a one process per device concept, where for each device (notice - not device *type*) requested, a new process which handles it will be spawned. 3. That process will be limited exactly to the resources it needs to operate, for example - if we run a virtio-blk device, it would be able to access only the image file which it should be using. 4. Connection between hypervisor and devices will be based on unix sockets, this should allow for better separation compared to other approaches such as shared memory. 5. While performance is an aspect, complete isolation is more important. Security is primary, performance is secondary. 6. Share as much code as possible with current implementation of virtio devices, make it possible to run virtio devices either like it's being done now, or by spawning them as separate processes - the amount of specific code for the separate process case should be minimal. Thats all I have for now, comments are *very* welcome. -- Sasha.