On Wed, Aug 27, 2008 at 05:02:14PM -0700, Tony Nguyen wrote:
>
> > * 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.
Thanks, that's what I was looking for.
> > * 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 think we might be able to work something out that's adaptable and may
be useful before enhanced profiles are available. But we can work on
that moving forward, I don't think it's an immediate requirement.
> > 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.
But the service's start or refresh method wouldn't have the ability to
load rules into ipfilter, which is what your framework will do on its
behalf.
However, this is one of the questions that Dave and Bill are chasing, so
I'll defer to that part of the thread.
-renee
