Darren Reed wrote: > 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.
Great. > > >>>>> 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? > The short answer is yes. The current snapshot is the same as the running snapshot. The primary issue is a service refresh action triggers both a snapshot update and execution of the refresh method since we want the service to always run with the active/latest configuration. Thanks, -tony
