Date: Sun, 6 Aug 2000 22:49:43 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Nick Sayer <nsayer@quack.kfu.com> Cc: freebsd-emulation@FreeBSD.ORG, security-officer@FreeBSD.ORG Subject: Re: vmware changes result in nasty bridging mess Message-ID: <Pine.NEB.3.96L.1000806223715.90634G-100000@fledge.watson.org> In-Reply-To: <398E0DC8.745E02F9@quack.kfu.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > 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. > 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. 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. 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. > 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. > 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. The bridging issue has to do with transparency, and throwing arbitrary IP routing into there won't help. 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. 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. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services 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?Pine.NEB.3.96L.1000806223715.90634G-100000>