qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gianni Tedesco <gianni@scaramanga.co.uk>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] Security house-cleaning
Date: Thu, 17 Jun 2004 18:16:57 +0100	[thread overview]
Message-ID: <1087492617.3375.127.camel@sherbert> (raw)
In-Reply-To: <20040617163740.GB20148@sentinelchicken.org>

[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2004-06-17 17:18 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-17  4:38 [Qemu-devel] [PATCH] Security house-cleaning Tim
2004-06-17 15:07 ` Gianni Tedesco
2004-06-17 15:14   ` Renzo Davoli
2004-06-17 15:24     ` Panagiotis Issaris
2004-06-17 15:27     ` Sebastien Bechet
2004-06-17 16:37     ` Tim
2004-06-17 17:03       ` Sander Nagtegaal
2004-06-17 17:16       ` Gianni Tedesco [this message]
2004-06-17 19:59       ` Renzo Davoli
2004-06-17 16:05   ` Tim
2004-06-17 17:41     ` Gianni Tedesco
2004-06-18  4:13       ` Tim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1087492617.3375.127.camel@sherbert \
    --to=gianni@scaramanga.co.uk \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).