|
Replies:
2
-
Last Post:
Sep 21, 2009 11:51 AM
by: anurag_m
|
|
|
|
|
|
|
Re: [nwam-discuss] [Fwd: SMF and IPFilter related code review
comments: paul-01...05 and tony-01...15]
Posted:
Sep 15, 2009 5:51 AM
|
|
|
|
|
Posts:
110
From:
US
Registered:
4/16/08
|
|
|
|
Re: [nwam-discuss] [Fwd: SMF and IPFilter related code review
comments: paul-01...05 and tony-01...15]
Posted:
Sep 15, 2009 5:51 AM
in response to: Guest
|
|
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 ...
>>
>>> 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.
>
>> 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.
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.
>> 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.
Anurag
_______________________________________________
nwam-discuss mailing list
nwam-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/nwam-discuss
|
|
|
|
|
Posts:
110
From:
US
Registered:
4/16/08
|
|
|
|
Re: [nwam-discuss] [Fwd: SMF and IPFilter related code review
comments: paul-01...05 and tony-01...15]
Posted:
Sep 21, 2009 11:51 AM
in response to: Guest
|
|
Tony,
I apologize for the delay in getting these responses back to you.
I'll address the Firewall issues separately in a different email. Below
the remaining comments are addressed and I've updated the webrev.
Tony Nguyen wrote:
>> The webrev for these changes against the current nwam gate is at
>>
>> http://zhadum.east/export/ws/am223141/temp/nwam1-work/nwam1-smf-review-webrev/
>>
>> The original webrev that went out for code review is at
>> http://cr.opensolaris.org/~mph/nwam1_cr/
> net-loc: start_svc() always does a refresh. There's no harm but it
> causes the system to do unnecessary work. I'd recommend remove 'svcadm
> refresh' from start_svc() and call it explicitly for the necessary
> cases. However, I don't have strong objection if you keep it as it is.
I've added refresh_svc() and call it explicitly before start_svc() for
cases when smf properties have been modified.
>> Yes. If nwam is enabled, the net-svc script exits. The net-loc
>> script sets up the remaining configuration depending on the location
>> that's being activated. If nwam is not enabled, the net-svc script
>> proceeds as before. Some tasks from network/service was spun-off
>> into network/netmask and network/ipqos services.
> tony-04 usr/src/cmd/svc/milestone/network-service.xml - No update?
> However, are dependencies (e.g. NIS dependencies) and comments still
> accurate if the service is now only responsible for updating DNS
> information?
> ok
>
> network-service.xml had no changes and shouldn't be in the original
> webrev.
Hmm ... strangely I had never made changes to network-service.xml but
updated the keywords and copyright year. I've reverted them to what it
was before so that no diff in generated against ON.
>> The history seems to have lost the comment that went with this
>> particular change. I think Renee has the answers. Will chat with
>> her early next week.
> tony-05 network-physical.xml'41,87 - It's not clear from the
> design spec that there will be additional network/physical instances.
> Clarification please?
> Any news?
Renee's response:
> Okay, I took a look at the comments in question, and now I remember
> what this was about.
>
> The original thinking was that we would represent the various
> nwam objects as smf service instances, possibly instances of
> the network/physical service. So those are the instances that
> this comment is talking about.
>
> I think that even if we end up representing objects as service
> instances in some way, they're unlikely to be instances of the
> network/physical service; even if they are, we can update the
> comments/dependency assignment as needed when that happens!
>
> So I think the right thing to do here is to create the dependency
> at the service level, and simply remove the comment--making it
> like what's in network-physical.xml in ON currently.
>
Thus, I have moved the loopback dependency to the service level, rather
than the instance level.
>>> tony-11 net-loc'502 - refresh_ipf also needs to be set here to
>>> make the changes effective.
>> Rather than setting refresh_ipf, I've explicitly refreshed ipfilter.
>> That's because if refresh_ipf is set, ipfilter service remains online
>> (even though the policy is "none"). Not setting the refresh_ipf
>> changes the ipfilter service to disabled. This makes it less
>> confusing for users to see if ipfilter is on by simplying doing "svcs
>> ipfilter".
> How about the other cases of setting refresh_ipf?
When refresh_ipf is set in the other cases, ipfilter gets refreshed and
(re)started. refresh_ipf is set only when a config file is specified
and smf property modified.
The reason I don't want to set refresh_ipf when changing the
firewall_config_default/policy to "none" is because if I set
refresh_ipf, then ipfilter gets refreshed and enabled. Even though
there is no ipfilter policy in this case, checking the service shows it
as "online" which can be misleading.
_______________________________________________
nwam-discuss mailing list
nwam-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/nwam-discuss
|
|
|
|
|
