Wednesday, 25 June 2014

Firewalls and per-network sharing

Firewalls

Fedora has had problems for a long while with the default firewall rules. They would make a lot of things not work (media and file sharing of various sorts, usually, whether as a client or a server) and users would usually disable the firewall altogether, or work around it through micro-management of opened ports.

We went through multiple discussions over the years trying to break the security folks' resolve on what should be allowed to be exposed on the local network (sometimes trying to get rid of the firewall). Or rather we tried to agree on a setup that would be implementable for desktop developers and usable for users, while still providing the amount of security and dependability that the security folks wanted.

The last round of discussions was more productive, and I posted the end plan on the Fedora Desktop mailing-list.

By Fedora 21, Fedora will have a firewall that's completely open for the user's applications (with better tracking of what applications do what once we have application sandboxing). This reflects how the firewall was used on the systems that the Fedora Workstation version targets. System services will still be blocked by default, except a select few such as ssh or mDNS, which might need some tightening.

But this change means that you'd be sharing your music through DLNA on the café's Wi-Fi right? Well, this is what this next change is here to avoid.

Per-network Sharing

To avoid showing your music in the caf, or exposing your holiday photographs at work, we needed a way to restrict sharing to wireless networks where you'd already shared this data, and provide a way to avoid sharing in the future, should you change your mind.

Allan Day mocked up such controls in our Sharing panel which I diligently implemented. Personal File Sharing (through gnome-user-share and WedDAV), Media Sharing (through rygel and DLNA) and Screen Sharing (through vino and VNC) implement the same per-network sharing mechanism.

Make sure that your versions of gnome-settings-daemon (which implements the starting/stopping of services based on the network) and gnome-control-center match for this all to work. You'll also need the latest version of all 3 of the aforementioned sharing utilities.

(and it also works with wired network profiles :)



4 comments:

liam said...

Why not package firewall policy with the packages?

Bastien Nocera said...

liam: Because most of the sharing programs that run in the user's session use dynamic ports, so the firewall rules can't be hard-coded.

And if you get the programs to open the ports, you'll need to modify a large number of programs, and untrusted programs will be able to open ports anyway. Which wouldn't be any different from not having a firewall for those at all.

Colin Guthrie said...

So am I right in saying that if I turn off Media sharing for a given network, it physically stops the services running then, and then starts them again if I join a different, trusted network?

Do the ports in question stay open by default? Therefore if I happen to run some random code that opens a port, it can be contacted from the outside?

It would seem to me that listening on various ports should be something that the user ack's via some kind of GUI and the choices noted for future reference, such as:

Media Sharing" wants to listen on your network and allow incoming connections.

What do you want to do?

[ Allow always ] [ Allow on "Colin's Wifi" ] [ Deny for now ] [ Deny always ]



I can appreciate the problems here but any solution that relies on the firewall being open but there not being any listening services just feels wrong. Perhaps I've misunderstood tho'?

I do think that this is indeed a problem that needs solved so KUTGW regardless :)

Bastien Nocera said...

Colin: The (user) ports stay open by default. It will start if you requested it to start on a particular network. Instead of nagging the user with questions, we expect him/her to actively request the sharing.

gnome-settings-daemon is responsible for starting and stopping the services, so the services don't start unless you've requested for them to be started.

Random code can listen on the network. That's no different from the 2 other options: switching off the firewall, obviously, or allowing applications (that can't yet be identified for certain) to open ports in the system firewall.

In the future, that "random code" will be sandboxed, and we'll be able to allow/disallow network access.