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.)
-Will
> _______________________________________________
> security-discuss mailing list
> security-discuss at opensolaris.org
>
