Unify KVM kernel-space and user-space code into a single project
in [Kernel]
|
Prev: Irish 2010 Grant Winner
Next: [PATCH] staging: winbond: mds_f.h whitespace and CamelCase corrections.
From: Avi Kivity on 24 Mar 2010 11:50 On 03/24/2010 05:37 PM, Joerg Roedel wrote: > >> No it can't. With sVirt every single VM has a custom security label and >> the policy only allows it access to disks / files with a matching label, >> and prevents it attacking any other VMs or processes on the host. THis >> confines the scope of any exploit in QEMU to those resources the admin >> has explicitly assigned to the guest. >> > Even better. So a guest which breaks out can't even access its own > /sys/kvm/ directory. Perfect, it doesn't need that access anyway. > > But what security label does that directory have? How can we make sure that whoever needs access to those files, gets them? Automatically created objects don't work well with that model. They're simply missing information. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 24 Mar 2010 12:00 On 03/24/2010 05:50 PM, Joerg Roedel wrote: > On Wed, Mar 24, 2010 at 05:43:31PM +0200, Avi Kivity wrote: > >> On 03/24/2010 05:37 PM, Joerg Roedel wrote: >> >>> Even better. So a guest which breaks out can't even access its own >>> /sys/kvm/ directory. Perfect, it doesn't need that access anyway. >>> >> But what security label does that directory have? How can we make sure >> that whoever needs access to those files, gets them? >> >> Automatically created objects don't work well with that model. They're >> simply missing information. >> > If we go the /proc/<pid>/kvm way then the directory should probably > inherit the label from /proc/<pid>/? > That's a security policy. The security people like their policies outside the kernel. For example, they may want a label that allows a trace context to read the data, and also qemu itself for introspection. > Same could be applied to /sys/kvm/guest/ if we decide for it. The VM is > still bound to a single process with a /proc/<pid> after all. > Ditto. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on 24 Mar 2010 12:10 On Wed, 2010-03-24 at 16:01 +0100, Joerg Roedel wrote: > What I meant was: perf-kernel puts the guest-name into every sample and > perf-userspace accesses /sys/kvm/guest_name/fs/ later to resolve the > symbols. I leave the question of how the guest-fs is exposed to the host > out of this discussion. We should discuss this seperatly. I'd much prefer a pid like suggested later, keeps the samples smaller. But that said, we need guest kernel events like mmap and context switches too, otherwise we simply can't make sense of guest userspace addresses, we need to know the guest address space layout. So aside from a filesystem content, we first need mmap and context switch events to find the files we need to access. And while I appreciate all the security talk, its basically pointless anyway, the host can access it anyway, everybody agrees on that, but still you're arguing the case.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 24 Mar 2010 12:20 On 03/24/2010 05:59 PM, Joerg Roedel wrote: > > >>> I am not tied to /sys/kvm. We could also use /proc/<pid>/kvm/ for >>> example. This would keep anything in the process space (except for the >>> global list of VMs which we should have anyway). >>> >>> >> How about ~/.qemu/guests/$pid? >> > That makes it hard for perf to find it and even harder to get a list of > all VMs. Looks trivial to find a guest, less so with enumerating (still doable). > With /proc/<pid>/kvm/guest we could symlink all guest > directories to /proc/kvm/ and perf reads the list from there. Also perf > can easily derive the directory for a guest from its pid. > Last but not least its kernel-created and thus independent from the > userspace part being used. > Doesn't perf already has a dependency on naming conventions for finding debug information? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 24 Mar 2010 12:30
On 03/24/2010 06:17 PM, Joerg Roedel wrote: > On Wed, Mar 24, 2010 at 05:52:54PM +0200, Avi Kivity wrote: > >> On 03/24/2010 05:50 PM, Joerg Roedel wrote: >> >>> If we go the /proc/<pid>/kvm way then the directory should probably >>> inherit the label from /proc/<pid>/? >>> >> That's a security policy. The security people like their policies >> outside the kernel. >> >> For example, they may want a label that allows a trace context to read >> the data, and also qemu itself for introspection. >> > Hm, I am not a security expert. I'm out of my depth here as well. > But is this not only one entity more for > sVirt to handle? I would leave that decision to the sVirt developers. > Does attaching the same label as for the VM resources mean that root > could not access it anymore? > IIUC processes run under a context, and there's a policy somewhere that tells you which context can access which label (and with what permissions). There was a server on the Internet once that gave you root access and invited you to attack it. No idea if anyone succeeded or not (I got bored after about a minute). So it depends on the policy. If you attach the same label, that means all files with the same label have the same access permissions. I think. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |