qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefan Berger <stefanb@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] virtio-rng and fd passing
Date: Fri, 01 Mar 2013 16:14:40 -0700	[thread overview]
Message-ID: <51313660.5010001@redhat.com> (raw)
In-Reply-To: <87r4jy90wt.fsf@codemonkey.ws>

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

On 03/01/2013 04:05 PM, Anthony Liguori wrote:
> Eric Blake <eblake@redhat.com> writes:
> 
>> On 03/01/2013 02:08 PM, Anthony Liguori wrote:
>>
>>>>> You can pass chardevs to the egd backend.  It's really not a good idea
>>>>> to pass a fd via rng-rangom.
>>
>> Why not?  If you are running a single guest, why can't libvirt pass that
>> one guest an fd instead of making qemu open() the file?
> 
> Why can't QEMU just open(/dev/random)?  What's the advantage of libvirt
> doing the open?

sVirt/syscall blacklisting

Libvirt WANTS to prohibit qemu from using open()/openat(), and instead
get ALL its fds from inheritence across exec() and/or SCM_RIGHTS.  In
this way, qemu can be made more secure out of the box, even on file
systems like NFS that lack SELinux labeling.  Right now, if you store
your image files on NFS, then you have to explicitly grant SELinux the
virt_use_nfs boolean, which says that qemu can open() _any_ file on NFS,
even if it is not a file belonging to the guest's disk image.  But if we
can prohibit qemu from calling open(), while still accessing everything
it needs with fd passing, then virt_use_nfs is no longer necessary - and
even if the qemu process is compromised by a rogue guest, the
compromised process cannot access any file to which it does not already
have an fd.

But given the way open() blacklisting works, allowing qemu to
open("/dev/random") while forbidding open("/nfs/...") is much harder
than forbidding all open().  In other words, an all-or-nothing switch is
possible only if qemu consistently uses qemu_open() instead of raw open().

> I understand the reason that fdsets exist (because NFS is stupid and
> doesn't support labeling).  But we aren't doing dynamic labeling of
> /dev/random and I strongly suspect it's not on NFS anyway.
> 
> So why are we trying to pass fds here?

Consistency - how do you write a policy that allows open("/dev/random")
while forbidding open("/nfs/...")?  It's much simpler to forbid open(),
even if /dev/random doesn't have any labeling issues.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]

  reply	other threads:[~2013-03-01 23:14 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <512FF819.7050505@redhat.com>
2013-03-01  9:51 ` [Qemu-devel] virtio-rng and fd passing Paolo Bonzini
2013-03-04  4:29   ` Amit Shah
2013-03-06  6:20   ` Amit Shah
2013-03-01 19:37 ` H. Peter Anvin
2013-03-01 20:13   ` Stefan Berger
2013-03-01 20:15     ` H. Peter Anvin
2013-03-01 20:41     ` Paolo Bonzini
2013-03-01 20:04 ` Anthony Liguori
2013-03-01 20:34   ` Stefan Berger
2013-03-01 21:08     ` Anthony Liguori
2013-03-01 21:13       ` Eric Blake
2013-03-01 23:05         ` Anthony Liguori
2013-03-01 23:14           ` Eric Blake [this message]
2013-03-01 23:59             ` Anthony Liguori
2013-03-02  0:29               ` Eric Blake
2013-03-02  3:13                 ` Anthony Liguori
2013-03-02 12:23                   ` Paolo Bonzini
2013-03-03 21:05                     ` Anthony Liguori
2013-03-04 21:57                       ` Eric Blake
2013-03-04 22:24                         ` Anthony Liguori
2013-03-04 22:35                           ` Eric Blake
2013-03-05  4:44                     ` H. Peter Anvin
2013-03-04 21:54                   ` Eric Blake
2013-03-02  0:34               ` Stefan Berger
2013-03-02  3:17                 ` Anthony Liguori
2013-03-02  3:34                   ` Stefan Berger
2013-03-03 21:06                     ` Anthony Liguori
2013-03-04 15:27                     ` Corey Bryant
2013-03-04 10:29             ` Daniel P. Berrange
2013-03-04 15:55               ` Corey Bryant
2013-03-01 22:59   ` Peter Krempa
2013-03-01 23:14     ` Anthony Liguori

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=51313660.5010001@redhat.com \
    --to=eblake@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanb@linux.vnet.ibm.com \
    /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).