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. 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
