David Powell wrote:
> 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.
Currently, we use the {inetd | context}/{name | isrpc} properties to
provide service's static information. Given a service's name,
getservbyname(3SOCKET) allows us to get a service's port and protocol
information.
I'm in agreement with a more complete static information. At the moment,
however, we don't have enough knowledge to come up with a set of context
information and a rule generation mechanism that would for "every"
possible service.
>>
>> 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).
Correct. This mechanism also allows client services such as nis/client
and ntp client to produce rules that permit their communication.
>
> 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.
>
