Renee Danson wrote:
> 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.
OK
>
>>> 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.
Yes, they can. These methods can simply create some rules and request
ipfilter to make them active, something like
echo "rules" | ipf -f -
>
> However, this is one of the questions that Dave and Bill are chasing, so
> I'll defer to that part of the thread.
>
> -renee
>
Ok, we'll pick it up there.
Thanks,
tony
