On 11/09/2009 04:20 PM, Anthony Liguori wrote:
Avi Kivity wrote:
On 11/08/2009 12:11 AM, Anthony Liguori wrote:
You don't need root privileges to use a tap device.
You can access a preconfigured tap device but you cannot allocate a
tap device and connect it to a bridge without CAP_NET_ADMIN.
btw, shouldn't we, in the general case, create a bridge per user and
use IP NAT? If we have a global bridge, users can spoof each other's
MAC addresses and interfere with their virtual machines.
qemu-bridge-helper supports that model quite well :-) You would
create a NAT'd bridge for each user as the administrator, then create
a bridge.conf that consisted of per-user includes with appropriate
permissions set on each of those files.
Except that the out-of-the-box experience is "go and configure things"
again.
Really, bridging is fairly complex. You have to set up the bridge,
perhaps with NAT, perhaps to the physical device (possibly fighting a
bit with NetworkManager in that case), allocate MAC addresses in a
nonconflicting way, set up DHCP, and if you are multiuser, protect users
from each other, and protect the host from guests.
They can also interfere with the real network.
That's not a concern with most one-user-per-machine configurations,
but the default configuration should be safe.
Let's not kid ourselves, no matter what we do we're giving a user
elevated privileges. Even with NAT, if the host can access the NAT'ed
network, then you can run a privileged service (like NFS) in that
network. Like it or not, some networks rely on privileged services
being trusted as part of their security model (consider NIS).
At least on commercial Linux vendor exports NFS home directories with
the 'secure' option, requiring a privileged port to mount NFS shares.
If your patch falls into the wrong hands, virtualization developers
working at such a vendor might be able to access their home directories
from guests, which would annoy IT immensely.
I think the best we can do is provide a tool that allows an
administrator to grant users additional privileges in the tiniest
increments possible. Putting people in wheel just so they can do
virtualization is too much.
I'm concerned that we're confusing the situation instead of clearing
it. Telling users to "edit /etc/foo/bar" so you can run bridging
without fully explaining the impact is not responsible. Trusting
libvirt to do it end-to-end is fine, but in this case it can also set up
the tap itself.
I don't see having an fscap-based helper as creating policy. I see it
as adding a mechanism for administrators to create policy.
I'll summarize my current issues with the patchset:
- by introducing an suid/fscap helper we're expanding the scope of
security in qemu. In addition to protecting qemu against malicious
guests trying to gain local user privileges, we need to protect it
against malicious local users trying to gain root (or CAP_NET_ADMIN)
privileges
- we're introducing yet another authorization mechanism. We have
enough. We already have feedback that policykit is wanted in at least
some cases. Given that authorization is best kept consistent in a
distro, and that distros try to be as inconsistent from each other as
possible, we can't please everyone.
- for the command-line user, we aren't providing a full solution; they
still have a lot of configuration to do before things work (especially
if they don't already have a network segment with DHCP)
- for libvirt and other management systems, it is insufficient since
they will at least in some cases need to perform privileged
configuration before handing the tap to the guest. So they still need
to be privileged and they can't use -net bridge for hotplug.
I would be happier if we drop suid/fscap from the helper. We can have a
user-provided script or binary gain the necessary privileges (using sudo
or policykit or whatever). This way we don't need to deal with local
privilege escalation vulnerabilities.
--
error compiling committee.c: too many arguments to function
