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.
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?
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.
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
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
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.
*** Bug 129129 has been marked as a duplicate of this bug. ***
Fixed in rawhide in package system-config-firewall-1.2.18-1 or newer.
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?
Putting back into ASSIGNED state.
(In reply to comment #8) > Bit more details? Any info on this one?
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> > "
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]$
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?
Closing because there will not be big changes to system-config-firewall anymore.