On 10/28/08 01:25, Tony Nguyen wrote: > Renee Danson wrote: > >> Apologies for the delayed response... >> >> Thanks for reporting on our conversation, Tony; it's a good summary. >> >> On Wed, Oct 22, 2008 at 11:41:46AM -0700, Tony Nguyen wrote: >> >> >>> Tony Nguyen wrote: >>> >>> >>>> I had a conversation with Renee. As far as I know, a NWAM location has >>>> an associated IPfilter policy that would be applied when the location is >>>> activated. >>>> >>>> The long term solution should store a location's associated >>>> configuration in a SMF profile. In this model, NWAM can consume >>>> host-based firewall by delivering a location's IPfilter policy as a set >>>> of firewall settings for all network services. Host-based firewall >>>> simply obtains the firewall policies from the active profile and >>>> generate the corresponding rules. >>>> >>>> The short term solution currently delivers the IPfilter configuration, a >>>> set of rules in files to be loaded when a location is activated. The >>>> team agreed to use the host-based firewall custom mode to activate >>>> location specific IPfilter rules, setting Global policy to custom and >>>> specifying the rules file. The other alternative is to >>>> translate/generate firewall settings for all services when a location is >>>> chosen. This would better a better integration with host-based firewall >>>> but requiring a secondary storage for different locations' policies. >>>> >>>> >>>> >>> A follow up thought. Avoid using the host-based firewall custom mode is >>> preferred since that would prevent user from actually configure >>> host-based firewall. I don't know how location IPfilter configuration is >>> generated but an idea is to store the configuration as a set of >>> services' firewall policy. >>> >>> >> I'd been thinking along these lines, as well. When I first looked at >> your design, I was thinking about tighter integration, where nwam was >> able to take advantage of the UI you're creating, as well as the under- >> the-hood configuration details; and as we discussed, the challenge there >> is having the config data stored somewhere other than in the service >> properties, so that it can be applied when NWAM decides to activate the >> location, rather than immediately. >> >> But even if we can't initially use your UI, we can present the user >> with equivalent options through the nwam UI, and then apply appropriate >> properties at the right time so that the host-based firewall can consume >> them and generate the appropriate ipfilter policy. >> >> Is that what you had in mind? >> >> > Hi Renee, > > Yes, applying the appropriate set of property values for the active > location is probably the best workaround until Enhanced Profiles is > available. W.r.t the UI, ideally, NWAM UI would be integrated into > Visual Panels and the Firewall UI is enhanced to support NWAM locations. > We all know having duplicate functionality isn't appropriate but it's > probably too late to undo the UI decision. >
At the moment the NWAM locations discussion seems to be more of less restricted to enforcing network access policies based on which network one connects to. Stepping beyond that, is it possible for NWAM locations to also apply a SMF template that results in services being enabled/disabled as appropriate? So, for example, if I connect to SWAN then I probably want NIS/LDAP to be enabled but when I connect at home, I want them disabled. This can effectively be mimic'd through the correct application of packet filters but a more thorough application of the security policy should result in the service being disabled. Does this fall within the balliwack of the work being done by those in the SMF group or NWAM? Darren -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/security-discuss/attachments/20081028/18c46393/attachment.html>
