I'm not sure why this isn't clear, but the examples that I provided are far
from the only aspects, and I notice you're only addressing the ones that
require the user to manually run something.
Consider this. Our default ssh config, under your firewall config, would allow
any system on any network your system is connected to to break in. If you're
running local, it's open to any system on a network you're on. If you're
running postgres, same deal, and so on.
Regardless, I suppose I'll still address your points:
On Tuesday, August 27, 2019 9:14:10 AM MST Björn Persson wrote:
John Harris wrote:
>On Tuesday, August 27, 2019 5:36:20 AM MST Björn Persson wrote:
>> Please elaborate. Where does the script come from, what exactly happens
>> by accident, and how would a packet filter stop it?
>It could come from anywhere, that's not the point. A *firewall* would stop
>it from doing anything too harmful: Opening up the system to the world by
>binding a port, or listening on a UDP port.
If it could come from anywhere, then we must assume that it's malicious.
You executed untrusted code. It's already past your firewall. Game over,
you're infected. You're closing the stable door after the horse has
The idea that once one part of the system is affected, every security aspect
should be disregarded is absolutely absurd. That would be like the example I
sent to this list before, getting robbed, and leaving your doors unlocked as a
Different parts of the system deal with security in different ways.
>It'd still be bound, or would still be listening on a port,
but it wouldn't
>be accessible unless somebody went and manually opened a port on the
And what if the malicious script doesn't just listen, but actively
If that's the case, then it's SELinux's issue.
Let's just say I'm talking about granting permission with
you mention below, whichever way you envision that.
If the user chooses to allow it, that's one thing. We can still supply a
secure default. The user is always free to run their system however they want.
>Additionally, I'm referring to incidents like that common in
>a package gets modified to something malicious, and then runs a backdoor
>which is accessible over a given port.
Again, it's already past your firewall. You're already infected. What
If that were the case, it'd be the job of SELinux, if anything. It's usually
not, which may surprise you. Regardless, the fact that you envision a
different attack vector, which we already deal with to the best of our
ability, doesn't mean that we should not address another attack vector, which
is actually the topic at hand.
>> How would a "vulnerability" "bind a
port"? If the program is supposed
>> to communicate, then it will be allowed, and any vulnerabilities it has
>> are then exposed to the network. If it's not supposed to communicate,
>> then it won't randomly sprout a network service because of a bug.
>For example, RCEs, specific or otherwise. This has happened in `firefox`
OK so you meant the case below:
>> If you mean that an arbitrary code execution vulnerability has been
>> exploited, so that the program is now executing the attacker's code,
>> then it's already too late. The attack code won't listen for incoming
>> connections. It will make an outgoing connection to its master. And in
>> case you're considering requiring permission even for outgoing
>> connections – which would be unbearable to the user – the attack code
>> would just make an API call (through Dbus or whatever) to grant itself
>> permission to communicate.
>Just because a potential attacker may have already compromised part of a
>system doesn't mean that you just open up the firewall to anything they've
And for the fourth time: It's not listening, it's actively phoning home.
And for the nth time: That's generally not the case, and if it were, it'd be
an issue for a different part of the security subsystems installed on a given
Fedora system, most likely SELinux. Let's address what we can actually address
with reference to the firewall, rather than attempting to deflect
responsibility. If you really want to get into it, our default firewall could
be tuned to only allow certain outgoing traffic as well, but I would be
against such a move.
>Additionally, such a thing trying to open a port would likely
>require Polkit to grant you permission to do so first, which would, by
>default, require the user to authenticate and have the appropriate
Do you expect users to type their passphrase every single time they
want to play some peer-to-peer game, or make an Internet phone call, or
download something with Bittorrent, et cetera?
I fail to see what that has to do with firewall management. Of course not, I'd
hope they're not trying to run those programs as root or something ridiculous
Or would the permissions be stored permanently somewhere? In that
how would you prevent a malicious program from impersonating one of the
We don't have an application based firewall, so I don't know what you're
talking about. Firewall rules, on Fedora, are handled entirely by firewalld.
John M. Harris, Jr. <johnmh(a)splentity.com>