Darren Reed wrote:
Dave Miner wrote:
...
Yes it is, otherwise customers will find themselves with Solaris
systems that don't
work when all of a sudden loopback RPC no longer functions. Further,
while customers
may be using zones and want IPFilter between them, above all else, by
default it needs
to be backward compatible with today's environment.
Not that I care that much about this point, but you could conceivably
provide default rulesets which provided exactly the current behavior
and enable loopback filtering. The real issue, to me, is that it's
incredibly clumsy to have to go muck with /etc/system and reboot if I
want to use zones and filtering, which is clearly a very desirable
model. This seems like a very high-priority RFE for IPFilter.
In making it easy to enable loopback filtering, it changes the nature of
this choice from being a policy decision to something that can be more
ad-hoc. I'm concerned about the nature of that from a security
perspective - can it become too easy to accidently disable/enable?
I've heard several respected security thinkers take the position that
ease-of-use for security features makes them more likely to be used
effectively.
Do you view being able to enable/disable it via the driver's .conf file
as being equally clumsy?
I'd rather put it in terms of what I'd think would be the user requirements:
- it should be easy for the user to make this selection in the context
of other tasks they'd be doing to configure the filtering feature. It
should be part of what they'd normally do to set other aspects of
filtering policy.
- it must not require a reboot or similarly serious discontinuity of
system services to take effect.
If you could meet those requirements putting it in /etc/system, or a
driver .conf file, then I wouldn't necessarily care.
Dave
_______________________________________________
networking-discuss mailing list
[email protected]
