"Workstation" Product defaults to wide-open firewall

Zbigniew Jędrzejewski-Szmek zbyszek at in.waw.pl
Wed Dec 10 04:40:15 UTC 2014


On Tue, Dec 09, 2014 at 12:09:23PM -0700, Pete Travis wrote:
> On Dec 9, 2014 12:06 PM, "Chuck Anderson" <cra at wpi.edu> wrote:
> >
> > On Tue, Dec 09, 2014 at 11:52:01AM -0700, Pete Travis wrote:
> > > On Dec 9, 2014 11:33 AM, "Chuck Anderson" <cra at wpi.edu> wrote:
> > > I should have said "ask firewalld for a port to be opened" - sorry, I
> > > thought that would come from the context.
> > >
> > > Are you saying bind() should be talking to firewalld, via some approval
> > > agent?  how do we make that happen?
> >
> > My point was that a firewall is superfluous if a program can just ask
> > firewalld to poke a hole in the firewall for it automatically, because
> > a program can already ask the system to open a listening port for it
> > using bind(2) (and listen(2) and accept(2)) when no firewall is
> > present.
> >
> > It means that in a world where automatic-hole-punching exists, the
> > only use of a firewall on the host is maybe to limit the SCOPE of such
> > communication, not whether such communication is allowed at all or
> > not.  This is where firewall zones come in.
> 
> Okay, one more thing on the ideal requirements list:  firewalld must not
> blindly approve all requests, there must be some approval mechanism.  What
> would that look like?
I think that this is the kind of question that we should be asking.

Let's say that we had a dbus daemon which would "listen" for new ports being
opened, and would broadcast a message specifying the PID, user, executable
name, whenever a port was opened. It should also listen to ports being
closed.

A second daemon would listen to those events, compare them against a
database of already seen ports, and if it is an unseen application, it might
pop up a notification, "/bin/xxx tried to open a port to listen, but
current firewalld policy blocks this", and the user could click on the
notification to modify firewalld configuration, and possibly allow
/bin/xxx to open a port by default.

I think this shouldn't be too hard to write, if we had an efficent way
to wait for bind/shutdown calls. If /proc/net/{tcp,tcp6,udp,...} files were
pollable, this would be easy, even if not very efficient. Is there some
other mechanism that the kernel provides to do that?

Zbyszek


More information about the devel mailing list