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.
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 :)
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.
I'm on F21/gnome. I can enable Screen Sharing with a wired network; works great through an SSH tunnel. But when I'm on the wireless network, Screen Sharing is disabled. The option to turn it on is grayed out.
Pstrang: If the wireless network is unencrypted, then it's expected. If you're connected to an encrypted network, it's possible that your NetworkManager is too old. Feel free to file a bug about it against gnome-control-center.
Thank you for the quick response. The wireless network is indeed unencrypted. But I turn off vnc-server firewall services and only remote-desktop within an SSH tunnel.
Pstrang: seeing as you need to modify VNC/Vino's configuration by hand to avoid exporting it on all interfaces, you'll need to start it by hand as well.
20 January 2015 at 14:35
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.
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.
"Firewalls and per-network sharing"
8 Comments -
Why not package firewall policy with the packages?
25 June 2014 at 21:31
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.
26 June 2014 at 11:07
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 :)
26 June 2014 at 11:22
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.
26 June 2014 at 11:41
I'm on F21/gnome. I can enable Screen Sharing with a wired network; works great through an SSH tunnel. But when I'm on the wireless network, Screen Sharing is disabled. The option to turn it on is grayed out.
Can you provide some guidance?
Thanks!
9 January 2015 at 17:01
Pstrang: If the wireless network is unencrypted, then it's expected. If you're connected to an encrypted network, it's possible that your NetworkManager is too old. Feel free to file a bug about it against gnome-control-center.
9 January 2015 at 17:04
Thank you for the quick response. The wireless network is indeed unencrypted. But I turn off vnc-server firewall services and only remote-desktop within an SSH tunnel.
Any other way to override this limitation?
Thank you.
9 January 2015 at 20:28
Pstrang: seeing as you need to modify VNC/Vino's configuration by hand to avoid exporting it on all interfaces, you'll need to start it by hand as well.
20 January 2015 at 14:35