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? -renee > Something like > > <service name="network/ssh"> > <policy value="use_global"/> > <apply_to value="host:1.2.3.4 host:5.4.3.2" /> > <exceptions value="" >/ > </service> > .... > > The firewall policies can then be applied to SMF services when a > location is activated. I'm not sure if this would work for NWAM but it > would allow users have both NWAM and still be able to properly configure > host-based firewall. > > -tony > > > > >Darren Reed wrote: > >>On 20/10/08 08:05 PM, Darren Reed wrote: > >>>On 20/10/08 11:44 AM, Renee Danson wrote: > >>>>[security-discuss readers: if you're not familiar with nwam, please see > >>>>http://www.opensolaris.org/os/project/nwam/p1spec] > >>>> > >>>>IP Filter and IPsec policy rules are part of NWAM locations; this > >>>>allows you > >>>>to configure different security policy, depending on where you're > >>>>connected. > >>>> > >>>How will NWAM's locations play with Visual Panels' host based firewall > >>>configuration? > >>>(PSARC/2008/580) > >>Given no comments thus far regarding this, let me highlight > >>my concerns. > >> > >>Most of PSARC/2008/580 has been accepted with "Commited" > >>interfaces for the various SMF changes. Whilst this is a > >>fair call without NWAM's locations, I'm concerned that the > >>interfaces it introduces will either be redundant or not > >>functional with NWAM locations. > >> > >>For example, if I define two NWAM locations, home and office, > >>it is reasonable to expect that the SMF entries for, say, > >>sshd, are significantly different with respect to what networks > >>are and are not allowed and that we somehow make this work with > >>PSARC/2008/580. > >> > >>At present PSARC/2008/580 is still not putback, so if there > >>is a well defined need, we can amend the case - but time > >>isn't on our side if the host base firewall project is going > >>to make it into the next OpenSolaris release. > >> > >>My main worry is that PSARC/2008/580 will put us in a corner > >>that is not at all compatible with NWAM locations. At the > >>very worst, if we can't get discussion going on this soon, > >>NWAM locations, in its current guise, could be sent back to > >>the drawing board from PSARC because it fails to interoperate > >>with the host based firewalls. The usual rule in PSARC is > >>that whoever is first gets to make the rules for those that > >>come later. If we do nothing, this could get unpleasant for > >>a number of people - especially users. > >> > >>It would be of benefit if the NWAM project could at least put > >>a stake in the ground for this work and create an empty PSARC > >>case so that we have some ability to reference that project. > >>I'm not going to ask that it decides whether it should be a > >>fast track or project, just that we need something. If the > >>NWAM locations project isn't going to be a fast track then > >>I'd like to suggest that the team puts something together, > >>post-haste, for an inception review or pre-inception review > >>so that we can formally address these architectural matters. > >> > >>Remember: ARC early, ARC often. > >> > >>Thanks, > >>Darren > >> > >>------------------------------------------------------------------------ > >> > >>_______________________________________________ > >>smf-discuss mailing list > >>smf-discuss at opensolaris.org > >> > > > >_______________________________________________ > >smf-discuss mailing list > >smf-discuss at opensolaris.org >
