summaryrefslogtreecommitdiff
path: root/qemu-bridge-helper.c
AgeCommit message (Collapse)AuthorFilesLines
2014-06-27qemu-bridge-helper: Fix fd leak in main()Gonglei1-2/+7
initialize fd and ctlfd, and close them at the end Signed-off-by: Gonglei <arei.gonglei@huawei.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2013-03-28qemu-bridge-helper: force usage of a very high MAC address for the bridgePaolo Bonzini1-0/+18
Linux uses the lowest enslaved MAC address as the MAC address of the bridge. Set MAC address to a high value so that it does not affect the MAC address of the bridge. Changing the MAC address of the bridge could cause a few seconds of network downtime. Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-id: 1363971468-21154-1-git-send-email-pbonzini@redhat.com Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-12-19misc: move include files to include/qemu/Paolo Bonzini1-1/+1
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2012-08-01net: Add interface to bridge when SIOCBRADDIF isn't availableCorey Bryant1-3/+21
The bridge helper uses the SIOCBRADDIF ioctl to add an inteface to a bridge. SIOCBRADDIF is not available on old Linux versions. This patch adds support to use the SIOCDEVPRIVATE ioctl with BRCTL_ADD_IF if SIOCBRADDIF is not available. Reported-by: Fabien Chouteau <chouteau@adacore.com> Signed-off-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
2012-02-01Add cap reduction support to enable use as SUIDCorey Bryant1-0/+36
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: Anthony Liguori <aliguori@us.ibm.com> Signed-off-by: Richa Marwaha <rmarwah@linux.vnet.ibm.com> Signed-off-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-02-01Add access control support to qemu bridge helperCorey Bryant1-0/+153
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: Anthony Liguori <aliguori@us.ibm.com> Signed-off-by: Richa Marwaha <rmarwah@linux.vnet.ibm.com> Signed-off-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-02-01Add basic version of bridge helperCorey Bryant1-0/+221
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: Anthony Liguori <aliguori@us.ibm.com> Signed-off-by: Richa Marwaha <rmarwah@linux.vnet.ibm.com> Signed-off-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>