On Mon, 2019-08-26 at 09:15 -0400, Robert Marcano wrote: > On 8/26/19 9:07 AM, mcatanzaro@xxxxxxxxx wrote: > > Well the thing is, blocknig ports tends to break applications that > > want > > to use those ports. We're not going to do that, period. It also > > doesn't > > really accomplish anything: either your app or service needs > > network > > access and you have whitelisted it (in which case the firewall > > provides > > no security), or it needs network access and you have not > > whitelisted it > > (in which case your firewall breaks your app/service). In no case > > does > > it increase your security without breaking your app, right? Unless > > you > > have malware installed (in which case, you have bigger problems > > than the > > firewall). Or unless you have a vulnerable network service > > installed > > that you don't want (in which case, uninstall it). > > This is a reasonable point of view, until you notice Linux desktops > evironments don't provide applications with a method to detect if > they > are running on a private network or not (See Windows Home, Office, > Internet network settings). > > Then a non technical user start Rythmbox, enable music sharing, and > it > works perfectly on their home network but then decides to buy a WAN > card/USB stick and suddenly all the music is being shared to the > world. > > I wish NetworkManager could do something about these situations, > maybe > the default should be the public zone for interfaces that receive > public > IP addresses. The idea was originally that applications like Rhythmbox or desktop sharing or printer sharing or whatever would do something intelligent with the currently active firewalld zone that NM puts the connected interface into. eg if the zone was "public" Rhythmbox wouldn't enable sharing. Unfortunately applications didn't do that, and the mechanism to tie all these things together (assigning zone to connections, having applications know about zones, what happens if you're not running firewalld, etc) were never fully planned out or implemented. Dan > > So if you want to change the firewall settings, you'd need to > > completely > > rethink how the firewall works. And nobody seems interested in > > doing > > that. We could e.g. have a list of apps th at are allowed network > > access, but then we'd need some form of attestation so apps can't > > impersonate each other. So only sandboxed (flatpaked) apps could > > use > > this hypothetical new firewall. And we surely don't want to have > > yes/no > > permission prompts, so we can't really ask the user "do you want > > your > > app to access the network?" (the user will almost always say yes). > > I'm > > not really sure what design would even work. > > > > Avoiding unnecessary network services makes more sense. > > > > On Mon, Aug 26, 2019 at 3:45 PM, Alexander Ploumistos > > <alex.ploumistos@xxxxxxxxx> wrote: > > > As a matter of fact, you did: > > > https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/3LHDQD5HCZMPV6O4LZRSKTVEIKEFJIBY/#3LHDQD5HCZMPV6O4LZRSKTVEIKEFJIBY > > > https://docs.fedoraproject.org/en-US/Fedora/21/html/Release_Notes/sect-Products.html#idm225474210784 > > > > Thanks for dredging up these links! > > > > Michael > > > > _______________________________________________ > > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > > 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@xxxxxxxxxxxxxxxxxxxxxxx > > > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx