"Workstation" Product defaults to wide-open firewall

[Kevin Kofler]

So, since I was accused of "ignoring" the main part of this mail, let's 
answer it:

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

But Workstation is basically removing the outer layer.

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

I doubt that this is your primary means of house security. For example, do 
you keep your computer in that lockbox?! Yet, it's both expensive and has 
sensitive data on it.

> 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.

But the most effective and safest method is always to prevent the intrusion 
in the first place.

> 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.

That's another important point: You should be running as few network-facing 
services as possible. Those "features" the wide-open firewall is intended to 
make "just work" are all pointless security risks. For example, gnome-user-
share spawns an instance of the frigging Apache httpd (!) in your user 
session. That's totally inappropriate for a desktop system. (Not to mention 
that the UI makes it incredibly easy to accidentally share your files to the 
world, by just dropping them in the Public folder.) So the firewall blocking 
all access to those "features" is actually a GOOD thing, that's exactly what 
it is for. (And we shouldn't be offering those "features" to begin with.)

> 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.

Even for Fedora packages, the "no services by default" rule applies only to 
systemwide services that start with systemd. The desktop "features" that run 
on higher ports are not services and get activated by other mechanisms. Even 
if they don't run by default, they present a UI that makes it easy to enable 
them.

And indeed, third-party software can also be a problem.

> 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.

There, I agree, if we let the attacker run a trojan horse, we have already 
lost. But this is just another argument FOR keeping a tight insulation layer 
to prevent attackers from entering the system in the first place. (And yes, 
I realize that there are more vectors for malware delivery than just network 
intrusion, but network intrusion is one of them and needs to be accurately 
defended against.)

> 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.

That's assuming that the service runs under a confined SELinux context to 
begin with, which won't always be the case. And also that the SELinux policy 
is perfect. It is much safer to not open an Apache httpd instance to the 
attacker in the first place. You can easily prove that "access denied" 
prevents any harm to the system. It's much harder to prove the same with an 
SELinux policy.

> 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.

And I don't agree with that (point 2).

> 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).

That could become an annoyance, and the Workstation folks also seem set 
against that idea, but sure, it'd be an improvement over just keeping 
everything wide open.

But until that happens, we should default to the only safe setting (deny).

        Kevin Kofler