[libvirt] [libvirt PATCHv3 04/10] make default chain policy "DROP"

Stefan Berger stefanb at linux.vnet.ibm.com
Mon Oct 17 17:29:08 UTC 2011


On 10/17/2011 01:04 PM, David Stevens wrote:
> Stefan Berger<stefanb at linux.vnet.ibm.com>  wrote on 10/17/2011 08:50:14
> AM:
>
>
>> I agree with Daniel's previous comments that this could introduce
>> compatibility problems. It would be best not to change it or if really
>> need be later on introduce an XML attribute for a chain that allows to
>> choose whether the default policy is accept or drop.
>          This is not a functional change. With the multiple address
> support, literally all of the chains in question end with "-j DROP".
> By changing the default policy to "DROP", it removes the requirement
> to have the "-j DROP"  _at_the_end_, which makes appending new rules
> without reference to a priority easier.
Yes, '_at_the_end_', that's what I thought. I am not sure whether this 
particular requirement is the best way to proceed since obviously you 
cannot have any other rules with lesser priority after the ones doing 
the 'return' -- whatever those rules may be doing. The alternative would 
be having to instantiate the whole filter chain in the same way as the 
IP address learning thread does with the 'late' filter instantiation 
call -- that would at least get all the priorities correct and not 
introduce a requirement on how one has to write a filter.

>          I think the real sticking point here is whether we consider
> the existing standard chains as immutable. If, for compatibility's sake,
I don't consider them as immutable but should be replaced with something 
of the same or 'better' functionality.
> we keep address matching as:
>          if ($IP != ADDRESS) DROP
>          ACCEPT
>
> then we cannot support multiple IP addresses. If we change this to:
>
>          if ($IP == ADDRESS1) RETURN
>          if ($IP == ADDRESS2) RETURN
>          ...
>          DROP
>
> all of the standard chains end in "-j DROP" and making the policy
> be DROP expresses exactly the same thing with one less rule per chain.
> This also allows appending more allowed addresses without using a
> priority to ensure that "-j DROP" is last.
Yes, I understand that but I don't necessarily like the implications of 
this.

>          Any customization to the old filters that do "DROP" or "ACCEPT"
> will still work and "RETURN" and "CONTINUE" were not supported before,
> so the default, whether done by "-j DROP/ACCEPT" or the policy, don't
> matter-- the custom rule will behave as it does now. It's just that
> that "DROP/ACCEPT" will bypass subsequent checks that are now possible
> if doing "RETURN/CONTINUE" instead.
>          But, of course, *any* change to the standard filters requires
> a review of custom filters that link into them or modify them.
>
>          I think maintaining this level of compatibility simply means
> we cannot support multiple addresses. Doing that obviously requires
> changing the existing address matching filters, which therefore can't
> be linked in in identically the same way. However, I think any
> existing customization is trivial to apply after, too. Perhaps an
> example filter that causes a problem?
I don't have an example filter myself, but I don't know what other 
people may have written.

An alternative would be to say that the existing filters work with the 
IP address learning thread and we would need to introduce new filters 
for support of multiple IP addresses. Yes, the current filters aren't 
prepare for supporting multiple IP addresses per interface.
I don't think replacing the existing filters would be a problem per-se, 
but I don't like that the priority of the rules doing the 'RETURN' is 
assumed to be the lowest in the chain and we can just append anything to 
the end of the chain -- the filters we are writing are just examples and 
someone may come up with a few rules that do something with packets that 
were not RETURN'ed and thus needs to have rules executing behind those. 
Again, maybe (the less efficient but more generic way of) instantiating 
the filters by calling the virNWFilterInstantiateFilterLate() could 
solve part of the problem.


     Stefan
>                                                          +-DLS
>
>
>




More information about the libvir-list mailing list