Darren Reed wrote: > Nicolas Williams wrote: >> On Wed, Sep 24, 2008 at 12:14:33PM +0200, Darren Reed wrote: >> >>> Below are the properties, their possible values and correspoding >>> semantics: >>> >>> policy >>> >>> "none" policy mode - no access restriction. For a global policy, >>> this >>> mode allows all incoming traffic. For a service policy, this mode >>> allows all incoming traffic to its service. >>> >>> "deny" policy mode: more restrictive than "none". This mode allows >>> incoming traffic from all sources except those specified in the >>> "apply_to" property. >>> >>> "allow" policy mode: most restrictive mode. This mode blocks >>> incoming >>> traffic from all sources except those specified in the "apply_to" >>> property. >>> >> >> I find this confusing or likely to be confusing. >> >> How about: >> >> "any" -> allow all incoming >> "blacklist" -> allow all incoming where source not on blacklist >> "whitelist" -> allow incoming only from sources listed in whitelist >> "none" -> disallow all incoming >> >> instead of "none," "deny" and "allow"? >> >> Or, better yet, why not replace "policy"/"apply_to" with "blacklist"/ >> "whitelist"? >> > > This is bikeshed'ing...and you've forgotten grey...or it gray and not grey? > > IMHO, I prefer to see relevant policy words that are in common use > elsewhere > in the industry for control words. Nowhere else in [Open]Solaris do we > have > the concept of "white" and "black" (that I'm aware of), so it would seem > extremely inappropriate to introduce that new concept here. > > >>> apply_to >>> A multi-value property listing network entities to enforce the >>> chosen policy mode. Entities listed in apply_to property will be >>> denied >>> if policy is "deny" and allowed if policy is "allow". The syntax for >>> possible values are: >>> >>> host: host:IP "host:192.168.84.14" >>> subnet: network:IP/netmask "network:129.168.1.5/24" >>> interface: if:interface_name "if:e1000g0" >>> >> >> Why do we need 'host'/'subnet' when we have CIDR notation? And if >> there's no hostnames then we don't need 'if' for interface names either. >> > > I'd rather it be possible to be explicit in nature about the nature of > what an object > is, when it comes to security, so that you are in a better position to > try and catch > simple mistakes. > > For example, if someone put in "host:192.168.84.14/24", because they did a > copy paste from somewhere else, what does that mean? Isn't it better to say > "ok, they wanted a host, gave me a CIDR so I'll give them an error" than to > just accept it and try to guess that the user wanted a network instead > of a host, > possibly creating a security exposure? >
We chose to use URIs here to avoid potential parsing issues and have an extensible configuration store. For example, to add support for ippool and IPv6, we probably can have ippool: ippool6: host6: network6: > >>> exceptions >>> >>> A multi-value property listing network entities to be excluded >>> from the >>> "apply_to" list. For example, when deny policy is applied to a >>> subnet, >>> exceptions can be made to some hosts in that subnet by specifying >>> them >>> in the "exceptions" property. This property has the same value >>> syntax >>> as "apply_to" property. >>> >> >> Why not just have '!' notation in apply_to instead of this exceptions >> property? >> > > Thinking of it in terms of usability, it would seem better (to me), to > have a list of > things you allow and a list of exceptions to that list, rather than a > combined list > that you need to sift through to work out what's what. > I actually think "!" notation is pretty neat but have similar usability concern. -tony
