Bug 440469 - RFE: Firewall: PolicyKit integration for desktop applications
RFE: Firewall: PolicyKit integration for desktop applications
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: system-config-firewall (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Woerner
Fedora Extras Quality Assurance
: Reopened
: 129129 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-03 13:40 EDT by Tim Waugh
Modified: 2013-11-06 14:32 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-06 14:32:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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

  None (edit)
Description Tim Waugh 2008-04-03 13:40:05 EDT
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 08:09:11 EDT
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):
    return

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

  open_ports (closed_ports)
  return
}

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 12:24:51 EDT
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
interface.

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 05:22:47 EST
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 4 Colin Walters 2009-04-09 10:40:26 EDT
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 13:06:17 EDT
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 10:04:52 EDT
*** Bug 129129 has been marked as a duplicate of this bug. ***
Comment 7 Thomas Woerner 2009-09-18 10:52:52 EDT
Fixed in rawhide in package system-config-firewall-1.2.18-1 or newer.
Comment 8 Bastien Nocera 2009-09-18 11:45:47 EDT
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 05:07:24 EDT
Putting back into ASSIGNED state.
Comment 10 Sven Herzberg 2010-03-03 10:19:55 EST
(In reply to comment #8)
> Bit more details?

Any info on this one?
Comment 11 Sven Herzberg 2010-03-03 11:09:29 EST
From:
# 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 11:36:45 EST
Created attachment 397601 [details]
firewall-reader

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 11:40:24 EST
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>
    <method name="OpenPort">
      <arg direction="in"  type="i" name="port" />
    </method>
    <method name="ClosePort">
      <arg direction="in"  type="i" name="port" />
    </method>
  </interface>

This way applications can easily open the ports they like to get. Comments?
Comment 14 Thomas Woerner 2013-11-06 14:32:07 EST
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.