On Sat, Sep 01, 2007 at 22:30:12 -0500,
Arthur Pemberton <pemboa(a)gmail.com> wrote:
On 9/1/07, Bruno Wolff III <bruno(a)wolff.to> wrote:
> On Sat, Sep 01, 2007 at 12:05:00 -0500,
> Arthur Pemberton <pemboa(a)gmail.com> wrote:
> > On 9/1/07, Bruno Wolff III <bruno(a)wolff.to> wrote:
> > > On Sat, Sep 01, 2007 at 14:07:17 +0200,
> > > Benny Amorsen <benny+usenet(a)amorsen.dk> wrote:
> > > >
> > > > Administrators sometimes want to limit which traffic can reach
> > > > applications, and perhaps limit the risk when accidentally starting
> > > > applications. Automating firewall setup makes that useless.
> > >
> > > That is probably the main reason. And having apps undo restrictions seems
> > > like a really really bad idea.
> >
> > So being able to easily disable this wouldn't be enough?
>
> I don't think so. I thought making it easy for people to shoot themselves
> in the foot was the Microsoft way.
I do not see a parallel here, please explain
Microsoft makes things convenient even when what is being made convenient is
a dumb idea from a security perspective. Think email clients that run programs
to view attachments of type other than plain/text without even asking.
> > > Plus I have no confidence that apps can properly
rewrite iptables rules
> > > correctly. iptables setups can have complications which will make it
> > > hard to change them. I have used subroutines for checking reserved ip
> > > ranges and have had services configured to only be available to local
> > > ip addresses or specific interfaces.
> >
> > This is something that would/should work only if you're using
> > system-config-firewall
>
> And how is the code going to determine that?
By having the init script ask s-c-firewall to open the port as has
been suggested.
Does the init script know that s-c-firewall is what wrote the current set
of firewall rules? If so, I'd be curious to know how it does. Because if
s-c-firewall didn't write the rules, it is possible that the changes it makes
will cause problems.