Will Young wrote: > Nicolas Williams wrote: >> The idea that a service describes its networking patterns so that IPF >> can take them into account is very neat, but not sufficient to get rid >> of packet filtering rules: not everything is a service under SMF >> management. >> > Right, I view the how they handle the policy they apply before and > after active service derived policy as their private choice: > >>> I don't think that point is sufficient to dismiss the lack of >>> abstraction for services manifest contents. Only the policy above and >>> bellow services can be a private API between ipfilter and vpanels. > > I'm really only looking for all the static knowledge about the > services that I'm assuming will get buried in ipf_method(s), (like the > manifest is talking about ssh right now so we think this is in reference > to tcp port 22.) Without this kind of knowledge anything that tries to > get as much use as ipfilter out of the added data really can't without > knowing a lot of gibberish. > > I certainly wouldn't complain if it was also easy to determine > how/if ipfilter was applying the data but there are plenty of other > things of equal importance we wont know without product specific > knowledge (i.e. the IPsec/IKE config.)
I think Tony's intent is for the firewall configuration to be descriptive whenever possible. ipf_method is only meant as an escape hatch for cases when the IPFilter configuration required for the service gets complicated. This could be because the service's use of networking is inherently complicated, or because the needs of the service aren't obvious (e.g. when the port the service is using is a tunable buried in a service-specific config file). As time goes on and we learn more about the kinds of exceptions that need to be made, the firewall context could be expanded to obviate certain classes of ipf_methods. Front-loading such an analysis, however, would be expensive and would most likely produce an over- engineered product. Dave
