Daniel, can you explain your reasoning a little more, please?
I started to look at fixing this, and have some questions...
Firstly: In Intrepid (firehol 1.256-3) the debian/postinst script does:
update-rc.d firehol start 41 S . start 36 0 6 . > /dev/null
I initially suspected a typo: the second "start" should be "stop". Am I
correct? Why start a firewall when rebooting or shutting down? Or, is
this a "clever" way to ensure the firewall is only stopped very late in
the set of scripts run at shutdown/reboot, after all other applications
are stopped, since Debian Policy Manual 9.3.1 says:
The two runlevels 0 (halt) and 6 (reboot) are slightly different. In these runlevels,
the links with an S prefix are still called after those with a K prefix, but they too
are called with the single argument stop.
A comment in the postinst script describing the author's intent would
perhaps have been helpful, given how complex the update-rc.d option
syntax is.
Secondly: If this postinst script is patched to say something more conventional, based on
https://wiki.ubuntu.com/Teardown, such as
update-rc.d firehol start 46 2345 . stop 54 1 . > /dev/null
is that sufficient to solve this bug? If busy-wait is required, what is
the firehol init script supposed to wait for?
Thirdly: I fear that delaying firewall setup until runlevels 2 to 5 may
introduce a serious security issue. Does it really make sense for a
firewall to wait until remote network filesystems are mounted before it
is started? Doesn't that introduce a potentially lengthy window of
opportunity (between network startup and completing of remote filesystem
mounts) during which time networking will be active, but the machine
will be unprotected by the packet filter?
In this case, perhaps the real solution would be for NFS/NIS client
machines to use a firehol script (on a local fileystem!) that allows the
appropriate NFS/NIS traffic to flow, and then to start firehol *before*
any attempts to do remote filesystem mounts are made? So the current
approach of starting it in /etc/rcS.d/ is then correct?
I think that (other than the start/stop possible typo issue mentioned
above) this reported bug may in fact be a policy question -- the firehol
developers went for security, starting the packet filtering early; the
bug reporter apparently wants a shared firehol policy file, and so wants
the firewall enabled later, only after NFS/NIS are up and running.
Which approach is "correct" perhaps depends on your perspective (and
your degree of network security paranoia)?
Since anyone installing a firewall on their machine is being at least
somewhat security-conscious, "secure-by-default" sounds to me like the
better way to go here, leaving those who want to reduce security to
allow the convenience of an NFS-shared firehol script to make that
choice for themselves (using any of several runlevel editors) and be
very ware of the risk they are taking.
Jonathan
--
The rcS.d script for firehol starts before NFS and NIS
https://bugs.launchpad.net/bugs/28906
You received this bug notification because you are a member of MOTU,
which is a bug assignee.