1. 28 Mar, 2013 1 commit
  2. 19 Dec, 2012 1 commit
  3. 01 Aug, 2012 1 commit
  4. 01 Feb, 2012 3 commits
    • Corey Bryant's avatar
      Add cap reduction support to enable use as SUID · 47e98658
      Corey Bryant authored
      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: default avatarAnthony Liguori <aliguori@us.ibm.com>
      Signed-off-by: default avatarRicha Marwaha <rmarwah@linux.vnet.ibm.com>
      Signed-off-by: default avatarCorey Bryant <coreyb@linux.vnet.ibm.com>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      47e98658
    • Corey Bryant's avatar
      Add access control support to qemu bridge helper · bdef79a2
      Corey Bryant authored
      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: default avatarAnthony Liguori <aliguori@us.ibm.com>
      Signed-off-by: default avatarRicha Marwaha <rmarwah@linux.vnet.ibm.com>
      Signed-off-by: default avatarCorey Bryant <coreyb@linux.vnet.ibm.com>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      bdef79a2
    • Corey Bryant's avatar
      Add basic version of bridge helper · 7b93fadf
      Corey Bryant authored
      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: default avatarAnthony Liguori <aliguori@us.ibm.com>
      Signed-off-by: default avatarRicha Marwaha <rmarwah@linux.vnet.ibm.com>
      Signed-off-by: default avatarCorey Bryant <coreyb@linux.vnet.ibm.com>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      7b93fadf