Jeffrey Hutzelman wrote: > --On Thursday, August 28, 2008 01:16:18 PM -0700 Tony Nguyen > <Truong.Q.Nguyen at Sun.COM> wrote: > >> Scott Rotondo wrote: >>> Tony Nguyen wrote: >>>> >>>> The design strongly encourages your described scenario though >>>> presented differently. The overall policy is split into two global >>>> layers, Global Default and Global Override. >>>> >>>> - Initially, services are set to inherit Global Default's policy so >>>> service specific rules enforces the same policy(block or allow the >>>> same set of network entities). This is the preferred and default >>>> settings for services. >>>> >>>> - Administrator can, however, choose to set a different policy for a >>>> specific service. This action potentially exposes the system, but only >>>> through that service and is a user's conscious decision. >>>> >>>> - The Global Override allows another set of global rules, overall >>>> policy, that takes precedence over the needs of all services. This >>>> explicit global override policy makes it clear services' policies are >>>> restricted by another overall policy. >>> >>> Yes, I got that from reading the design document, and the Global >>> Override seems to accomplish what I was looking for in terms of a global >>> policy that cannot be undone by individual services. >>> >>> However, a highly desirable related property would be assurance that >>> individual service rules cannot conflict with each other. As you said in >>> response to another email: >>> >>>> A service is expected to only generate rules relevant to its network >>>> traffic. >>> >>> It would be ideal if the way of expressing service rules made it >>> impossible to affect other services. I don't think the current syntax >>> for service rules provides that assurance (and it may not be feasible to >>> do so), but it would be great if it could. >>> >> >> Agree, that would be the ideal solution. At the moment, I don't see a >> way to analyze an arbitrary set of rules for a conflicting subset. > > No, of course not; the possibilities offered by ipf are too varied and > complex to allow that. > > What I think Scott was proposing is that services not get to specify > arbitrary ipf rules, but instead get to specify rules in a much more > restrictive language, which is designed such that you _can_ analyze for > conflicts, or even better, such that conflicts cannot occur.
As I clarified in a different post and Dave in another, users do not specify *any* rules. User configures a service's policy (deny/accept and a list of network entities) which is translated to ipf rules based on service's static network information. The only customized rules are those delivered by service developers for services which has more complex network communication. In these cases, the service developers are responsible for correct system functioning when their service is running. -tony
