"Workstation" Product defaults to wide-open firewall

Tue Dec 9 01:05:41 UTC 2014

On Tue, 2014-12-09 at 01:28 +0100, Kevin Kofler wrote:
> Matthew Miller wrote:
> > Whether you agree or not, reasonable people argue that a host-based packet
> > filter isn't really a meaningful increase in security. I don't think we're
> > _really_ leaving the security emphasis behind.
> 
> And I argue that the firewall is by far the most important security 
> mechanism we have available, and a lot more effective than SELinux, which we 
> are forcing on all our Spins. Instead of merely trying to limit the damage 
> an intruder can do, it's a lot safer (and also less annoying to legitimate 
> users) to not let them intrude in the first place.
> 

I think you're forgetting the core tenet of security: good security is
*always* layered.

> How do you protect your house or apartment from thieves? Do you:
> (a) … lock your entrance door? or

Yes

> (b) … put locks on every single valuable item to keep it from being removed?

Also yes: I keep my irreplaceable and most valuable things inside a
fireproof lockbox inside my locked house.

I may also have (c) between (a) and (b) which is a house alarm system
tied to the local police department, so that when (a) fails, the police
may arrive before the intruders have time to open my lockbox (or rip it
out of the wall, etc.)

> A firewall does (a), SELinux does (b).
> 

Sure, and these are both parts of the story. We also have kernel
auditing, container faux-isolation and other useful techniques that work
to minimize the potential damage.

Remember, even in the "DROP everything" firewall, if you're running a
service, there's a chance that a vulnerability will be found in it. Now
they've escalated past the service and you need to rely on those
non-firewall solutions. It will always be impossible to eliminate all
human coding errors.

Now, the real question to ask here is not "Is the firewall secure?" but
"Is my system secure?".

The fundamental question at stake here is this: "What new avenues of
attack are open if I don't block this firewall port?".

If there are system services running on that port that are unexpected,
then this can lead to an overall increase in attack surface (partly
because of the additional possibility of coding errors as well as the
admin being unaware that it's running and therefore not accounting for
it).

I think we're (Fedora) in reasonably good shape here in the core distro,
because we have a lot of stringent requirements on packagers not to
start any services by default. There *is* a net lowering of security
when we look to the larger open-source ecosystem where others providing
packages may not be following this rule. So that's an argument for this
being a net lowering of security.

Other than a package ignoring the rules, the only other case I can think
of would be a malicious trojan horse. Of course, if an attacker already
has sufficient access to run a network service on your system, they have
already achieved a level of control of at least one user account.

In this case, the primary risk is that of inappropriate data access to
content visible to the affected user or being joined to a botnet without
the user's knowledge. Both cases are fairly serious, and therefore
constitute a considerable degree of concern, but I would also argue that
this is mitigated by other factors. In the data-access case, this is a
perfect example of where the layered security comes into play. If the
SELinux rules are properly enforced, malware that comes in through e.g.
Apache would not be privileged to actually access anything besides the
static HTML files. The bot-net case is less easy for us to deal with,
but while it's a net loss in security for the internet at large, I'd say
that it's less of a *direct* concern for the compromised machine itself.

So from a pure security perspective, I'd come to the following
conclusions:

1) Yes, there is a net reduction in security and
2) It's probably a sufficiently small reduction given the other layered
mechanisms in place.

I'm not sure I necessarily buy the UI decisions either; I think if we
push for appropriate systemd and firewalld integration (perhaps
requiring all network services to request their port via systemd's
socket-activation feature which can be extended to talking to a prompter
for the GUI; just spitballing here), it should be possible to provide at
least a somewhat reasonable interface to at least let the user know that
"<application> wants to listen on the network. Is this expected?" (and
perhaps maintain a sensible whitelist for things like SSHD).

I'd leave it up to the designers to figure out the actual correct
approach to that, but I'd like to see that discussion happen (again,
since I *do* know that some of it happened the first time around).

> > On Mon, Dec 08, 2014 at 03:20:30PM -0500, Mike Pinkerton wrote:
> >> Perhaps the Workstation team thought that opening up the firewall
> >> defaults was the best compromise.  I disagree.  Perhaps a better
> >> compromise would have been to leave the old defaults in place, and
> >> add a new pre-configured "more open" zone for those who want fewer
> >> constraints.AAAA
> > 
> > Wait, my last paragraph was a great end to a long message :) but I need
> > to also add: please take a look at the actual implementation. The above
> > suggestion is _exactly_ what was done.
> 
> Uh no, it was not.
> 1. The default zone is the insecure one. Mike Pinkerton says that the
>    default zone should be the secure one, and the insecure one opt-in, not
>    opt-out (and I agree with him).

I generally agree, but I'll come at it with the caveat that the "pure"
secure solution of blocking everything has usability issues that need to
be balanced as well. For example, people STILL have trouble working with
network printers. In 2014.

> 2. The tool to change to a secure firewall zone isn't even installed by
>    default.

This is a somewhat misleading statement. The GUI tool to change the
default isn't in place, but there is 

1) The CLI tool to change the default (see my earlier message to this
thread)
2) A GUI tool to change the zone on any or all of the network interfaces
on the system. Change them all and it's the same as changing the
default.

Also, while I think it's been unclear in this thread, the main reason
that the firewall GUI was taken out was because the Workstation guys
want to design a more user-understandable one and include that directly
(if I am remembering that conversation correctly). The current one is
not terribly easy to understand (though it's certainly an improvement
over s-c-firewall).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20141208/c712fba3/attachment.sig>