1. 07 2月, 2012 11 次提交
  2. 04 2月, 2012 24 次提交
  3. 02 2月, 2012 5 次提交
    • S
      Change license from GPLv2 to GPLv2+ · 4c32fe66
      Stefan Weil 提交于
      This file only contains code from Red Hat, so it can use GPLv2+.
      Tested with `git blame -M -C net/checksum.c`.
      Signed-off-by: NStefan Weil <sw@weilnetz.de>
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      4c32fe66
    • C
      Add support for net bridge · a7c36ee4
      Corey Bryant 提交于
      The most common use of -net tap is to connect a tap device to a bridge.  This
      requires the use of a script and running qemu as root in order to allocate a
      tap device to pass to the script.
      
      This model is great for portability and flexibility but it's incredibly
      difficult to eliminate the need to run qemu as root.  The only really viable
      mechanism is to use tunctl to create a tap device, attach it to a bridge as
      root, and then hand that tap device to qemu.  The problem with this mechanism
      is that it requires administrator intervention whenever a user wants to create
      a guest.
      
      By essentially writing a helper that implements the most common qemu-ifup
      script that can be safely given cap_net_admin, we can dramatically simplify
      things for non-privileged users.  We still support existing -net tap options
      as a mechanism for advanced users and backwards compatibility.
      
      Currently, this is very Linux centric but there's really no reason why it
      couldn't be extended for other Unixes.
      
      A typical invocation would be similar to one of the following:
      
        qemu linux.img -net bridge -net nic,model=virtio
      
        qemu linux.img -net tap,helper="/usr/local/libexec/qemu-bridge-helper"
                       -net nic,model=virtio
      
        qemu linux.img -netdev bridge,id=hn0
                       -device virtio-net-pci,netdev=hn0,id=nic1
      
        qemu linux.img -netdev tap,helper="/usr/local/libexec/qemu-bridge-helper",id=hn0
                       -device virtio-net-pci,netdev=hn0,id=nic1
      
      The default bridge that we attach to is br0.  The thinking is that a distro
      could preconfigure such an interface to allow out-of-the-box bridged networking.
      
      Alternatively, if a user wants to use a different bridge, a typical invocation
      would be simliar to one of the following:
      
        qemu linux.img -net bridge,br=qemubr0 -net nic,model=virtio
      
        qemu linux.img -net tap,helper="/usr/local/libexec/qemu-bridge-helper --br=qemubr0"
                       -net nic,model=virtio
      
        qemu linux.img -netdev bridge,br=qemubr0,id=hn0
                       -device virtio-net-pci,netdev=hn0,id=nic1
      
        qemu linux.img -netdev tap,helper="/usr/local/libexec/qemu-bridge-helper --br=qemubr0",id=hn0
                       -device virtio-net-pci,netdev=hn0,id=nic1
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      Signed-off-by: NRicha Marwaha <rmarwah@linux.vnet.ibm.com>
      Signed-off-by: NCorey Bryant <coreyb@linux.vnet.ibm.com>
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      a7c36ee4
    • C
      Add cap reduction support to enable use as SUID · 47e98658
      Corey Bryant 提交于
      The ideal way to use qemu-bridge-helper is to give it an fscap of using:
      
       setcap cap_net_admin=ep qemu-bridge-helper
      
      Unfortunately, most distros still do not have a mechanism to package files
      with fscaps applied.  This means they'll have to SUID the qemu-bridge-helper
      binary.
      
      To improve security, use libcap to reduce our capability set to just
      cap_net_admin, then reduce privileges down to the calling user.  This is
      hopefully close to equivalent to fscap support from a security perspective.
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      Signed-off-by: NRicha Marwaha <rmarwah@linux.vnet.ibm.com>
      Signed-off-by: NCorey Bryant <coreyb@linux.vnet.ibm.com>
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      47e98658
    • C
      Add access control support to qemu bridge helper · bdef79a2
      Corey Bryant 提交于
      We go to great lengths to restrict ourselves to just cap_net_admin as an OS
      enforced security mechanism.  However, we further restrict what we allow users
      to do to simply adding a tap device to a bridge interface by virtue of the fact
      that this is the only functionality we expose.
      
      This is not good enough though.  An administrator is likely to want to restrict
      the bridges that an unprivileged user can access, in particular, to restrict
      an unprivileged user from putting a guest on what should be isolated networks.
      
      This patch implements an ACL mechanism that is enforced by qemu-bridge-helper.
      The ACLs are fairly simple whitelist/blacklist mechanisms with a wildcard of
      'all'.  All users are blacklisted by default, and deny takes precedence over
      allow.
      
      An interesting feature of this ACL mechanism is that you can include external
      ACL files.  The main reason to support this is so that you can set different
      file system permissions on those external ACL files.  This allows an
      administrator to implement rather sophisticated ACL policies based on
      user/group policies via the file system.
      
      As an example:
      
      /etc/qemu/bridge.conf root:qemu 0640
      
       allow br0
       include /etc/qemu/alice.conf
       include /etc/qemu/bob.conf
       include /etc/qemu/charlie.conf
      
      /etc/qemu/alice.conf root:alice 0640
       allow br1
      
      /etc/qemu/bob.conf root:bob 0640
       allow br2
      
      /etc/qemu/charlie.conf root:charlie 0640
       deny all
      
      This ACL pattern allows any user in the qemu group to get a tap device
      connected to br0 (which is bridged to the physical network).
      
      Users in the alice group can additionally get a tap device connected to br1.
      This allows br1 to act as a private bridge for the alice group.
      
      Users in the bob group can additionally get a tap device connected to br2.
      This allows br2 to act as a private bridge for the bob group.
      
      Users in the charlie group cannot get a tap device connected to any bridge.
      
      Under no circumstance can the bob group get access to br1 or can the alice
      group get access to br2.  And under no cicumstance can the charlie group
      get access to any bridge.
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      Signed-off-by: NRicha Marwaha <rmarwah@linux.vnet.ibm.com>
      Signed-off-by: NCorey Bryant <coreyb@linux.vnet.ibm.com>
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      bdef79a2
    • C
      Add basic version of bridge helper · 7b93fadf
      Corey Bryant 提交于
      This patch adds a helper that can be used to create a tap device attached to
      a bridge device.  Since this helper is minimal in what it does, it can be
      given CAP_NET_ADMIN which allows qemu to avoid running as root while still
      satisfying the majority of what users tend to want to do with tap devices.
      
      The way this all works is that qemu launches this helper passing a bridge
      name and the name of an inherited file descriptor.  The descriptor is one
      end of a socketpair() of domain sockets.  This domain socket is used to
      transmit a file descriptor of the opened tap device from the helper to qemu.
      
      The helper can then exit and let qemu use the tap device.
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      Signed-off-by: NRicha Marwaha <rmarwah@linux.vnet.ibm.com>
      Signed-off-by: NCorey Bryant <coreyb@linux.vnet.ibm.com>
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      7b93fadf