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:
> > In addition the DMTF XML format illustrated above is seriously ugly
> > and not following the style of other libvirt XML formats. The use
> > of UPPERCASE alone is reason enough to create a native libvirt format
> > for this. We should of course ensure that whatever we do can be
> > reliably mapped into the DMTF format via a simple XSL transform.
> >
> > Daniel
>
> Hi, we have been thinking about the comments regarding the XML format
> and hope the following is more in line with other libvirt XML formats:
>
> As Stefan proposed originally, the guest interface has an additional
> firewall. The firewall can have several filters, some of which are
> generic and template based and some are guest specific. The template
> filters can take parameters.
> The filters contain rules, currently for mac, arp, vlan and ip. A rule
> is applied if the conditions specified by the attributes and their
> values are true and the specified action will happen. The match
> attribute can be used to specify that the action should happen if the
> condition is not true.
> If an attribute is supplied on a rule but its value is empty (''), the
> supplied parameter for a template or the respective value for the
> current interface is used.
>
> This will need a few more examples to verify it is sufficient, but here
> is the current status:
>
> The guest xml file:
> -------------------
> <domain type='kvm'>
> <name>demo</name>
> <memory>256000</memory>
> <devices>
> <interface type="bridge">
> <firewall>
> <filter template='drop-all'/>
> <filter template='no-arp-spoofing' srcipaddr='10.0.0.1'/>
> <filter template='no-mac-spoofing'/>
> <filter template='no-ip-spoofing srcipaddr='10.0.0.1'/>
> <filter>
> <!-- allow outgoing IPV4 packets with the
> guest mac addr and vlanid 3 -->
> <rule action='allow' direction='out'>
> <mac srcmacaddr='' />
> <vlan id='3'/>
> <ip version='4'/>
> </rule>
>
> <!-- only accept non-IPV6 packets from
> 'aa:bb:cc:dd:ee:ff' -->
> <rule action='allow' direction='in'>
> <mac srcmacaddr='aa:bb:cc:dd:ee:ff' />
> <vlan id='3'/>
> <ip match='no' version='6'/>
> </rule>
>
> <!-- no access to port 25 allowed -->
> <rule action='allow' direction='in'>
> <ip match='no'
> dstportstart = '25'
> dstportend = '25' />
> </rule>
> </filter>
> </firewall>
> </interface>
> </devices>
> </domain>
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.
> The template xml files could be similar to this:
> ------------------------------------------------
>
> <firewall>
> <!-- by default drop everything -->
> <template name='drop-all'>
> <filter policy='drop' />
> </template>
>
> <template name='no-arp-spoofing'>
> <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=''/>
> <arp match='no' srcipaddr='' />
> </rule>
> <!-- drop if ipaddr or macaddr does not belong to guest -->
> <rule action='drop' direction='in'>
> <arp match='no' dstmacaddr=' '/>
> <arp match='no' dstipaddr='' />
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
> </rule>
> <!-- allow all other request or reply packets -->
> <rule action='allow' direction='inout'>
> <arp opcode='request'/>
> <arp opcode='reply'/>
> </rule>
> </filter>
> </template>
>
> <template name='no-mac-spoofing'>
> <filter name='DLFT'>
> <!-- no mac spoofing -->
> <rule action='drop' direction='out'>
> <mac match='no' srcmacaddr=''/>
> </rule>
> </filter>
> </template>
>
> <template name='no-ip-spoofing'>
> <filter name='IPv4'>
> <!-- no ip spoofing -->
> <rule action='drop' direction='out'>
> <ip match='no' srcipaddr=''/>
> </rule>
> </filter>
> </template>
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
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list