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