On Wed, 2013-09-11 at 23:18 +0200, Mateusz Marzantowicz wrote: > On 11.09.2013 17:24, Daniel J Walsh wrote: > > On 09/11/2013 09:18 AM, Reindl Harald wrote: > > > > > >> Am 11.09.2013 15:05, schrieb Daniel J Walsh: > >>> On 09/11/2013 08:56 AM, Alec Leamas wrote: > >>>> Although this would work for both our wifes I'd hate it myself. There > >>>> need to be some way in the interface to understand what's *really* > >>>> going on here, the ports opened, triggers etc. But not unless > >>>> requested, agreed. > >>> > >>> My idea is that Samba registers something with firewalld that says here > >>> is the prompt to show if a process in user space says to open port 2345. > > > >> very very bad idea! > > > > In a perfect world I agree. Sadly we need something better then we currently > > have. > > > > Microsoft tried the tell the user about every port connection and this does > > not work, because users have no idea. > > > > I am trying to find some happy ground between, telling everyone you have to > > disable firewall to do cool stuff on the desktop. > > > > If a random prompt came up that says "Do you want to share FOOBAR on the > > internet"? A non educated user could have a chance of saying No? If it kept > > on happening, he might even ask someone why his machine is acting weird. > > > > But if he just said setup sharing of FOOBAR he would understand this and make > > the correct decision. > > > > We have a tool that could be used for labeling the processes that are asking, > > SELinux, but we would have to eliminate the unconfined_t domain :^(. > > > >> that means if the is no samba running and whatever harmful process needs to > >> open incoming connections it would trigger the promt for samba > > > >> these is the way to go only if you want to design a security nightmare > > > >>> The problem with this solution is potential conflicts in port numbers and > >>> pps that just use random ports (Which I think should just not be allowed > >>> to use the service and would require to disable the firewall.) > > > >> the real problem i described above > > > >> as long the is no way to get *predictable* which service/process is aksing > >> for open a specific port and verify this on the system level this all is > >> completly pointless > > > > > > > > Interesting discussion but several things doesn't fit together for me: > > 1. It's firewall's job to manage and keep track of opened ports and > established connection so it also should be the piece of software that > asks user if he wants to allow network traffic or not. Asking users is generally a bad idea, but indeed it should be done by a central app if ever. > 2. Why you say there is no way for firewall to know which app is > requesting specific port to be opened? There is a process name and path > and it could be identified. It's also easy to maintain database of most > commonly used binaries and ports that they'd like to open/close. If you > don't trust binaries on your system it means it's already been > compromised and firewall is then useless. You may have a legit app that you do not want to allow to access the network, for whatever reason (and there are many valid ones). > 3. If you allow each app to ask for permission to open some port, it'll > certainly be done in thousand different ways and lack of consistency > isn't going to help users. An API to a central service to request access would make sense, then the central service can decide based on policy whether to grant it, prompt a user, or whatever. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
