Darren Reed wrote: > On 08/21/08 01:17, Tony Nguyen wrote: >> Hi Darren, >> >> Thanks for the valuable comments. See my responses inline. >> -tony >> >> Darren Reed wrote: >> ... >> ... >>> The tree for allow/deny with exceptions is only 2 deep. >>> I'm not sure this is enough and needs at least another layer. >>> Or maybe I'm not putting the pieces together right... >>> For example, if I set my global policy to "deny_all_except", >>> I might then specify 129.146/16 in the default allow "except" >>> list but may wish to put holes in that for, for example, >>> blocking traffic from Tony's desktop. >> A really neat scenario. Essentially, we want to block all but allow >> from 129.146/16, except specific host(s) on that 129.146/16 network. >> >> In this case, we would configure use both the Global Default and >> Global Override layers to get the desired behavior. >> >> - Global Default policy is set to "deny_all_except" and specifiy >> 129.146/16 in the "deny_except_list" >> - Global Override policy is set to "allow_all_except" and specify >> unwanted hosts on 129.146/16 network in the "allow_except_list" >> >> Having another layer for each firewall configuration as you suggested >> is a good option but I'm concerned about the more complex user model, >> deny all but allow some, except a few. The current implementation >> while not flawless(can't apply the above scenario to a service), is a >> simpler model and would satisfy most use cases, in my opinion. > > Hmm... can the 3rd layer be a union of the global over ride policy > (which is already in the design) and a local over ride policy?
It certainly can though not necessarily a union. The Global Override is mostly used as a blacklist, hosts that we deny access. However, we can have implement the override layer for each service by having deny_override and allow_override lists to override the except list. What do you think? > > >>> If a network service is in maintenance mode, for one >>> reason or another, what impact does that have on the >>> firewall rules? >>> >> Currently, active rules for a service aren't affected if the service >> goes into maintenance mode. Essentially, a service's firewall >> shouldn't be affected by the service's operating mode(maintenance or >> degraded). The other approach is to remove the active rules but that >> has a potential issue where a service may have been deleted and its >> ipf_method is now missing. > > So if you have a service that has multiple daemons, one starts but the > other doesn't, > causing the service to enter maintenance mode, if both listen on TCP > sockets, what > would you expect the outcome to be? And what do you think people will > desire? > In such case, the service's firewall rules should still be active. A service's firewall is configured to protect the service and should not cause any regression to the service's functionality. Thus, a service operating in degraded state should still be protected by its firewall policy. Is that reasonable? > >>> For RPC services, given you are querying rpcbind to >>> access port number information, is there any merit in >>> also storing that retrieved information back in the >>> running profile of the RPC service in a volatile field? >>> (This is possibly outside the scope of this project.) >>> >> I'm not sure I understand the benefit of caching port information >> given that some RPC services have dynamic ports. Would you clarify? > > So that you can use svccfg, as well as rpcinfo, to find out what > port number the service is running on. Given that the port number > is a property of most other services, it seems ... to fit? > Ah. One potential implementation issue, a change to a service's configuration requires a service refresh. If an RPC services gets a different port on each service refresh and saving the new port requires another refresh, we'll get into a loop. Thanks, -tony
