Anurag S. Maskey wrote: > nwam-dev and nwam-discuss for feedback/opinions from the nwam team ... > > I think ipfilter and firewall refer to the same thing, so I used > ipfilter. please correct me if I am wrong ... Not quite. IPFilter provides the underlying technology whereas firewall provides an abstraction that simplify configuration IPFilter for Solaris.
>>> >>>> tony-09 create/revert_legacy_loc doesn't correctly save/restore >>>> custom file. User may have a policy other than custom but has a >>>> valid configuration file. The current code doesn't correctly save >>>> the configuration file if policy is something other than 'custom' >>>> thus can't properly restore it. >>> If the policy is not custom, then when creating the Legacy location >>> we save the value of the policy. In the ipfilter-config-file >>> property, this value is preceded by a '/' since the property requres >>> that the file be absolute. For any location, the user specifies the >>> config file and net-loc only changes the policy (to "custom") and >>> the custom_policy_file. When the Legacy location is installed (on >>> disabling nwam), the policy is set back to what is was. If the >>> policy was not custom, then the '/' is removed from the >>> ipfilter-config-file and set to policy. >>> >> >> But the config file is lost when revert back to legacy. The problem >> is in how we are using a single property to store two different >> possible values. The restored configuration can't be complete. >> >> If you always save the config file, that is storing the policy >> separately from the config file, then you can always correctly revert >> to a prior legacy configuration. I'm after adding an extra location >> property so that we always capture the entire firewall setting so we >> can correctly revert back. Does it make sense? > When you say "entire firewall setting", what are the properties that > we are looking at? I hacked our ipfilter-config-file property to work > with the new ipfilter changes. If the policy is custom, the custom > file is copied to /etc/nwam/loc/Legacy and pointer to the original > location of the custom file is stored in ipfilter-config-file. If the > policy is not custom, then the policy value is stored in > ipfilter-config-file. > > When reverting to Legacy loc, the opposite of the above is done. > The reversion is not complete. We have configuration with n properties, you save and restore only one property. If user modify one of the non-saved properties, the reversion will not be complete since we only restore one property. With the current implementation, the ONLY supported firewall configuration is the 'custom' policy where a rule file is specified since we save and restore this property. If we decide this is the case for Phase I, I'd expect a flag day to spell out the limitation. A complete firewall setting would be the set of firewall properties in network/ipfilter and all firewall supporting services (e.g. services with firewall_config property groups). A better approach to this solution would have been collecting all these properties using svcprop or svccfg and generates a SMF profile for the Legacy location that can be applied when Legacy is activated. The location thus only stores the reference to this SMF profile rather than duplicating property values. This solution allows user to configure then save a complete firewall configuration rather than limited to only the 'custom' policy. >> >>> If Host-based firewall provided with an export-like function, then >>> it will be much easier for nwam. We could simply "export" the >>> ipfilter configuration and save that configuration file in the >>> ipfilter-config-file property. When installing the Legacy location, >>> nwam could simply import the exported file and the configuration >>> would be back to what is was. Is there something like this in the >>> works? >>> >> >> There isn't a use case for exporting just firewall settings. Your >> work is essentially exporting the firewall settings. > > ipfilter changed since nwam was first designed. then, it was just a > config file, now it is more complicated from our point of view. Isn't > our work a use case for having an export? This would make nwam's life > so much easier and avoid the discussions below. > My point here is that firewall itself has no need for such functionality. I suppose an RFE can be filed against firewall to request the 'export' feature. But that wouldn't be any more work than a shell script that perform the work I describe earlier to parse the properties values from services and generate a profile file. > To get full ipfilter functionality from nwam locations, all the > ipfilter properties have to be duplicated in nwam locations and users > will have to change the nwam location properties (and not the ipfilter > smf properties) to setup ipfilter. If changes are made to ipfilter > smf properties, these are lost (unless we have a "save to current > location" option in ipfilter). > > BTW, what ipfilter properties should nwam locations copy over to get > the full functionality? > > Do you have thoughts on solution for this? Duplicating the ipfilter > properties is one option, but two places of having the ipfilter > configuration confuses users. > See above section. >>> tony-15 I have another concern regarding location-based IPfilter >>> configuration. The current implementation requires users to supply a >>> customized ipf rules for every location if they want to configure >>> IPfilter. This essentially undo the functionality of Host-based >>> firewall which simplified IPfilter configuration. We ought to allow >>> users to configure location with the option of using their existing >>> IPFilter configuration, in fact, I'd argued that option should be >>> the default. >> >>> Changes made to the system when a particular NCP or location is >>> active is not persistent and it lost when the system is rebooted, >>> NWAM restarted or location changed. For example, if a user plumbs >>> an interface with ifconfig, then it is not plumbed the next time the >>> system is rebooted. As for the Host-based firewall, the changes are >>> also temporary, in effect until the location is changed. >> >> But user can make changes to location specific configuration and have >> those changes take effect whenever the location is activated. Guess >> what I'm after is how much work would be required for user to set up >> firewall for each location. >> >> With the current NWAM implementation, it's only possible to have a >> temporary configuration and have only the 'custom' policy. This is >> extremely limited and a huge regression in term of functionality. >> Have you consider a Location option to not affect the system's >> firewall configuration so that user's existing configuration can run >> regardless of location? I'd even suggest this option to the default >> for newly created locations until we can fully configure firewall for >> each location. > If there is no ipfilter property, then the machine is unprotected > after a location is activated and the user is activating the ipfilter > rules. >> >>> By the way, how do users access the new firewall configuration? Is >>> there a GUI or CLI? One way I see using it would be to have an >>> option to save the configured IPFilter settings (using an >>> export-like function) and then setting the active location's >>> ipfilter-config-file to point to that. If there's a GUI, then a >>> button to "save config to current location" would achieve this. >>> >> >> Firewall configuration can be accessed through normal svccfg/svcprop >> commands or the upcoming Firewall panel in Visual Panels project. >> However, Firewall settings is more complex than just rules in a >> single file. The complete firewall settings include many property >> values in network/ipfilter and all services with a 'firewall_config' >> property group. The long term solution, similar to your suggestion, >> is to some how export the complete firewall configuration to a >> location and apply the configuration when the location is activated. >> We were all hoping for Enhanced Profiles to make it possible but >> we'll need to do with what's available to us. >> >> I have an upgrade question. If I have a firewall configuration >> running on my system (custom/non-custom policy), what would happen >> upon upgrading to a NWAM release? > currently, the ipfilter configuration is not upgraded. The Automatic > location has no ipfilter rules. So firewalled machines become unprotected after upgrading to an NWAM release. What's the rationale behind this behavior? -tony
