qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Security house-cleaning


From: Gianni Tedesco
Subject: Re: [Qemu-devel] [PATCH] Security house-cleaning
Date: Thu, 17 Jun 2004 18:16:57 +0100

On Thu, 2004-06-17 at 09:37 -0700, Tim wrote:
> > One of the main pros of Qemu (among the others) it that it has been
> > designed NOT to run SUID.
> > The only piece of code that need root access is tuntap networking.
> > This problem can be circunvented by:
> > - using sudo for tuntap
> > - using user net (a.k.a slirp)
> > - using vde.
> 
> Other future considerations: 
> - PCI Proxy support (if it is ever offically supported)
>     How will the host OS allow access by QEMU guest in this case?
> - Other bus (USB, firewire, etc) direct access to real hardware

well first thought is even you aren't root, you are still playing with
PCI devices, and due to the coarse grained control on some platforms
(read: x86) if you can access PCI devices, you can 0wn the entire system
(man 2 iopl). USB is packet based so can be secured reasonably.

The easiest approach is to acquire the resource as root and drop your
privileges...

FD passing across fork isn't really feasable because you need to parse
commandline to know what nodes to open with both PCI and USB.

Another approach is having a daemon which mediates access over a socket
(either mediating all access for security, or passing fds for
performance). The former approach would allow you to use devices in
remote machines so as to avoid locking up your qemu machine. It all
sounds quite nice, but I'm not sure we need yet another daemon though :)

-- 
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]