Re: vmware changes result in nasty bridging mess
On Tue, Aug 08, 2000 at 02:36:02PM +0900, Akinori -Aki- MUSHA wrote: At a quick glance, "start_bridge" doesn't seem to have chance to be 1, does it? It's depend. I'm pretty tired that discussian about bridging. So if people want to use bridge let set start_bridge to 1, if not leave it in zero. Also it's possible to setup that value at configuration stage, whatever. And, what's the difference among those three values of "bridge"? To diagnostic current behaviour about bridging. + bridge="_bridge_on" Startup script configured do not touch bridging and at the time when script starting, bridging was enabled. + bridge="_bridge_off" /.../ disabled. + bridge="_bridge" Script configured to setup bridging and did successfully When bridge == "" its means that kernel compiled without bridging support, or outdated kernel. -- Vladimir To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vmware changes result in nasty bridging mess
Ok, guys.
See in the attachment fix, you should apply it to prevent current behavior.
On Sun, Aug 06, 2000 at 07:14:59PM -0400, Robert Watson wrote:
On Thu, 3 Aug 2000, Vladimir N. Silyaev wrote:
Bridging on by default may
have nasty side effects for multi-interface machines (especially security
side effects).
It's several ways to work around about that:
- compile kernel without bridging support.
- remove bridge starting code vmware.sh file in rc.d directory.
- create special bridge cluster with one real interface and with one emulated
Actually, I was hoping that the vmware port wouldn't interfere with
existing configurations on the box :-). I compile in the BRIDGE code so
that I can test/develop with it, not so that ethernet support on the
notebook can be broken after I install the vmware port, or so that a port
can arbitrarily turn on bridging of all attached ethernet devices.
I haven't read the code (I admit) but I finding the
current behavior both (a) irritating (messages) and (b) worrying
(unpredicted bridging with potential side effects).
I don't know I never seen such effect. Could you to do more testing
about that.
The behavior with the wi0 ethernet driver seems to be continuous printing
of the output included in my previous message.
With the ep0 driver, the results are actually much worse -- I'm unable to
use networking at all while the bridging sysctl is enabled (the default).
While the sysctl is enabled, dhclient fails for that interface, and any
attempt to manually configure and use it results in a route not found.
When I disable the sysctl, networking begins to work on the box.
The following default-installed startup script is really, really scary:
sysctl net.link.ether.bridge_refresh bridge="_bridge"
kldload if_tap.ko
echo -n /compat/linux/dev/vmnet1
ifconfig vmnet1 $host_ip netmask $netmask
if [ _$bridge != _ ]; then
sysctl -w net.link.ether.bridge_refresh=1
sysctl -w net.link.ether.bridge=1
fi
Un-announced, the vmware port enabled bridging between the ethernet
interfaces on my notebook, generated voluminous output for wi0, and broke
networking for ep0. This is a security risk, in that it automatically
enables bridging between previously un-connected LAN segments that may
have different security properties. This is against POLA in that it
breaks functionality (networking), bridges packets unto unexpected
segments (potentially breaking many other things, especially DHCP), etc.
Previously, use of networking support would create a virtual network
between the host and the guest OS, but not affect other networking
functionality.
--
Vladimir
Index: files/vmware.sh
===
RCS file: /home/vns/cvs/vmware/vmware/vmmon-only/freebsd/port/files/vmware.sh,v
retrieving revision 1.5
diff -u -r1.5 vmware.sh
--- files/vmware.sh 2000/07/31 00:54:37 1.5
+++ files/vmware.sh 2000/08/07 03:16:16
@@ -8,6 +8,7 @@
networking=@@NETWORKING@@
host_ip=@@HOST_IP@@
netmask=@@NETMASK@@
+start_bridge=0
[ -x $vmware_dir/bin/vmware ] || exit
@@ -19,17 +20,32 @@
exec /dev/null
+if [ $networking -eq 1 ]; then
+ if sysctl net.link.ether.bridge_refresh; then
+ if sysctl net.link.ether.bridge|grep 1; then
+ bridge="_bridge_on"
+ start_bridge=0
+ else
+ if [ $start_bridge -eq 1 ]; then
+ bridge="_bridge"
+ else
+ bridge="_bridge_off"
+ fi
+ fi
+ fi
+fi
+
case $1 in
start)
kldload ${vmware_dir}/lib/modules/vmmon_${suffix}.ko
if [ $networking -eq 1 ]; then
- sysctl net.link.ether.bridge_refresh bridge="_bridge"
kldload if_tap.ko
echo -n @@LINUX_DIR@@/dev/vmnet1
ifconfig vmnet1 $host_ip netmask $netmask
+ sysctl net.link.ether.bridge
if [ _$bridge != _ ]; then
sysctl -w net.link.ether.bridge_refresh=1
- sysctl -w net.link.ether.bridge=1
+ [ $start_bridge -eq 1 ] sysctl -w net.link.ether.bridge=1
fi
fi
echo -n " VMware${bridge}" 2
@@ -40,7 +56,6 @@
if [ $networking -eq 1 ]; then
ifconfig vmnet1 down
ifconfig vmnet1 delete $host_ip
- sysctl net.link.ether.bridge_refresh bridge="_bridge"
[ _$bridge != _ ] sysctl -w net.link.ether.bridge_refresh=1
fi
;;
Re: vmware changes result in nasty bridging mess
At a quick glance, "start_bridge" doesn't seem to have chance to be 1, does it? And, what's the difference among those three values of "bridge"? + bridge="_bridge_on" + bridge="_bridge" + bridge="_bridge_off" -- / /__ __ / ) ) ) ) / Akinori -Aki- MUSHA aka / (_ / ( (__( @ idaemons.org / FreeBSD.org "We're only at home when we're on the run, on the wing, on the fly" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vmware changes result in nasty bridging mess
On Thu, 3 Aug 2000, Vladimir N. Silyaev wrote: Bridging on by default may have nasty side effects for multi-interface machines (especially security side effects). It's several ways to work around about that: - compile kernel without bridging support. - remove bridge starting code vmware.sh file in rc.d directory. - create special bridge cluster with one real interface and with one emulated Actually, I was hoping that the vmware port wouldn't interfere with existing configurations on the box :-). I compile in the BRIDGE code so that I can test/develop with it, not so that ethernet support on the notebook can be broken after I install the vmware port, or so that a port can arbitrarily turn on bridging of all attached ethernet devices. I haven't read the code (I admit) but I finding the current behavior both (a) irritating (messages) and (b) worrying (unpredicted bridging with potential side effects). I don't know I never seen such effect. Could you to do more testing about that. The behavior with the wi0 ethernet driver seems to be continuous printing of the output included in my previous message. With the ep0 driver, the results are actually much worse -- I'm unable to use networking at all while the bridging sysctl is enabled (the default). While the sysctl is enabled, dhclient fails for that interface, and any attempt to manually configure and use it results in a route not found. When I disable the sysctl, networking begins to work on the box. The following default-installed startup script is really, really scary: sysctl net.link.ether.bridge_refresh bridge="_bridge" kldload if_tap.ko echo -n /compat/linux/dev/vmnet1 ifconfig vmnet1 $host_ip netmask $netmask if [ _$bridge != _ ]; then sysctl -w net.link.ether.bridge_refresh=1 sysctl -w net.link.ether.bridge=1 fi Un-announced, the vmware port enabled bridging between the ethernet interfaces on my notebook, generated voluminous output for wi0, and broke networking for ep0. This is a security risk, in that it automatically enables bridging between previously un-connected LAN segments that may have different security properties. This is against POLA in that it breaks functionality (networking), bridges packets unto unexpected segments (potentially breaking many other things, especially DHCP), etc. Previously, use of networking support would create a virtual network between the host and the guest OS, but not affect other networking functionality. Robert N M Watson [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vmware changes result in nasty bridging mess
On Sun, 6 Aug 2000, Robert Watson wrote: Un-announced, the vmware port enabled bridging between the ethernet interfaces on my notebook This is bad - ethernet segments should not be bridged without explicit user confirmation, because they are commonly separated precisely for security reasons. Someone please fix the port appropriately..thanks. Kris FreeBSD Security Officer Team -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: vmware changes result in nasty bridging mess
I'm using vmware2 in a different way ... I do not have bridging enabled in the kernel. I'm using the host method although I do not have a "legal" subnet on the other side. I've ment to contact the port maintainer so he can add this to the Hints.FreeBSD file. I've configured 10.1.1.1 for the vmnet device, and 10.1.1.2 in windows. I use ipfw and natd to translate the info ... this works like a charm. I'm using the latest port of vmware and I don't see those messages, probably because I do not have BRIDGING enabled in the kernel. For thos interested .. here is the natd and ipfw rules. natd -u -a my_legal_ip ipfw a 3 divert natd all from 10.1.1.2 to any out via vr0 ipfw a 4 divert natd all from any to my_legal_ip in via vr0 I'm even accessing the NT servers :), browsing bla bla bla :) Regards Reinier On 02-Aug-00 Robert Watson wrote: bridge_in-- reading table bridge_in-- reading table bridge_in-- reading table bridge_in-- reading table bridge_in-- reading table bridge_in-- reading table bridge_in-- reading table bridge_in-- reading table bridge_in-- reading table ... The vmware2 port now seems to enable bridging by default, and generate a kernel message for every ethernet packet sent. Bridging on by default may have nasty side effects for multi-interface machines (especially security side effects). I haven't read the code (I admit) but I finding the current behavior both (a) irritating (messages) and (b) worrying (unpredicted bridging with potential side effects). Robert N M Watson [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message ### # # # R.N. Bezuidenhout NetSeq Firewall # # [EMAIL PROTECTED] http://www.nanoteq.co.za# # # ### -- Date: 03-Aug-00 Time: 09:04:34 This message was sent by XFMail -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: vmware changes result in nasty bridging mess
On Thu, 3 Aug 2000, Reinier Bezuidenhout wrote: I'm using vmware2 in a different way ... I do not have bridging enabled in the kernel. I'm using the host method although I do not have a "legal" subnet on the other side. That was the configuration I was using also, until I upgraded my version of -STABLE, and as a result had to upgrade my vmware port. The results thus far have been a little worrying, and I'd like to see them fixed before too many people get hurt. Robert N M Watson [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vmware changes result in nasty bridging mess
In muc.lists.freebsd.hackers, you wrote: bridge_in-- reading table bridge_in-- reading table bridge_in-- reading table bridge_in-- reading table bridge_in-- reading table bridge_in-- reading table bridge_in-- reading table bridge_in-- reading table bridge_in-- reading table ... The vmware2 port now seems to enable bridging by default, and generate a kernel message for every ethernet packet sent. FreeBSD bridge code doesn't have any vmware related modifications. Only one modification what was impelmented, it's a special sysctl net.link.ether.bridge_refresh, which provied support for loadable ethernets drivers. The rest of bridging code didn't touched at all. Bridging on by default may have nasty side effects for multi-interface machines (especially security side effects). It's several ways to work around about that: - compile kernel without bridging support. - remove bridge starting code vmware.sh file in rc.d directory. - create special bridge cluster with one real interface and with one emulated I haven't read the code (I admit) but I finding the current behavior both (a) irritating (messages) and (b) worrying (unpredicted bridging with potential side effects). I don't know I never seen such effect. Could you to do more testing about that. -- Vladimir To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
vmware changes result in nasty bridging mess
bridge_in-- reading table bridge_in-- reading table bridge_in-- reading table bridge_in-- reading table bridge_in-- reading table bridge_in-- reading table bridge_in-- reading table bridge_in-- reading table bridge_in-- reading table ... The vmware2 port now seems to enable bridging by default, and generate a kernel message for every ethernet packet sent. Bridging on by default may have nasty side effects for multi-interface machines (especially security side effects). I haven't read the code (I admit) but I finding the current behavior both (a) irritating (messages) and (b) worrying (unpredicted bridging with potential side effects). Robert N M Watson [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
