Steve Langasek wrote:
On Fri, Nov 25, 2005 at 12:19:58PM +0100, Johannes Wiedersich wrote:
On Fri, Nov 25, 2005 at 10:26:43AM +0100, Johannes Wiedersich wrote:
Subject: firestarter breaks nis
Package: firestarter
Version: 1.0.3-1.1
Severity: critical
Justification: breaks unrelated software
Firestarter is a firewalling tool; nis is a network application. These are
not unrelated software.
Given that you can break *any* network application by means of a
misconfigured firewall, and given that your stated solution for this bug
was
to make a change to your *nis* config, not to your firestarter config, I
don't see any reason to treat this as a grave bug, either.
This is a workaround, not a solution.
In fact installation/start of firestarter breaks an otherwise working
configuration in nis. The really annoying part of the problem is that no
hints of what gets wrong is displayed by firestarter; no events etc.
The firewall is set up correctly, allowing all connections to the
desired private network. I would prefer to change the configuration via
firestarter, not nis. How should one set up firestarter to allow
broadcassting to 192.168.0.255 for a nis server apart from allowing all
connections to and from 192.168.0.0/24?
Presumably, allowing outbound broadcast packets to 192.168.0.255/32 on an
appropriate destination port and incoming udp packets from 192.168.0.0/24
on an appropriate source port would be correct?
As far as I know, YES.
I've never personally used firestarter, so I don't know whether it's
reasonable to expect all blocked inbound or outbound packets to generate
logging events. The package description says there's a "real-time hit
monitor" that shows attackers probing your machine; if it's the outbound
traffic that's being blocked, then that doesn't qualify as "an attacker
probing the machine", so *I* don't have any expectation that such traffic
would generate log events. You may have a different expectation; if so, it
would help me to know why your expectation is different from mine.
To sum it up: the firewall is configured correctly,
This is patently false. If the firewall were configured correctly for your
application, the application would not fail. If you mean that the firewall
*cannot* be configured correctly, that would be a more serious bug, but I
haven't gathered that this is actually what you're saying.
Let's try to word it precisely: Firestarter is a front end gui
configuration tool for some scripts that set up the firewall. If you use
this front end to configure the firewall and set it up to allow *all*
outgoing connections plus all incoming connections on 192.168.0.0/24,
then nis on that subnet is broken. (Not 100% sure, but presumably either
the broadcast or its reply are blocked.) Therefore it appears indeed
that it is impossible to configure the firewall by firestarter in a way
that the default settings of nis work (ie. without the workaund).
Maybe the correct wording would be: The way the scripts set up the
firewall are apparently different from what is selected from the gui.
shows no logs
which could warrant a release-critical severity, depending on what the
normal logging policy is for firestarter.
According to the documentation found at
http://www.fs-security.com/docs/tutorial.php
`On the events page you will see all connections that the firewall has
terminated since you started the program.'
This is evidently not the case as far as nis is concerned. This is
precisely the reason, why it took me so much effort to find out the
reason for the unexpected failure of nis starting correctly.
This is not a definition, this is only an explanation of one type of package
relationship that *disqualifies* a bug for being of critical severity. :)
Software may be "related" in other ways than through dependency fields --
like I said, a firewall and a network application are another case of
related packages.
I see this now, sorry.
Of course I would like to help you in tracking down the problem; so if
you need more information or configuration or log files, please just let
me know.
Thanks,
Johannes
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
