"Workstation" Product defaults to wide-open firewall

William B william at firstyear.id.au
Tue Dec 9 21:43:54 UTC 2014

Hash: SHA1

> If by opening up some ports that would have hampered the user, rather
> than protect them[1], we avoid the users disabling the firewall, and
> exposing security critical services (such as exposing rpcbind, or
> ntpd, or any other root service), then it's a win for me.

> [1]: I haven't seen anything but arm-flailing on that issue. If
> somebody wants to go into details about what a server running inside
> the user's session would be able to do that a client wouldn't be able
> to, feel free.

Arm flailing looks more like this:

"Err mah gosh, dey touck ourz firewallz away, how's will I be totes secure now?"

I am not "arm flailing". I have provided some logical examples of why this is bad:

* Exploited applications are now more easily able to communicate back to C&C systems. Most applications are not "sandboxed", and even if they were, this sandboxing is not an excuse to open up other parts of the system.
* In some circumstances the impact may be wider than the "local network" especially when you consideripv6.
* The reason for this choice seems to stem from resistance to creating a UI that asks users for their permission.
* You cannot make any assumptions about the client software a user will run or about wheter it is "secure", no as in "does it use SSL", but as in "does it have remote exploits or other issues?". What if rhythmbox has an RCE? What about pidgin? Evolution?
* Users are intentionally decived. When they look they will see "firewall is active" without realising that it practically amounts to "open". We are taking control away from our users.
* This "very loose" firewall policy appears to fly directly in the face of the FESCO descision that disallowed you from disabling the firewall. You may as well have disabled it with the policy that is in place now.

Right now however, I believe that this issue will not be sorted on the mailing list. You Bastien have "bunkered down" and are defending this as much as possible, and I do not believe you are willing to have a discussion about this matter.

At this stage the only way to move forward is to raise a critically rated bugzilla security issue within fedora, or to create a FESCO ticket.


I have used some of my points from above in this ticket.

- -- 

William Brown

Version: GnuPG v2


More information about the devel mailing list