Reposted from http://fedoramagazine.org/5tftw-2014-12-17/.
Fedora is a big project, and it’s hard to keep up with everything that goes on. This series highlights interesting happenings in five different areas every week. It isn’t comprehensive news coverage — just quick summaries with links to each. Here are the five things for December 17th, 2014:
Fedora 21 Retrospective: What was awesome? What wasn’t? -------------------------------------------------------
While Fedora 22 is already rolling into the target zone, we do want to make sure we look back at this previous cycle and identify things we can improve — ideally, specific and actionable changes. In the end, we came out with (another!) great release, but there is always something to learn. In particular, we ended _yet again_ in a last minute scramble to get a release we could feel good about signing off on out before the holidays, and next time around it would be nice to put less stress on all of our contributors (including the quality assurance team and the developers needed to make those late fixes.)
There will be more to it than this, but to get started, we have a F21 Retrospective wiki page, to help collect comments and ideas.
* https://fedoraproject.org/wiki/Fedora_21_Retrospective
Fedora 22: Coming up fast! --------------------------
FESCo (the Fedora Engineering Steering Committee, the elected organization which oversees technical decisions in the project) has indicated that we’re back to aiming for the traditional May/October Fedora release cycle, and although the F22 schedule isn’t finalized yet, we have a tentative plan calling for a release about 6 months from now. When you work back from that, it means that there’s really not much time to think about change proposals for F22, especially if we subtract out holiday time. So, if you’re thinking of working on something big, please start getting your proposal formalized — the tentative deadline is January 20th, 2015.
Fedora 19: End of Life ----------------------
And on the other end of the cycle: it’s time to say farewell to Fedora 19. If you’re running this release, please plan to update before January 6th, 2015, when the last updates will go out. After that, there will be no further security fixes. The good news is that Fedora 20 was a great release, and Fedora 21 is *even better*, and I think you’ll be happy with the upgrade.
* http://fedoramagazine.org/fedora-19-eol-01-06-2015/
Fedora Workstation firewall discussion --------------------------------------
This week’s big devel-list thread concerned the default firewall settings in Fedora Workstation. The Fedora Workstation Working Group was not happy with the user experience offered by blocking incoming “high ports” by default. Out of the box, nothing is listening on these, but if one installs software that expects to, it won’t work, and because we don’t have a good way yet to tie *attempts* to access ports to listening applications and communicate that to the user, the resulting failure is invisible.
On the other hand, if you install something and it starts listening and you didn’t know that, that’s *also* invisible. So, pretty much everyone recognizes this as a not ideal situation. Everyone involved in the discussion also is concerned with enhancing user security in practice — the question is just how to best get there from an imperfect state. Originally, the Workstation WG asked to disable the firewall entirely. FESCo asked instead that it be left available, possibly with a less-restrictive out-of-the-box configuration — the path taken for F21.
If you’re not running Workstation, this doesn’t affect you. If you are, and would like a different configuration, run the firewall configuration tool and either edit the Fedora Workstation zone or change the default zone. (There’s a long list of options, but “public” is a generally-restrictive choice.)
You can also change the per-network zone. Unfortunately currently wired networks are all considered as one per interface, but wireless networks are distinguished individually. This can be done in a number of ways, but the easiest is to run the network configuration tool (in GNOME control center — press the overview key and start typing “network”), select the wifi network in question, press the little gear icon next to it, go down to Identity (?!), and choose the appropriate firewall zone. (Again, there’s a long list — go back to the firewall config tool to see exactly what they all do.)
This is clearly, not the most friendly approach; it’s my understanding that the desktop designers, network tools team, and security team are going to work together to develop a better overall solution for Fedora 22 and beyond.
Overall, the mailing list thread stayed relatively positive and constructive and avoided personal attacks, although there were some accusations of bad faith actions which do not seem warranted based on the actual history. It is, however, a case where more transparent discussion and communication could have helped; that’s something we’re continually working at making better and might make for a good component of the F21 retrospective mentioned above.
* https://lists.fedoraproject.org/pipermail/devel/2014-December/205010.html
Christmas break ---------------
Of course things in Fedora never really stop, but it’s vacation time for many of us. Before I was a Red Hat employee, I was used to seeing extended days off as ideal for getting in some serious work on Fedora. Now, things are strangely inverted, and I’m going to use the time to unplug a bit. I’ll be back in January all recharged, and will catch up with everything that’s happened in the meantime — FtFTW will resume the week of January 15th — or possibly the week before, but let’s save the hard-to-keep resolutions for New Year’s Day. :)
Check out the Fedora vacation calendar to see who else will be away, and make sure to add yourself if you will be too. (There's even a Fedora badge for doing so!)
* https://apps.fedoraproject.org/calendar/vacation/ * https://badges.fedoraproject.org/badge/vacation
Hey Matt,
A few corrections for the portion about the workstation firewall.
----- Original Message ----- <snip>
Fedora Workstation firewall discussion
This week’s big devel-list thread concerned the default firewall settings in Fedora Workstation. The Fedora Workstation Working Group was not happy with the user experience offered by blocking incoming “high ports” by default. Out of the box, nothing is listening on these, but if one installs software that expects to,
"If one tries to use the already installed software"
it won’t work, and because we don’t have a good way yet to tie *attempts* to access ports to listening applications and communicate that to the user, the resulting failure is invisible.
Even if we could do that in a secure way, that's not the way we'd want to implement it.
On the other hand, if you install something and it starts listening and you didn’t know that,
If you install something from Fedora and it does that, then it's a bug in the application.
that’s *also* invisible. So, pretty much everyone recognizes this as a not ideal situation. Everyone involved in the discussion also is concerned with enhancing user security in practice — the question is just how to best get there from an imperfect state. Originally, the Workstation WG asked to disable the firewall entirely.
That wasn't the Workstation WG, it was earlier, for the Desktop spin.
FESCo asked instead that it be left available, possibly with a less-restrictive out-of-the-box configuration — the path taken for F21.
If you’re not running Workstation, this doesn’t affect you. If you are, and would like a different configuration, run the firewall configuration tool and either edit the Fedora Workstation zone or change the default zone. (There’s a long list of options, but “public” is a generally-restrictive choice.)
You can also change the per-network zone. Unfortunately currently wired networks are all considered as one per interface, but wireless networks are distinguished individually. This can be done in a number of ways, but the easiest is to run the network configuration tool (in GNOME control center — press the overview key and start typing “network”), select the wifi network in question, press the little gear icon next to it, go down to Identity (?!), and choose the appropriate firewall zone. (Again, there’s a long list — go back to the firewall config tool to see exactly what they all do.)
Thank you for pointing out the main reason why the zones can't ever be a user-facing concept ;)
This is clearly, not the most friendly approach; it’s my understanding that the desktop designers, network tools team, and security team are going to work together to develop a better overall solution for Fedora 22 and beyond.
This was supposed to be the "better overall solution" with the next steps coming from application sandboxing.
Overall, the mailing list thread stayed relatively positive and constructive and avoided personal attacks, although there were some accusations of bad faith actions which do not seem warranted based on the actual history.
That could translate as "It wasn't as bad as a systemd flamewar". That's not a very high standard to set though.
Hi,
On the other hand, if you install something and it starts listening and you didn’t know that,
If you install something from Fedora and it does that, then it's a bug in the application.
No. It's you solving your problem with gnome-user-share and declaring the fallout somebody elses problem so you can safely ignore it.
You can also change the per-network zone. Unfortunately currently wired networks are all considered as one per interface, but wireless networks are distinguished individually. This can be done in a number of ways, but the easiest is to run the network configuration tool (in GNOME control center — press the overview key and start typing “network”), select the wifi network in question, press the little gear icon next to it, go down to Identity (?!), and choose the appropriate firewall zone. (Again, there’s a long list — go back to the firewall config tool to see exactly what they all do.)
Thank you for pointing out the main reason why the zones can't ever be a user-facing concept ;)
The fact that the current GUI (and zone naming) sucks big time doesn't imply that the underlying concept is unusable. The big advantage of using firewall zones is that it works outside the gnome universe too.
(1) Pulling the qemu/kvm vnc server example again, which you decided to not respond to last time I mentioned it. I want the guests vnc display be reachable in my home networks and not reachable in public networks. Doing it with the firewall works.
(2) Heck, even the gnome-user-share UI shows that. Pick "Remote Login", notice that you can NOT select networks for sharing.
Yes, I know why you can't pick networks for ssh. But this IMO clearly shows that the "just don't listen on untrusted networks" as distro-wide policy isn't going to fly.
cheers, Gerd
----- Original Message -----
Hi,
On the other hand, if you install something and it starts listening and you didn’t know that,
If you install something from Fedora and it does that, then it's a bug in the application.
No. It's you solving your problem with gnome-user-share and declaring the fallout somebody elses problem so you can safely ignore it.
It's in the packaging guidelines that server applications shouldn't auto-start. It's not like I'm making this up...
You can also change the per-network zone. Unfortunately currently wired networks are all considered as one per interface, but wireless networks are distinguished individually. This can be done in a number of ways, but the easiest is to run the network configuration tool (in GNOME control center — press the overview key and start typing “network”), select the wifi network in question, press the little gear icon next to it, go down to Identity (?!), and choose the appropriate firewall zone. (Again, there’s a long list — go back to the firewall config tool to see exactly what they all do.)
Thank you for pointing out the main reason why the zones can't ever be a user-facing concept ;)
The fact that the current GUI (and zone naming) sucks big time doesn't imply that the underlying concept is unusable. The big advantage of using firewall zones is that it works outside the gnome universe too.
(1) Pulling the qemu/kvm vnc server example again, which you decided to not respond to last time I mentioned it.
I'm so sorry for missing one line in the 200+ emails from the thread. The firewall is still there. You can still use it. Which is better than what happens in F20 and before: 1a) developers disable the firewall because they have better things to do 1b) they switch distributions (when possible) because they have better things to do 2) they can't apply firewall rules to the VMs because the firewall is disabled
I want the guests vnc display be reachable in my home networks and not reachable in public networks. Doing it with the firewall works.
You found a use for the firewall that's still running.
(2) Heck, even the gnome-user-share UI shows that. Pick "Remote Login", notice that you can NOT select networks for sharing.
This isn't gnome-user-share. It's the sharing panel in the control-center. And it's not there because I wasn't sure whether changing the status quo for this was 1) necessary 2) how to implement it without breaking the setup for administrators if the user can choose to enable/disable the SSH server themselves.
I don't see how keeping the status quo for one (system-wide) service necessarily invalidates the design decisions done for all the other (user-wide) services.
Yes, I know why you can't pick networks for ssh. But this IMO clearly shows that the "just don't listen on untrusted networks" as distro-wide policy isn't going to fly.
I'll implement that if it's all it takes for you to admit that, yes, it's actually going to fly.
Am 18.12.2014 um 16:43 schrieb Bastien Nocera:
On the other hand, if you install something and it starts listening and you didn’t know that,
If you install something from Fedora and it does that, then it's a bug in the application.
No. It's you solving your problem with gnome-user-share and declaring the fallout somebody elses problem so you can safely ignore it.
It's in the packaging guidelines that server applications shouldn't auto-start. It's not like I'm making this up...
you still don't get it:
a operating system is *not only* for running software out of the distributions repos and hence it has to have secure defaults in *any* case and *even if* there is a package with a bug *the whole purpose* of a firewall is to *protect* against bugs
On Do, 2014-12-18 at 10:43 -0500, Bastien Nocera wrote:
----- Original Message -----
Hi,
On the other hand, if you install something and it starts listening and you didn’t know that,
If you install something from Fedora and it does that, then it's a bug in the application.
No. It's you solving your problem with gnome-user-share and declaring the fallout somebody elses problem so you can safely ignore it.
It's in the packaging guidelines that server applications shouldn't auto-start. It's not like I'm making this up...
(a) Bugs happen. (b) There are third party repos. (c) I might want use+enable the server apps and still have them reachable in trusted networks only.
I want the guests vnc display be reachable in my home networks and not reachable in public networks. Doing it with the firewall works.
You found a use for the firewall that's still running.
Yea, right.
And exactly that's why I think firewall setup should be alot simpler than it is now. Less zones, better names for them, ability to set them per network without digging deep into the network config tool.
Problem is gnome takes the opposite direction: Hide the firewall.
(2) Heck, even the gnome-user-share UI shows that. Pick "Remote Login", notice that you can NOT select networks for sharing.
This isn't gnome-user-share. It's the sharing panel in the control-center. And it's not there because I wasn't sure whether changing the status quo for this was
- necessary 2) how to implement it without breaking the setup for administrators if
the user can choose to enable/disable the SSH server themselves.
I'd suggest to simply use the firewall. Do you seriously consider to automatically start/stop ssh as the machine switches networks? What if the machine has two active network interfaces with different trust levels.
I don't see how keeping the status quo for one (system-wide) service necessarily invalidates the design decisions done for all the other (user-wide) services.
I've picked just one example. There are alot more system wide services which are facing the very same problem. mdns & cups are typical for desktops. Developer workstations might run a git server, also all sorts of server services (http, sql, gluster, ...) for testing purposes. The qemu example goes into that category too.
Yes, I know why you can't pick networks for ssh. But this IMO clearly shows that the "just don't listen on untrusted networks" as distro-wide policy isn't going to fly.
I'll implement that if it's all it takes for you to admit that, yes, it's actually going to fly.
Yes, I'd like to see a reasonable approach for system services. IMHO that approach is "use the firewall", but you don't wanna go that route.
So, what else can be done when the user switches networks?
(a) start/stop services. Has the disadvantage that they stop listening on the loopback device too, and for some (qemu for example) it isn't a reasonable thing to do. (b) reconfigure services. Have fun implementing that for all the server services fedora has. (c) teach all those services to listen on dbus & reconfigure themselves. Have fun implementing that for all the server services fedora has. (d) run those services in a sandbox, reconfigure the sandbox. Yea, might work (don't know enough about sandboxes to say for sure). (e) something else?
cheers, Gerd
Il 17/12/2014 20:38, Matthew Miller ha scritto:
This is clearly, not the most friendly approach; it’s my understanding that the desktop designers, network tools team, and security team are going to work together to develop a better overall solution for Fedora 22 and beyond.
Maybe I put it too simple, but instead of opening all high ports by default what about having firewall rules declared in RPMs for packages that need to have ports opened? I mean, creating a script in the %post section of the specfile where the packager can tell firewalld to open up one or more ports. I know it's not perfect, because this solution covers only packages that come from official repositories, but this can be a start.
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.
On Sat, 2014-12-20 at 17:51 +0100, Mattia Verga wrote:
Maybe I put it too simple, but instead of opening all high ports by default what about having firewall rules declared in RPMs for packages that need to have ports opened?
Because we need to support applications that use random ports.
Am 20.12.2014 um 22:19 schrieb Michael Catanzaro:
On Sat, 2014-12-20 at 17:51 +0100, Mattia Verga wrote:
Maybe I put it too simple, but instead of opening all high ports by default what about having firewall rules declared in RPMs for packages that need to have ports opened?
Because we need to support applications that use random ports
first: you should not quote only parts and stop reading premature
what about first try to fix that applications instead burry the default firewall to make them happy - since networking is my daily job i see no single reason to design a *server* for listen on random ports and there is really no single reason to make security decisions based on *one* desktop and it's shipped applications ______________________________________
you completly ignored the following paragraph, my guess is because "ask the user" is considered harmful by GNOME upstream
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.
On Sat, 2014-12-20 at 22:24 +0100, Reindl Harald wrote:
you completly ignored the following paragraph, my guess is because "ask the user" is considered harmful by GNOME upstream
Well I read it, but yes, I do think that ask the user is harmful. We need to get out of the business of training users to click through security prompts. You and I will have to agree to disagree on this.
Am 20.12.2014 um 23:32 schrieb Michael Catanzaro:
On Sat, 2014-12-20 at 22:24 +0100, Reindl Harald wrote:
you completly ignored the following paragraph, my guess is because "ask the user" is considered harmful by GNOME upstream
Well I read it, but yes, I do think that ask the user is harmful. We need to get out of the business of training users to click through security prompts. You and I will have to agree to disagree on this
how can not ask the user and open things anyways not be *much more harmful* - that's completly illogical
instead of rely on a users action do the harm as default don't make things better and it's simply impossible to have complex computer systems working magical secure and maintaince free out of the box
Il 20/12/2014 23:32, Michael Catanzaro ha scritto:
On Sat, 2014-12-20 at 22:24 +0100, Reindl Harald wrote:
you completly ignored the following paragraph, my guess is because "ask the user" is considered harmful by GNOME upstream
Well I read it, but yes, I do think that ask the user is harmful. We need to get out of the business of training users to click through security prompts. You and I will have to agree to disagree on this.
Well, at work I use Windows 7 and when I have to set up a FTP server I must open the firewall settings and manually set it to allow incoming connections to the program (not to FTP port, so the program can open up all ports it wants). That's really much more complex than clicking a security prompt.
If the problem is file sharing, and specifically gnome-user-share, I think firewalld can inlude a "trusted app" list: if a user enables file sharing he's aware of doing that, so there's no need that firewalld asks him again if it's ok for gnome-user-share to open any port. This is also the way how Windows 7 works for file sharing, with three security levels for this trusted app list in case you're on a public network or home or at work.
Since I'm not good to write complex sentences in English, here is a schema that explains how I think firewalld should work as I wrote in the previous post.
Mattia Verga wrote:
Since I'm not good to write complex sentences in English, here is a schema that explains how I think firewalld should work as I wrote in the previous post.
A "trusted app" to me would mean that I trust that it's secure enough to communicate even on *untrusted* networks. I don't usually trust any network, but in the rare cases when I do, I'll let any bug-ridden junk communicate because I'm confident that there isn't anything on the network that will exploit any security holes. If Gnome-user-share (your example) can't be trusted on untrusted networks, then including it in a "trusted app list" seems very wrong. Since you didn't even give the user an option to allow Gnome-user-share to communicate on the untrusted network, your list seems more ĺike a list of known defective apps.
On 21 December 2014 at 09:45, Björn Persson <Bjorn@rombobjörn.se> wrote:
Mattia Verga wrote:
Since I'm not good to write complex sentences in English, here is a schema that explains how I think firewalld should work as I wrote in the previous post.
A "trusted app" to me would mean that I trust that it's secure enough to communicate even on *untrusted* networks. I don't usually trust any
That is personal semantics versus actual semantics. You define "trusted" as X, someone defines it as Y. They may or may not overlap which causes all kinds of arguments over words versus actual usage.
What Mattia is saying is that you set levels of trust for programs or acceptance (again another overloaded word that will causes arguments over definitions).
Program A is 'accepted' or 'trusted' or 'fill in your word here' to work on network A without intervention. If the system is not on that network then before Program A can have a port open, it needs the user to determine whether or not that is allowed. Program B is not 'accepted' in any white list and so the user needs to be notified.
I think in the end a firstboot or anaconda module on user security settings should be put in. In places where the environment is preset up, it can be turned off easily in kickstart or a boot time flag.
User A wants to be notified of all programs opening ports even if he is going to whitelist them. User B does not want to be notified and could care less about security. etc.
network, but in the rare cases when I do, I'll let any bug-ridden junk communicate because I'm confident that there isn't anything on the network that will exploit any security holes. If Gnome-user-share (your example) can't be trusted on untrusted networks, then including it in a "trusted app list" seems very wrong. Since you didn't even give the user an option to allow Gnome-user-share to communicate on the untrusted network, your list seems more ĺike a list of known defective apps.
-- 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 John Smoogen wrote:
User A wants to be notified of all programs opening ports even if he is going to whitelist them. User B does not want to be notified and could care less about security. etc.
User C does not want to be notified either, but just wants everything blocked silently.
Kevin Kofler
On Mon, 2014-12-22 at 23:24 +0100, Kevin Kofler wrote:
Stephen John Smoogen wrote:
User A wants to be notified of all programs opening ports even if he is going to whitelist them. User B does not want to be notified and could care less about security. etc.
User C does not want to be notified either, but just wants everything blocked silently.
I doubt that User C *as described* exists. I suspect you meant "User C does not want an interactive notification. They want things to be blocked and logged appropriately, so that if things are not behaving as expected, they can find out why and what they would need to change to get it working again".
I'd argue that something similar to the SELinux Troubleshooter would be a useful solution here, if interfaces could be added to support it.
Stephen Gallagher wrote:
I doubt that User C *as described* exists. I suspect you meant "User C does not want an interactive notification. They want things to be blocked and logged appropriately, so that if things are not behaving as expected, they can find out why and what they would need to change to get it working again".
I'd argue that something similar to the SELinux Troubleshooter would be a useful solution here, if interfaces could be added to support it.
I am user C. I don't need a log of blocked stuff, I'd only be worried about intruders DoSing the machine by filling the log. I really want ANY outside access to my machine silently dropped. My machine is NOT a server, period.
Kevin Kofler
Kevin Kofler wrote:
I am user C. I don't need a log of blocked stuff, I'd only be worried about intruders DoSing the machine by filling the log. I really want ANY outside access to my machine silently dropped. My machine is NOT a server, period.
So you never use Bittorrent to download a new Fedora release, or any other kind of filesharing? You never use a softphone, or play multi-user games? Any kind of text chat you might use is a centralized service, not peer-to-peer? And you're sure that you will never use Tor, or Bitcoin, or any other kind of peer-to-peer communication that may be invented in the future?
It may be a valid use case, but the option would need to be clearly labeled so that users understand how much they're blocking. Otherwise people will choose it because they aren't setting up a web server, and then wonder why their networked game isn't working. Something like this:
"This is a special-purpose client machine. It will never engage in any kind of peer-to-peer communication, nor run any kind of server. And yes, I know what those terms mean."
Even then, I still think it would be better if programs that try to open a port would get an error code and have a chance to report the failure, rather than waiting in vain for requests that are being silently dropped.
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?
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.
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 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?
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 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.
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).
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
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 John Smoogen wrote:
- 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.
- 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.
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.
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
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 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
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
----- 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.
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.
----- 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@lists.stg.fedoraproject.org
-
Bastien Nocera -
Björn Persson -
drago01 -
Florian Weimer -
Gerd Hoffmann -
Kevin Kofler -
Matthew Miller -
Mattia Verga -
Michael Catanzaro -
Petr Spacek -
Rahul Sundaram -
Reindl Harald -
Stephen Gallagher -
Stephen John Smoogen