On Mon, 2010-01-25 at 14:59 +0000, Daniel P. Berrange wrote:
> On Fri, Jan 22, 2010 at 01:29:16PM +0100, Gerhard Stenzel wrote:
> > On Wed, 2010-01-13 at 17:36 +0000, Daniel P. Berrange wrote:
...
>
> The shear size of the ruleset inside the <interface> element is
> rather alarming to me. Imagine if you have a guest with more
> than one NIC. I'm inclined to suggest that the <interface>
> element in the domain XML description should only have a single
> rule
>
> <filter name='BLAH'/>
>
> and if apps wish to construct a filter, from multiple independant
> sub-filters, then that should be done against the filter object's
> config, rather than the domain object's config.
>
...
> What was the idea with the empty attributes here ? Are those
> implying that the attribute value is to be filled in with the
> value from the domain XML ? If so I'd probably make that more
> explicit using something like $IP and $MAC to represent the
> guest configured IP/MAC
>
...
> I don't think that '<firewall>' is the top level object to be managed
> here. I would suggest that '<firewall>' and '<template>' elements are
> redundant, and that <filter> should be for the top level managed objects.
> The libvirt API would allow listing of existing filters, creating / deleting
> filters and updating the config. The <filter> element would allow some kind
> of <include> element to allow a complex filter to be built out of multiple
> simpler filters.
>
>
> Regards,
> Daniel
Daniel,
ok, trying to combine your suggestions:
- guest contains a single filter reference per interface
guest.xml:
----------
<domain type='kvm'>
<name>demo</name>
<memory>256000</memory>
<devices>
<interface type="bridge">
<filter name='demofilter' ipaddr='10.0.0.1'/>
</interface>
</devices>
</domain>
- complex filter include other filter and can contain rules
complex demofilter.xml:
-----------------------
<filter name='demofilter'>
<include href='drop-all'/>
<include href='no-arp-spoofing' srcipaddr='$IP'/>
<include href='no-mac-spoofing'/>
<include href='no-ip-spoofing' srcipaddr='$IP'/>
<!-- no ip spoofing -->
<rule action='drop' direction='out'>
<ip match='no' srcipaddr='$IP'/>
</rule>
</filter>
- simple filter contain only rules
simple no-arp-spoofing.xml:
---------------------------
<filter name='ARP' policy='drop'>
<!-- no arp spoofing -->
<!-- drop if ipaddr or macaddr does not belong to guest -->
<rule action='drop' direction='out'>
<arp match='no' srcmacaddr='$MAC'/>
<arp match='no' srcipaddr='$IP' />
</rule>
<!-- drop if ipaddr or macaddr does not belong to guest -->
<rule action='drop' direction='in'>
<arp match='no' dstmacaddr='$MAC'/>
<arp match='no' dstipaddr='$IP' />
</rule>
<!-- allow all other request or reply packets -->
<rule action='allow' direction='inout'>
<arp opcode='request'/>
<arp opcode='reply'/>
</rule>
</filter>
- $IP, $MAC represent the guests configured IP,MAC values
If the above seems acceptable for the moment, I would suggest we verify that this is actually implementable or if we missed something.
--
Best regards,
Gerhard Stenzel,
-----------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list