[libvirt] [libvirt PATCHv3 03/10] reverse sense of address matching

[Stefan Berger]

On 10/25/2011 03:41 PM, David Stevens wrote:
> Stefan Berger<stefanb at linux.vnet.ibm.com>  wrote on 10/25/2011 12:01:05
> PM:
>
>> So the intention here was to remove the 'arp' chain. With it staying now
>> I suppose this patch and the allow-arpmac and allow-arpip aren't needed.
>>> diff --git a/examples/xml/nwfilter/allow-arpip.xml b/examples/xml/
>> nwfilter/allow-arpip.xml
> The intention was to separate MAC and IP address matching to be their
> own chains to make adding and removing addresses dynamically easy. If you
> do this in one chain with "IP=X and MAC=Y -j ACCEPT", then you need
> every combination of IP and MAC address as a rule. If you separate them
The current (proposed) iterator does this, it produces every combination 
of IP and MAC list items. The question is whether this is the correct 
way of producing the filtering rules. On the one side one could say that 
the VM (or nested VMs) owns all the given MAC and IP addresses and can 
produce any combination of them. So we'll have m*n combinations -> 
O(n^2) evaluations.
Another possibility would be to walk the lists of MAC and IP addresses 
parallel, i.e. produce a rule for $MAC[0] and $IP[0], another one for 
$MAC[n] and $IP[n], thus enforcing the association of IP and MAC 
addresses. We'd have O(n) evaluations, though the number of rules to 
evaluate should not drive how this works, but obviously 'correctness'.
If we split the evaluation into two chains (one for IP , the other for 
MAC checking) we allow all combinations. Complexity is O(2*n) -> O(n).

So what should be correct?Fixed IP - MAC association or allow any 
combination of them? Maybe we leave it as proposed (two chains) for now 
and modify the iterator to process multiple lists' elements in parallel...
> into MAC matching and protocol matching chains, you need one rule
> per MAC and IP address. After doing that, the ARP chain was empty, since
> that's all the standard chain had.
>
Yes, fine. For backwards compatibility purposes the 'arp' chain will remain.
>>> new file mode 100644
>>> index 0000000..6ddb6fe
>>> --- /dev/null
>>> +++ b/examples/xml/nwfilter/allow-arpip.xml
>>> @@ -0,0 +1,3 @@
>>> +<filter name='allow-arpip' chain='arpip'>
>>> +<rule direction='inout' action='accept'/>
>>> +</filter>
>> Seems no necessary following above.
> I don't understand this comment.
>
With the arp chain remaining we can keep the existing filter 'allow-arp' 
and don't need the one proposed in this patch.
>> This reshuffeling might make it more intuitive but isn't necessary.
> I didn't say it was the only way to support multiple addresses. :-)
> It uses nMAC + nIP rules, instead of nMAC X nIP rules to match every
> combination of MAC and IP addresses in the original ARP chain.
>
>>> +</rule>
>>> +<rule action='return' direction='out' priority='410'>
>>> +<arp match='yes' arpsrcipaddr='0.0.0.0' />
>>> +</rule>
>> Under what circumstances is the stack allowed to send a 0.0.0.0 as a
>> response to an ARP request (presumably)? Form what I see 0.0.0.0 could
>> be any machine whose interface is not configured. At least when using
>> DHCP the VM would broadcast the request without prior sending of an ARP
>> request (of course) and from what I remember the DHCP server then sends
>> the response back to the MAC address it has received the request from
>> also without ARP request.
> This isn't a requirement, but in general, the filters are placing
> restrictions on packets that have nothing to do with spoofing and are
> not part of the underlying protocols. A host without an IP address
> can use source address "0.0.0.0" legally by the protocols in cases besides
> sending a DHCP request, DHCP requests need not be MAC broadcast or sent
> to the all-hosts broadcast address (e.g., if firmware configured a
> particular
> preferred server (unicast MAC and/or IP), or knows the subnet and uses
> a directed broadcast). ARP requests received from other machines need
> not be addressed to this VM to be processed and update the cache.
I didn't test with a well-known DHCP server, so I was not sure whether 
the rule would actually be used. Following the DHCP protocol fields one 
could broadcast and put the IP address of the server into the server 
address field in the DHCP protocol and if the protocol was to support it 
that way only that server could respond

> By restricting these cases, the filters prevent VMs from doing
> protocol-legal things that have nothing to do with spoofing. It simply
> breaks unusual configurations unnecessarily.
>
> I was planning to submit clean-up patches to remove all these
> restrictions I found after my primary concern (DHCP snooping) is done.
> I threw in some of them along with the multiple address support in
> the version that did that, but they really are separate fixes that
> have nothing to do with either multiple address support or DHCP
> snooping.
>
> In the end, base anti-spoofing rules should prevent a VM from
> masquerading as someone else, and allow everything else.
>
>                                                                  +-DLS
>