On 08/21/08 14:06, Tony Nguyen wrote: > 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?
I think that will work a treat. >>>> 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? Yes. >>>> 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. Can it just be placed in the running profile, rather than current? Or does updating the running one still count as a configuration change? Darren
