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? >> 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? >> 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? Darren
