Date: Sun, 06 Aug 2000 23:04:45 -0700 From: Nick Sayer <nsayer@quack.kfu.com> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: freebsd-emulation@FreeBSD.ORG, security-officer@FreeBSD.ORG Subject: Re: vmware changes result in nasty bridging mess Message-ID: <398E517D.A524966F@quack.kfu.com> References: <Pine.NEB.3.96L.1000806223715.90634G-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote: > > On Sun, 6 Aug 2000, Nick Sayer wrote: > > > I think you're overreacting slightly. > > Possibly; I'd like to think I'm reporting a serious set of bugs: one to do > with correctness of a feature, and the other to do with potentially > serious security implications of the feature, which may not have been > fully thought out. I'm not opposed to supporting bridging with vmware, > I'm pointing out that there are substantial problems with the current > implementation, and I'd like it re-thought-out. > > In the mean time, I think it would be wise to disable the sysctl-munging > in vmware.sh, while we fiture out how it should behave. The BRIDGE option > in kernel was not intended to be used in such a hands-free way (i.e., it > requires understanding of the topology, and can interact poorly with other > networking features (IP forwarding/NAT) if not thought through carefully). > We may need to extend the BRIDGE behavior, or tidy it up some, for it to > be used in the way vmware currently attempts to use it. You act as though people are installing vmware largely on machines where complex network topographies exist. I would be more inclined to agree with your position if vmware was something that was part of the default installation. It is not. As such, having it be sure not to offend any possible user is an unnecessary hinderance. vmware does a ton of other things that are detremental from a purely security-conscious point of view. But a more pragmatic view balances that risk against the benefits gained. > > > 1. You are probably the only person on the planet who has a machine with > > both > > bridging and vmware who (aparently) doesn't intend to bridge the guest > > onto > > the connected LAN. This means that you have an opportunity to customize > > the > > startup script rather than insist that everyone have it the way you like > > it. > > Possibly true, but I'm interested in POLA for many situations, not just > the common case. :-) See below, however. But isn't that which astonishes least that which astonishes the least number of people?! > > > 2. In fact, you may be the only person on the planet who has a machine > > with > > bridging, vmware and more than one Ethernet interface active at the same > > time. > > No, I'm worried about the following case: a machine with two interfaces, > and vmware, who then tries out bridging for the purposes of using vmware. Everyone with this configuration, please raise their hands. Remember, to qualify the two interfaces must be run simultaneously. > The result of that operation is not POLA, as the BRIDGE documentation > clearly specifies that to turn on bridging, you set the sysctl, and that > the option is passive until then. As the port is currently written, it > enables BRIDGE at every boot, regardless of a guest running, and affects > more than just the guest environment, bridging all interfaces. And for both of you out there with two Ethernet cards and VMware running, you might want to add a bridge_cfg ioctl between the refresh and the enabling sysctl. > > Also, I pointed out that enabling bridging with if_tap and two different > ethernet devices results in extremely unfortunate behavior: failure of one > to operate at all, and kernel-spewing (per-packet) in the other. I have not been able to duplicate these results, though I have heard it said that wi is incapable of transmitting packets with other than its own Ethernet address, which would disqualify it as the host interface for a bridged vmware configuration. Perhaps that should be added to the hints file. > > > 3. POLA in this case is the opposite of what you think it is. People who > > configure > > their kernels for bridging when they install vmware expect it to work > > when they > > fire up the guest. They would be astonished if it didn't. People > > bringing up > > vmware without bridging turned on would not see the behaviour you > > castigate. I > > believe that everyone running vmware is in one set or the other. Except > > you. > > That is incorrect. People enabling BRIDGE should see the documented > behavior: nothing, until they enable the sysctl. POLA suggests that the > documentation should match the functionality. :-) > > Not only that, users with multiple interfaces (not as uncommon as you'd > like to think -- witness vmware on a box between a DSL modem and a home > network) will find that suddenly the two networks carry each others > traffic. If I had a gateway box like that, I don't think I'd be running vmware on it. I don't think I'm alone. > > > Perhaps in a universe where subnetting was actually possible for > > Internet-connected > > networks the bridged configuration wouldn't be necessary. Perhaps when > > IPv6 is deployed, > > bridges can go away. No one would be happier than I. But until then, I > > don't see a > > problem with catering to the (vast) majority of users by default. > > I'm not clear how bridging relates to IPv6. With IPv6 everyone will have enough subnets that bridging will not be nearly as necessary as it is now. > The bridging issue has to do > with transparency, and throwing arbitrary IP routing into there won't > help. Huh?! > > Probably, approximations of the correct behavior should involve the > following: > > During the install, the vmware user is asked what type of networking > support they want. Responses can include bridged, or non-bridged. If > bridged, they are instructed that they must enable the BRIDGE kernel > option, and decide what bridging means to them. Probably, it means > bridging a specific interface with the if_tap interface, rather than > arbitrarily bridging all interfaces with the if_tap interface. If they > have an existing bridge configured, then they need to decide if if_tap > will be added to that bridge, or be part of a new bridge. All of this is > configured using sysctls, and should probably be in /etc/sysctl.conf, > possibly added/modified with a helper tool. Patches are welcome. > > POLA should mean not making a mess of an existing (potentially > administered) network topology. Also, as I pointed out, this feature is > broken for at least two different driver types -- this may be a function > of the behavior of if_tap in combination with bridging: the vmnet driver > used to (and may still) behave differently if used without a process > attached to the user-land tap device. Clearly, this needs a bit more > debugging, and is probably not ready for prime time. Those of us to whom you complain have not been able to duplicate your failures. I have had no problems at all with or without vmware running. If it didn't work, I doubt those involved (myself included) would have committed it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-emulation" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?398E517D.A524966F>