Hi Renee, Thanks for the comments. My responses inline.
-tony Renee Danson wrote: > Hi Tony, > > Apologies for the late reply. > > On Mon, Aug 18, 2008 at 01:06:20PM -0700, Tony Nguyen wrote: >> Hi Darren and all, >> >> As part of the Visual Panels project, >> >> http://opensolaris.org/os/project/vpanels >> >> we're proposing a generic firewall framework for Solaris. The framework >> utilizes IPfilter to provide a simple mechanism to configure a firewall >> on Solaris systems. > > Overall, I think this is a nice design that should be able to integrate > well with nwam profiles. I'd need to look more closely at some of the > implementation details in order to figure out how exactly we need to do > this, though. > > Some of the specific things I would be interested in are: > > * How is the list of network services discovered? Is it hard-coded in > svc.ipfd? Or is it detected by walking all smf services and looking > or the firewall_config property group? If it's the latter, how will > svc.ipfd learn about newly added services (or newly added > firewall_config property groups for existing services)? When we activate the firewall, we do go through all services and generate IPfilter rules for those with firewall configuration, existence of firewall_{config | context} pg. svc.ipfd is notified when a service is enabled, disabled, refresh, restarted at which it looks for firewall configuration to determine whether to activate that service's firewall. New services or services with newly added firewall configuration will be recognized when enabled or refreshed. > > * What's the mechanism by which the gui front-end writes out config > data? Would it be possible to have it write out data to an alternate > location, rather than directly to service properties? I'm thinking it > would be nice for nwam to simply invoke that gui and have it write out > the data somewhere other than the current repository, so that nwam can > apply the changes when it applies the applicable profile. This problem > will likely be solved by enhanced profiles, when nwam profiles are > instances of enhanced profiles; but we might need an interim solution. > As we've discussed offline, the intended gui doesn't allow changes to an alternative repository. We can potentially provide a way to capture active firewall settings to be applied later or on another system. However, what you request should really be solution based what Enhanced Profiles provides. > I also had some (perhaps naive) concerns about security in the design. > I'm not a security expert, but the note about the service-provided > ipf_method scripts being exec'ed as root set off alarm bells. What's > to stop someone from creating a rogue service whose ipf_method script > creates rules that open up vulnerabilities, or that stomp on rules of > other services? Or (perhaps more likely) what about a service with a > flawed script that accidentally causes such problems? > I'm sure folks will correct me. It's essentially network/ipfilter that is running this provided ipf_method, a service delivered script. A service developer/vendor who delivers a flawed script can do the same in the service's start or refresh method.
