Solaris host-based firewall [PSARC/2008/580 FastTrack]

[Tony Nguyen]

Andrew Gabriel wrote:
> Tony Nguyen wrote:
>> Andrew Gabriel wrote:
>>> In the ipf(1M) manpage, you have removed the ipf and ipnat command 
>>> examples. This is incorrect -- these are still used and required for 
>>> current method of operation. You perhaps just need to add a comment 
>>> that these wouldn't be used if using the SMF framework to 
>>> automatically build firewall rules. You have also effectively removed 
>>> the instructions for changing filter rules without either rebooting 
>>> or disabling IPfilter. It is an important feature of IPfilter that it 
>>> allows rules to be changed dynamically without disabling it or 
>>> rebooting the system, and this needs to remain on the manpage. 
>>> ipf(1M) is a committed interface and a key part of the access to 
>>> important features of IPfilter.
>>
>> Actually, I removed that section for correctness and consistency, 
>> independently of firewall. IPfilter is an SMF service and should 
>> really be managed via SMF commands, in this case:
>>
>> "svcadm restart ipfilter" for "ipf -E"
>> "svcadm refresh ipfilter" for "ipf -f ipf.conf; ipf -f nat.conf"
>>
>> The argument here is choices for the customer but it can also be a 
>> little confusing to have the man page shows starting network/ipfilter 
>> with SMF command and restart/refresh actions are done with non-SMF 
>> commands.  Does it make sense?
> 
> No. The manpage is for the ipf(1M) command, and it makes no sense to 
> remove the example usage of the very command the manpage is describing. 
> I think that an "advanced user" is likely to start ipfilter with SMF, 
> and manipulate it dynamically with the ipf(1M) and/or ipnat(1M) commands 
> thereafter (at least, I do).

I see.

> 
> It would make sense to add the SMF command example too, and a 
> description of when you should use one or the other. The ipf(1M) and 
> ipnat(1M) commands are much more fully featured than you can access via 
> SMF, so SMF isn't a replacement for them, except in the most simple of 
> cases. (Strangely, the ipfilter SMF method script contains other useful 
> functions such as reipf and reipnat, but SMF has no mechanism for 
> calling them.)

I agree that ipf command features can't be replaced by the current SMF. 
In this specific example, the three ipf commands can be replaced by a 
single svcadm restart command so it was really tempting :)

> Alternatively, you could take the view that the ipf(1M) and ipnat(1M) 
> (and ippool(1M)?) manpages are only appropriate for "advanced users" 
> anyway. You could move all the detailed ipfilter SMF instructions to the 
> ipfilter(5) manpage, and then include only an appropriate cross 
> reference from each of the "advanced user" command manpages. I think 
> that makes most sense.

How about leaving the example intact and add the boilerplate phrase to 
ipfilter(5) which says ipfilter is managed by SMF under network/ipfilter 
and administrative actions should be done via svcadm?

> 
> However, my main concern was that you aren't proposing to change or 
> disable or decommit/obsolete the direct use of ipf(1M) and ipnat(1M) 
> commands, which it looks like you aren't, so that's OK.
> 

Correct, we are not obsoleting direct use of ipf.

Much appreciated,
tony