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 > bolted. 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 solution. 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 > >firewall. > And what if the malicious script doesn't just listen, but actively > phones home? If that's the case, then it's SELinux's issue. > Let's just say I'm talking about granting permission with Polkit like > 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 node.js, where > >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 the malicious Javascript doesn't just run a backdoor, but actively > phones home? 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` > >before. > > 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 > >got listening. > > 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 > >permissions. > > 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 like that. > Or would the permissions be stored permanently somewhere? In that case, > how would you prevent a malicious program from impersonating one of the > permissioned programs? 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. <joh...@splentity.com> Splentity https://splentity.com/ _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
