Bug 440469 - RFE: Firewall: PolicyKit integration for desktop applications
Summary: RFE: Firewall: PolicyKit integration for desktop applications
Alias: None
Product: Fedora
Classification: Fedora
Component: system-config-firewall
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Thomas Woerner
QA Contact: Fedora Extras Quality Assurance
: 129129 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2008-04-03 17:40 UTC by Tim Waugh
Modified: 2013-11-06 19:32 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-11-06 19:32:07 UTC
Type: ---

Attachments (Terms of Use)
firewall-reader (1.43 KB, application/x-bzip)
2010-03-03 16:36 UTC, Sven Herzberg
no flags Details

Description Tim Waugh 2008-04-03 17:40:05 UTC
Some desktop applications need to be able to find out if a particular IP port on
the local machine is reachable from the network through the firewall rules so
that the user can be prompted to adjust the firewall settings if necessary. 
Examples are:

* vino
* system-config-printer
* gnome-user-share

Ideally system-config-firewall would provide integration with PolicyKit.  The
goal is that firewall settings can be adjusted by the desktop applications when
user consent is given, in the same way that the system time can be adjusted.

In summary, the two requirements are:

1. ability to discover whether system firewall rules may prevent some service
being reachable from the network

2. ability to get a dialog to the user so that they can say 'allow this' as soon
as the desktop application discovers firewall rules relating to that port

Without requirement #1 the user will just find that things do not work even
though they said "share my desktop" or whatever.

Without requirement #2 the best that can be done is that each desktop
application just invokes system-config-firewall and the user has to decide which
service corresponds to "share my desktop" or whatever.

Comment 1 Tim Waugh 2008-04-22 12:09:11 UTC
In fact, the situation for gnome-user-share seems to be worse than for the
others, in that the user httpd processes bind to random ports.  This means that
it can only work if the user allows a very large range of ports using the
firewall tool.

Further, on a client machine wanting to use the user-shared files, they are not
discoverable from 'Places->Network' unless the Multicast DNS service is allowed
in the firewall tool: so 'nautilus' (which drives the Places->Network window) is
another application that could make good use of a PolicyKit-aware firewall tool.

All that said, I understand that there is a problem with requirement #1 in
comment #0, namely that it would create an information leak.  Currently it is
not possible for a user application to determine the current firewall rules, and
this is a policy decision.  Providing a method for discovering parts of those
rules would undermine that policy.

So here is an alternative scheme: instead of allowing user applications to
discover whether a firewall is blocking the port(s), instead the D-Bus interface
would be a one-way communication from the application to "the system" just
asking for a particular service to be allowed.  The application would not be
told whether the port(s) were already open, or whether the user was asked for
approval, or whether the user approved or denied it.

In this way, a simple D-Bus interface function could be implemented that behaves
something like this pseudo-code:

allow_service (servicename)
  ports = get_ports_for_service (servicename)
  if all_ports_are_open (ports):

  closed_ports = closed_ports_subset (ports)
  approved = policykit_dialog (closed_ports)
  if not approved:

  open_ports (closed_ports)

The details that need to be worked out are how to prevent the user application
from being able to detect that the PolicyKit dialog has been shown to the user.
 Is this possible?

Comment 2 Tim Waugh 2008-07-31 16:24:51 UTC
Simpler idea for this:

I think that for default installations it should be possible for the console
user to query the state of the current firewall on a port-level basis, as above.
 This can be restricted to the console user using D-Bus configuration for the

For installations that place more strict requirements on this information, they
can simply alter the D-Bus configuration for that interface to disallow it being
shared with console users.

Comment 3 Bug Zapper 2008-11-26 10:22:47 UTC
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 4 Colin Walters 2009-04-09 14:40:26 UTC
My take on this is that the only reason this whole "desktop systems must have firewalls" meme got started was old versions of Windows shipped with a lot of vulnerable services listening on ports by default.  And they had some really crazy default services, like one to pop up a dialog box on the desktop with arbitrary text.  

It doesn't make much sense to me to ship a firewall and *also* ship a service by default which pokes arbitrary holes in it.  What's the point?

My suggested solution:

* In both desktop and server, we work to limit and audit services which listen both in a privileged context and in the user session
* Desktop images ship with an open firewall
* Server images ship with ssh-only firewall
* Administrators can do whatever they want using iptables
* User never ever sees "Allow or deny" dialogs with incomprehensible technical stuff

Comment 5 Bastien Nocera 2009-04-09 17:06:17 UTC
We also need more crazy lark for UPNP (discovery and service access) to work, as well as mDNS-advertised services.

So add Rhythmbox, Banshee, Rygel/mediatomb, Totem to the mix. As Colin mentions, I'd rather the firewall just be switched off for the default configurations.

Comment 6 Thomas Woerner 2009-06-03 14:04:52 UTC
*** Bug 129129 has been marked as a duplicate of this bug. ***

Comment 7 Thomas Woerner 2009-09-18 14:52:52 UTC
Fixed in rawhide in package system-config-firewall-1.2.18-1 or newer.

Comment 8 Bastien Nocera 2009-09-18 15:45:47 UTC
Bit more details?

What are apps supposed to do to poke holes? Does this require large amounts of code? What does the code look like on the app side? Is it portable to other distributions?

Comment 9 Thomas Woerner 2009-09-24 09:07:24 UTC
Putting back into ASSIGNED state.

Comment 10 Sven Herzberg 2010-03-03 15:19:55 UTC
(In reply to comment #8)
> Bit more details?

Any info on this one?

Comment 11 Sven Herzberg 2010-03-03 16:09:29 UTC
# dbus-send --system --type=method_call --print-reply --dest=org.fedoraproject.Config.Firewall "/org/fedoraproject/Config/Firewall" org.freedesktop.DBus.Introspectable.Introspect
> method return sender=:1.250 -> dest=:1.302 reply_serial=2
>    string "<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN"
> "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
> <node name="/org/fedoraproject/Config/Firewall">
>   <interface name="org.freedesktop.DBus.Introspectable">
>     <method name="Introspect">
>       <arg direction="out" type="s" />
>     </method>
>   </interface>
>   <interface name="org.fedoraproject.Config.Firewall">
>     <method name="write">
>       <arg direction="in"  type="s" name="rep" />
>       <arg direction="out" type="i" />
>     </method>
>     <method name="read">
>       <arg direction="out" type="s" />
>     </method>
>     <method name="auth">
>       <arg direction="out" type="i" />
>     </method>
>   </interface>
> </node>
> "

Comment 12 Sven Herzberg 2010-03-03 16:36:45 UTC
Created attachment 397601 [details]

This little beast can read data from the firewall. Output on my computer (with mdns and unpriviliges ports open):
> [herzi@boober fw-client]$ ./fw-client 
> Firewall configuration:
> ((lp0
> S'--enabled'
> p1
> aS'--port=1024-65535:tcp'
> p2
> aS'--service=mdns'
> p3
> aS'--service=ssh'
> p4
> aS'/etc/sysconfig/system-config-firewall'
> p5
> tp6
> .
> [herzi@boober fw-client]$

Comment 13 Sven Herzberg 2010-03-03 16:40:24 UTC
My suggestion is that the firewall interface gets a little easier by providing these calls:

  <interface name="org.fedoraproject.Config.Firewall">
    <method name="IsPortOpen">
      <arg direction="in"  type="i" name="port" />
      <arg direction="out" type="b" name="open" />
    <method name="OpenPort">
      <arg direction="in"  type="i" name="port" />
    <method name="ClosePort">
      <arg direction="in"  type="i" name="port" />

This way applications can easily open the ports they like to get. Comments?

Comment 14 Thomas Woerner 2013-11-06 19:32:07 UTC
Closing because there will not be big changes to system-config-firewall anymore.

Note You need to log in before you can comment on or make changes to this bug.