Re: allowing programs to open ports
- Original Message - On 5.1.2015 15:57, Bastien Nocera wrote: - Original Message - Björn Persson wrote: I bet! I worry that the questions would quickly become annoying. But if ports are going to be blocked by default, then there needs to be some way for non-sysadmin users to open them. No, why? The ports just need to be closed, period. Non-sysadmin users shouldn't be allowed to open any ports. Which leads to users being frustrated at the default firewall, which leads to them throwing in the towel and disabling the firewall altogether, leading to worse security. Many people claim this AFAIK nobody posted link to an article/any hard data about this. (I'm not saying that this statement is not correct, I'm saying that I don't have reason to believe it without hard data.) I don't claim to have hard data on this, this is the result of discussions with my co-workers, Fedora developers that use GNOME, and Fedora users. Evidence of this is always going to be circumstantial but when I hear of other GNOME developers that end up using GNOME on Ubuntu with all the problems it brings rather than deal with SELinux or Fedora's firewall, alarm bells start ringing. IMHO solution to this problem is what Stephen Gallagher proposed in other part of this thread: I'd argue that something similar to the SELinux Troubleshooter would be a useful solution here, if interfaces could be added to support it. The SELinux Troubleshooter is positively awful UI for anyone that didn't go read SELinux introductory articles. It's also a bug reporting tool, not an authorisation request as a (bad) firewall UI would need to be. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: allowing programs to open ports
On 5.1.2015 15:57, Bastien Nocera wrote: - Original Message - Björn Persson wrote: I bet! I worry that the questions would quickly become annoying. But if ports are going to be blocked by default, then there needs to be some way for non-sysadmin users to open them. No, why? The ports just need to be closed, period. Non-sysadmin users shouldn't be allowed to open any ports. Which leads to users being frustrated at the default firewall, which leads to them throwing in the towel and disabling the firewall altogether, leading to worse security. Many people claim this AFAIK nobody posted link to an article/any hard data about this. (I'm not saying that this statement is not correct, I'm saying that I don't have reason to believe it without hard data.) IMHO solution to this problem is what Stephen Gallagher proposed in other part of this thread: I'd argue that something similar to the SELinux Troubleshooter would be a useful solution here, if interfaces could be added to support it. -- Petr^2 Spacek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: allowing programs to open ports
- Original Message - Björn Persson wrote: I bet! I worry that the questions would quickly become annoying. But if ports are going to be blocked by default, then there needs to be some way for non-sysadmin users to open them. No, why? The ports just need to be closed, period. Non-sysadmin users shouldn't be allowed to open any ports. Which leads to users being frustrated at the default firewall, which leads to them throwing in the towel and disabling the firewall altogether, leading to worse security. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: allowing programs to open ports
Björn Persson wrote: I bet! I worry that the questions would quickly become annoying. But if ports are going to be blocked by default, then there needs to be some way for non-sysadmin users to open them. No, why? The ports just need to be closed, period. Non-sysadmin users shouldn't be allowed to open any ports. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: allowing programs to open ports
Hi On Sun, Jan 4, 2015 at 6:32 PM, Kevin Kofler wrote: Björn Persson wrote: I bet! I worry that the questions would quickly become annoying. But if ports are going to be blocked by default, then there needs to be some way for non-sysadmin users to open them. No, why? The ports just need to be closed, period. Non-sysadmin users shouldn't be allowed to open any ports. That won't work in a world where users *are* the sysadmins as well. Even in a small business where one has a sysadmin, they aren't focused on internal issues all that much. Users are expected to cope up. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: allowing programs to open ports
Stephen John Smoogen wrote: 1) I do not feel that countless programs will or want to accept patches to open ports twice. I expect them to actually open a port once and if they want to work with firewalld or some other firewall daemon signal on dbus that they are looking to have a port open using a predefined and open protocol. The port will be open like it always was and the firewall will be closed if they don't use it, and possibly open if they do (depending on the top level policy of whatever firewall management program is there). Fine, so they wouldn't be patches to open ports twice, they'd be patches to ask FirewallD to open the firewall in addition to opening ports. Whatever. The point is that a lot of programs would have to be patched to do a Fedora-specific thing, and the patches would either have to be accepted upstream or carried in Fedora, or else the programs wouldn't work on Fedora. 3) glibc is meant to work on multiple OS's and distributions. Fedora and even Red Hat are not important enough to force through a change that isn't in the interests of other distributions. Which is where the vague politics comes up. This sort of change would require working with other distributions, other OS's and other organizations to get their consensus on how it should work. That takes a long amount of meetings, talking with people, showing them why it would be worthwhile, figuring out all the corner cases and seeing if they are fixable, etc. And it would see if it breaks various 'promises' like POSIX compliance and such that the glibc team work actively to keep. All of that is true, but I don't see how it would be an argument for signaling FirewallD from many places rather than from one place. Most of the programs are also meant to work on multiple OSes and distributions, and I doubt that their developers would be happy to implement multiple distribution-specific protocols for opening firewalls. It would still require lots of discussions to get all of those distributions, OSes and organizations to agree on a single firewall-opening protocol, regardless of whether that protocol would then be used from GlibC of from each program individually. -- Björn Persson signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: allowing programs to open ports
Florian Weimer wrote: On 12/21/2014 05:28 PM, Björn Persson wrote: Alternatively, cut out the packet filter and have GlibC ask the user whether the call to bind or connect shall be allowed to succeed (or automatically allow or deny the call if so configured). This has the advantage that the program is informed that it's not allowed to communicate. glibc is the wrong place for this, and a patch in this direction has absolutely zero chance of being accepted upstream. We also ship applications which call system calls directly, not through glibc, so patching glibc would not even work at a technical level. That's true. The ability to call system calls directly kills the idea of having GlibC deny the call. (It does not affect the idea of calling FirewallD from GlibC rather than from each program individually. Those few programs that do call system calls directly could still call FirewallD on their own.) However, a Linux Security Module such as SELinux could audit socket creation, and provide the user with means to override the default choices. Yes, that may be an even better solution if there is a way for SElinux to ask the user. However, this will be extremely controversial (even more so than the open firewall) because it will remind people of “personal firewalls” on Windows. I bet! I worry that the questions would quickly become annoying. But if ports are going to be blocked by default, then there needs to be some way for non-sysadmin users to open them. -- Björn Persson signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: allowing programs to open ports
Stephen John Smoogen wrote: Uhm no. You seem to be wanting a fight over something, and I have no mood to engage. I hope you have a more pleasant holidays than what your tone indicates you are currently having. The idea of making two calls to open a port seemed like a bad design to me, so I proposed what seemed like a better design. I received a reply that rejected my proposal for a very vague technical reason and an incomplete political reason, so I asked for clarification of both reasons. I honestly can't see how any of that would come across as picking a fight. In general I wish people could discuss the technical merits of proposed solutions without turning the discussions into personal fights all the time. -- Björn Persson signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: allowing programs to open ports
On Mon, Dec 22, 2014 at 9:26 AM, Björn Persson Bjorn@rombobjörn.se wrote: Stephen John Smoogen wrote: Uhm no. You seem to be wanting a fight over something, and I have no mood to engage. I hope you have a more pleasant holidays than what your tone indicates you are currently having. The idea of making two calls to open a port seemed like a bad design to me, so I proposed what seemed like a better design. FWIW we already have a mechanism to restricts which ports specific applications are allowed to open without using firewalld at all. Its called SELinux (only works for confined domains but server applications should run in one anyway). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: allowing programs to open ports
Am 22.12.2014 um 10:10 schrieb drago01: On Mon, Dec 22, 2014 at 9:26 AM, Björn Persson Bjorn@rombobjörn.se wrote: Stephen John Smoogen wrote: Uhm no. You seem to be wanting a fight over something, and I have no mood to engage. I hope you have a more pleasant holidays than what your tone indicates you are currently having. The idea of making two calls to open a port seemed like a bad design to me, so I proposed what seemed like a better design. FWIW we already have a mechanism to restricts which ports specific applications are allowed to open without using firewalld at all. Its called SELinux (only works for confined domains but server applications should run in one anyway) that don't solve the firewall open on ports greater than 1024 on workstations starting with F21 as long as you don't forbid *any* application without a SELinux context to open a non-privileged port signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: allowing programs to open ports
On 12/21/2014 05:28 PM, Björn Persson wrote: Alternatively, cut out the packet filter and have GlibC ask the user whether the call to bind or connect shall be allowed to succeed (or automatically allow or deny the call if so configured). This has the advantage that the program is informed that it's not allowed to communicate. glibc is the wrong place for this, and a patch in this direction has absolutely zero chance of being accepted upstream. We also ship applications which call system calls directly, not through glibc, so patching glibc would not even work at a technical level. However, a Linux Security Module such as SELinux could audit socket creation, and provide the user with means to override the default choices. However, this will be extremely controversial (even more so than the open firewall) because it will remind people of “personal firewalls” on Windows. -- Florian Weimer / Red Hat Product Security -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: allowing programs to open ports
Am 22.12.2014 um 11:49 schrieb Florian Weimer: On 12/21/2014 05:28 PM, Björn Persson wrote: Alternatively, cut out the packet filter and have GlibC ask the user whether the call to bind or connect shall be allowed to succeed (or automatically allow or deny the call if so configured). This has the advantage that the program is informed that it's not allowed to communicate. glibc is the wrong place for this, and a patch in this direction has absolutely zero chance of being accepted upstream. We also ship applications which call system calls directly, not through glibc, so patching glibc would not even work at a technical level. However, a Linux Security Module such as SELinux could audit socket creation, and provide the user with means to override the default choices. However, this will be extremely controversial (even more so than the open firewall) because it will remind people of “personal firewalls” on Windows. and exactly the behavior of personal firewalls on Windows is needed when somebody insinuates users can't handle a static firewall configuration at all and a few broken applications with random ports don't get fixed by intention signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: allowing programs to open ports
On 22 December 2014 at 01:26, Björn Persson Bjorn@rombobjörn.se wrote: Stephen John Smoogen wrote: Uhm no. You seem to be wanting a fight over something, and I have no mood to engage. I hope you have a more pleasant holidays than what your tone indicates you are currently having. The idea of making two calls to open a port seemed like a bad design to me, so I proposed what seemed like a better design. I received a reply that rejected my proposal for a very vague technical reason and an incomplete political reason, so I asked for clarification of both reasons. I honestly can't see how any of that would come across as picking a fight. In general I wish people could discuss the technical merits of proposed solutions without turning the discussions into personal fights all the time. I would love that also. But as far as I can tell you started the personal fight. It is very hard to believe you wanted a technical discussion with sentence structure like: So you think that countless other upstreams would feel compelled to accept the patches to always open ports twice, because they want their software to work on Fedora, but GlibC is important enough to be able to refuse without risk of being dropped from Fedora? Or maybe that GlibC can refuse because it's a library and can push the problem up to the programs? You barrel over my attempt at conversation by giving me idiotic options to try and defend that I never said in the first place.. To try and technically answer your strawmen questions: 1) I do not feel that countless programs will or want to accept patches to open ports twice. I expect them to actually open a port once and if they want to work with firewalld or some other firewall daemon signal on dbus that they are looking to have a port open using a predefined and open protocol. The port will be open like it always was and the firewall will be closed if they don't use it, and possibly open if they do (depending on the top level policy of whatever firewall management program is there). 2) glibc is important enough to be able to refuse without risk of being dropped from Fedora. Just like the kernel is important enough to regularly refuse things without risk of being dropped from Fedora. 3) glibc is meant to work on multiple OS's and distributions. Fedora and even Red Hat are not important enough to force through a change that isn't in the interests of other distributions. Which is where the vague politics comes up. This sort of change would require working with other distributions, other OS's and other organizations to get their consensus on how it should work. That takes a long amount of meetings, talking with people, showing them why it would be worthwhile, figuring out all the corner cases and seeing if they are fixable, etc. And it would see if it breaks various 'promises' like POSIX compliance and such that the glibc team work actively to keep. -- Björn Persson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: allowing programs to open ports (was: 5tFTW: Fedora 21, 22, and 19, firewall discussion, and holiday break)
On 21 December 2014 at 09:28, Björn Persson Bjorn@rombobjörn.se wrote: Mattia Verga wrote: The alternative could be a open approach from Firewalld, where an application, when it's executed, can inform firewalld that needs to open a port, firewalld asks the user if it should grant access to the application and then opens the port... but this needs to be implemented in the source of every application, it can eventually be sponsored to become a standard in the linux world. There is already a way for an application to inform the operating system that it needs to open a port. It's called the Berkeley socket API, and every program that communicates across a network already uses it. Why don't you guys patch GlibC's implementations of bind and connect to notify FirewallD and get it automatically enabled in every program, instead of requiring every communicating program to call a second API in addition to the Berkeley socket API? I am expecting because the patch would break other things and would be something that upstream would not want accept to glibc. With Fedora not wanting to put in patches not accepted by upstream it would be less accepted that firewalld is. Alternatively, cut out the packet filter and have GlibC ask the user whether the call to bind or connect shall be allowed to succeed (or automatically allow or deny the call if so configured). This has the advantage that the program is informed that it's not allowed to communicate. -- Björn Persson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: allowing programs to open ports
Stephen John Smoogen wrote: On 21 December 2014 at 09:28, Björn Persson Bjorn@rombobjörn.se wrote: Mattia Verga wrote: The alternative could be a open approach from Firewalld, where an application, when it's executed, can inform firewalld that needs to open a port, firewalld asks the user if it should grant access to the application and then opens the port... but this needs to be implemented in the source of every application, it can eventually be sponsored to become a standard in the linux world. There is already a way for an application to inform the operating system that it needs to open a port. It's called the Berkeley socket API, and every program that communicates across a network already uses it. Why don't you guys patch GlibC's implementations of bind and connect to notify FirewallD and get it automatically enabled in every program, instead of requiring every communicating program to call a second API in addition to the Berkeley socket API? I am expecting because the patch would break other things What things would it break that wouldn't be broken if every program had to call FirewallD on its own? and would be something that upstream would not want accept to glibc. With Fedora not wanting to put in patches not accepted by upstream it would be less accepted that firewalld is. So you think that countless other upstreams would feel compelled to accept the patches to always open ports twice, because they want their software to work on Fedora, but GlibC is important enough to be able to refuse without risk of being dropped from Fedora? Or maybe that GlibC can refuse because it's a library and can push the problem up to the programs? -- Björn Persson signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: allowing programs to open ports
On 21 December 2014 at 14:40, Björn Persson Bjorn@rombobjörn.se wrote: Stephen John Smoogen wrote: On 21 December 2014 at 09:28, Björn Persson Bjorn@rombobjörn.se wrote: Mattia Verga wrote: The alternative could be a open approach from Firewalld, where an application, when it's executed, can inform firewalld that needs to open a port, firewalld asks the user if it should grant access to the application and then opens the port... but this needs to be implemented in the source of every application, it can eventually be sponsored to become a standard in the linux world. There is already a way for an application to inform the operating system that it needs to open a port. It's called the Berkeley socket API, and every program that communicates across a network already uses it. Why don't you guys patch GlibC's implementations of bind and connect to notify FirewallD and get it automatically enabled in every program, instead of requiring every communicating program to call a second API in addition to the Berkeley socket API? I am expecting because the patch would break other things What things would it break that wouldn't be broken if every program had to call FirewallD on its own? and would be something that upstream would not want accept to glibc. With Fedora not wanting to put in patches not accepted by upstream it would be less accepted that firewalld is. So you think that countless other upstreams would feel compelled to accept the patches to always open ports twice, because they want their software to work on Fedora, but GlibC is important enough to be able to refuse without risk of being dropped from Fedora? Or maybe that GlibC can refuse because it's a library and can push the problem up to the programs? Uhm no. You seem to be wanting a fight over something, and I have no mood to engage. I hope you have a more pleasant holidays than what your tone indicates you are currently having. -- Björn Persson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
