@Chris Yup, I understand how capabilities work. I'm actively working on getting fscaps functioning with Debian/Ubuntu packaging (see https://wiki.ubuntu.com/Security/FilesystemCapabilties). (You seemed to miss me changing "ep" to "ei" in the wiki -- I've added the old instructions back and clarified the procedure.)
Just because qemu claims to only work on tun/tap devices doesn't mean it can't be subverted into working on arbitrary network devices. In a perfect world, upstream qemu will create a helper tool that is uses fscaps, etc, and correctly manages the tun/tap devices before launching qemu itself. That reduces the exposure of CAP_NET_ADMIN and makes for a more auditable chunk of code. I'll leave it up to the qemu maintainer in Ubuntu how to handle these things, but I just wanted to confirm that arbitrarily giving everyone CAP_NET_ADMIN (or being setuid root) via qemu was not preferred. If it's done via file permissions and a qemu-runners group, plus fscaps =ep, or done via fscaps =ei and select users are given =i via pam_cap, I don't much care. :) Regardless, fscaps are not supported in Debian/Ubuntu packaging (which I very much want to fix), so this is all a non-issue until that is solved. In the meantime, I feel it is my responsibility to provide as safe a set of instructions that accomplishes the goal of accessing the tun/tap devices. -- qemu no tun/tap networking https://bugs.launchpad.net/bugs/103010 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
