similar to: Bug#698841: xen-utils-common: HVM networking for ioemu devices is blocked when antispoof is on

This patch adds an ACM hook into the network scripts (/etc/xen/scripts). It adds iptables rules that enforce mandatory access control on network packets exchanged between virtual interfaces. If ACM is active, this patch sets the default FORWARD policy in Dom0 to DROP and adds iptables ACCEPT rules between vifs that belong to domains that are permitted to share (determined by using the

Hello with XEN 3.4.x antispoof=yes works on a bridge setup. I am using this line in xend-config.sxp (network-script ''network-bridge antispoof=yes'') It creates this under IPTABLES FORWARD chain: ACCEPT all -- anywhere anywhere PHYSDEV match --physdev-in peth0 Under XEN 4.0.1 it is not working, it does not create a IPTABLES rule. Customers can

Processing commands for control at bugs.debian.org: > forcemerge 613540 698841 Bug #613540 [xen-utils-common] xen-utils-common: iptables rules missing for qemu tap interfaces Bug #698841 [xen-utils-common] xen-utils-common: HVM networking for ioemu devices is blocked when antispoof is on Severity set to 'normal' from 'important' Marked as fixed in versions xen/4.2.1-1. Marked

Package: xen-utils-common Version: 4.8.3+comet2+shim4.10.0+comet3-1+deb9u5 Severity: important Tags: patch security -- System Information: Debian Release: 9.4 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),

Hi folks, I started testing the antispoof feature of xen stable (2.0.7). I am stuck with it. I have setup a standard bridged environment. I understood it like this: in domU config I set up the virtual NIC like vif = [ ''mac=ae:00:00:78:78:78, ip=192.168.0.100'' ] Then I configure /etc/network/interface of this domU to show the same IP address for eth0. After restarting

When start a domU through xl create. The domU associated ip in the configuration file is not recorded in the xenstore. For this reason vif-common.sh antispoof scripts fails. *xl create * /usr/bin/xenstore-ls /local/domain/0/backend/vif/5/0 frontend = "/local/domain/5/device/vif/0" frontend-id = "5" online = "1" state = "4" script =

CentOS 5.5 Xen "standard" Xen Installation. I have two nics. I just put the second one to DHCP and modified the ifcfg-et01 and so far I am holding, but I am not confident. Prior they were sequential IP Addrs on same subnet. arpwatch has indicated flip flips. I can find no rhyme or reason to predict them. I know I missed I must have missed a step somewhere. I want to keep the

Hi folks, I am trying to get antispoofing running on xen3 (based on Debian Sarge). This is what I have done to enable it: 1. I have compiled a dom0 kernel with CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m 2. I made sure this module is loaded: lsmod gives xt_physdev (among others). 3a. I have changed the line "(network-script network-bridge)" to "(network-script network-bridge

Package: xen-utils-common Followup-For: Bug #430778 Here's a patch I made to have working rules here... feel free to comment/adapt. Hope this helps -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-xen-686 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8,

Hey everyone, I have a question about vif-common.sh. I run multiple bridges attached on dummy interfaces, which allow me to put guests in seperate subnets (routed through the dom0). As you might expect I already have quite extensive iptables scripts to accomidate this kind of routing. I was just hoping someone on this list can confirm, that I understand what the iptables lines in vif-common.sh

Hi all. What right way to protect ip/mac spoofing for guests withnount dhcp and other 1 ip per guest?

Hi, have a debian 5.0 with all patches and xen 4.3.1 (debian repo) installed. If I use a VM with paravirtualizing it works fine. But a full virtualized image doesn''t boot. Message: ---8<--- # xm create deb50.cfg: Error: Device 2049 (vbd) could not be connected. Hotplug scripts not working. ---8<--- That is my deb50.cfg ---8<--- # Debian 5.0 import os, re arch = os.uname()[4]

Package: xen-utils-common Version: 4.1.4-3 Severity: important Dear Maintainer, While updating my xen package today, I was prompted with a config file conflict. --- /etc/xen/scripts/hotplugpath.sh 2013-04-28 01:51:20.899778510 +0800 +++ /etc/xen/scripts/hotplugpath.sh.dpkg-new 2013-04-19 19:39:55.000000000 +0800 @@ -1,12 +1,10 @@ SBINDIR="/usr/sbin" BINDIR="/usr/bin"

Package: xen-utils-common Version: 4.1.4-3 Severity: important Dear Maintainer, Executive summary: dist-upgrade - squeeze to wheezy. Rebooted machine; no default route on network interface eth0. Commented 'transfer_addrs' function in network-bridge produced a machine which worked after reboot. We're using network-bridge as our xen networking configuration. After rebooting the

Hi xen-devel, I have been trying to pcihide a NIC from dom0 and directly claim it on domU. The dom0 had come up with the bnx2 driver claiming the nic card, but after that i did an unbind and bound the pciback driver with this interface. lspci on domU shows the only pci device and it is claimed by the bnx2 driver.However the link of the interface as shown by ethtool continues to be down. When i

Hi, I have Xen 3.0.3 installed on CentOS 5.5 with 2 paravirtualized domU''s configured to use the default bridge networking and am having networking issues. If I boot the computer fresh I am able to ping dom0 and can SSH into it and start the domU''s. The following ping snippet demonstrates the problem. The first group of "Destination Host Unreachable" is while the

Package: xen-utils-common Version: 4.1.4-3+deb7u1 Severity: normal Dear Maintainer, i changed toolkit to xl, after that i observe that my domU started as HVM domains. I found same problem here: http://mail-index.netbsd.org/port-xen/2012/04/11/msg007216.html When i manualy setup loop devices and specify it as disks in my VM conf file, domU started as PV. -- System Information: Debian Release: 7.1

Package: xen-utils-common Version: 4.1.3~rc1+hg-20120614.a9c0a89c08f2-2 Severity: important Please modify the init scripts in a manner similar to the following to give the correct SE Linux labels. Failing to correctly label them may result in Xen not working correctly when SE Linux is enabled. --- /etc/init.d/xen.orig 2012-06-24 10:29:04.000000000 +1000 +++ /etc/init.d/xen 2012-06-24

Package: xen-utils-common Version: 4.0.0-1 Severity: normal When a qemu hvm with vif=['type=ioemu,bridge=eth0'] is created, xen will successfully create the required vif and tap bridge interfaces, but will create the corresponding iptables filter rules for the vif interface only, not the tap interface. With a FORWARD policy of DROP (e.g. by enabling antispoofing) network traffic from/to

Here is the situation. I have a xen system with 2 drives setup in a RAID1. I pulled one drive and put it into an identical server. Now, when I boot up the new server, peth1 is not created. [root@dom0 ~]# ifconfig | grep Link eth1 Link encap:Ethernet HWaddr 00:14:38:A7:55:C2 inet6 addr: fe80::214:38ff:fea7:55c2/64 Scope:Link lo Link encap:Local Loopback vif1.0 Link