Firewall blocking desktop features

[Simo Sorce]

On Wed, 2013-09-11 at 23:18 +0200, Mateusz Marzantowicz wrote:
> On 11.09.2013 17:24, Daniel J Walsh wrote:
> > On 09/11/2013 09:18 AM, Reindl Harald wrote:
> > 
> > 
> >> Am 11.09.2013 15:05, schrieb Daniel J Walsh:
> >>> On 09/11/2013 08:56 AM, Alec Leamas wrote:
> >>>> Although this would work for both our wifes I'd hate it myself. There
> >>>> need to be some way in  the interface to understand what's *really*
> >>>> going on here, the ports opened, triggers etc. But not unless
> >>>> requested, agreed.
> >>>
> >>> My idea is that Samba registers something with firewalld that says here
> >>> is the prompt to show if a process in user space says to open port 2345.
> > 
> >> very very bad idea!
> > 
> > In a perfect world I agree.  Sadly we need something better then we currently
> > have.
> > 
> > Microsoft tried the tell the user about every port connection and this does
> > not work, because users have no idea.
> > 
> > I am trying to find some happy ground between, telling everyone you have to
> > disable firewall to do cool stuff on the desktop.
> > 
> > If a random prompt came up that says "Do you want to share FOOBAR on the
> > internet"?  A non educated user could have a chance of saying No? If it kept
> > on happening, he might even ask someone why his machine is acting weird.
> > 
> > But if he just said setup sharing of FOOBAR he would understand this and make
> > the correct decision.
> > 
> > We have a tool that could be used for labeling the processes that are asking,
> > SELinux, but we would have to eliminate the unconfined_t domain :^(.
> > 
> >> that means if the is no samba running and whatever harmful process needs to
> >> open incoming connections it would trigger the promt for samba
> > 
> >> these is the way to go only if you want to design a security nightmare
> > 
> >>> The problem with this solution is potential conflicts in port numbers and
> >>> pps that just use random ports (Which I think should just not be allowed
> >>> to use the service and would require to disable the firewall.)
> > 
> >> the real problem i described above
> > 
> >> as long the is no way to get *predictable* which service/process is aksing
> >> for open a specific port and verify this on the system level this all is
> >> completly pointless
> > 
> > 
> > 
> 
> Interesting discussion but several things doesn't fit together for me:
> 
> 1. It's firewall's job to manage and keep track of opened ports and
> established connection so it also should be the piece of software that
> asks user if he wants to allow network traffic or not.

Asking users is generally a bad idea, but indeed it should be done by a
central app if ever.

> 2. Why you say there is no way for firewall to know which app is
> requesting specific port to be opened? There is a process name and path
> and it could be identified. It's also easy to maintain database of most
> commonly used binaries and ports that they'd like to open/close. If you
> don't trust binaries on your system it means it's already been
> compromised and firewall is then useless.

You may have a legit app that you do not want to allow to access the
network, for whatever reason (and there are many valid ones).

> 3. If you allow each app to ask for permission to open some port, it'll
> certainly be done in thousand different ways and lack of consistency
> isn't going to help users.

An API to a central service to request access would make sense, then the
central service can decide based on policy whether to grant it, prompt a
user, or whatever.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York