Nicely aligning with the current firewall thread I noticed that one of my machines was running the exim MTA for the last few days, dutifully listening on all interfaces.
How did this happen? It turns out that smartmontools intermittently required 'MTA' which (presumably due to its nice and short name) pulls in exim when there's no MTA already installed. This dependency was replaced (with a file dep on %{_sbindir}/sendmail) in smartmontools-6.2-5.fc20.
Ok, that's how it got installed. But why does it get run? Is the installation of exim tricking my system into believing it's Debian?
We do have the presets functionality[0] for this, I thought. And indeed, a call to systemctl preset disables exim.service just like it's supposed to do.
Looking at exim's spec file shows its %post is using the proper systemd_post macro which honors presets. In %postun, though, there's a direct call to systemctl enable, buried in the sysv conversion stuff. Is it really supposed to be there? But this shouldn't get executed on package install anyway, right?
Would be glad if someone who knows a bit more about the interaction of RPM and systemd preset files could chime in and tell me where the bug report should go.
Lars
On Sun, Apr 20, 2014 at 6:39 PM, Lars Seipel lars.seipel@gmail.com wrote:
Nicely aligning with the current firewall thread I noticed that one of my machines was running the exim MTA for the last few days, dutifully listening on all interfaces.
How did this happen? It turns out that smartmontools intermittently required 'MTA' which (presumably due to its nice and short name) pulls in exim when there's no MTA already installed. This dependency was replaced (with a file dep on %{_sbindir}/sendmail) in smartmontools-6.2-5.fc20.
Ok, that's how it got installed. But why does it get run? Is the installation of exim tricking my system into believing it's Debian?
We do have the presets functionality[0] for this, I thought. And indeed, a call to systemctl preset disables exim.service just like it's supposed to do.
Looking at exim's spec file shows its %post is using the proper systemd_post macro which honors presets. In %postun, though, there's a direct call to systemctl enable, buried in the sysv conversion stuff. Is it really supposed to be there? But this shouldn't get executed on package install anyway, right?
Would be glad if someone who knows a bit more about the interaction of RPM and systemd preset files could chime in and tell me where the bug report should go.
I think it's because upgrading installs a new package and uninstalls an old package. Sounds like a bug in exim.
So far, I know that this issue exists, in some form, in rpcbind, nfs-utils, and exim. Would it make sense to audit all spec files to look for instances of 'systemctl.*enable'? If so, is there an easy way to grab all the spec files? Scraping pkgs.fedoraproject.org is a bit painful.
--Andy
On Sun, Apr 20, 2014 at 06:44:53PM -0700, Andrew Lutomirski wrote:
I think it's because upgrading installs a new package and uninstalls an old package. Sounds like a bug in exim.
Yes, but there was no upgrade of exim. An update of smartmontools pulled it in but exim itself got installed for the first time.
Lars
Hi
On Sun, Apr 20, 2014 at 10:41 PM, Lars Seipel <wrote:
On Sun, Apr 20, 2014 at 06:44:53PM -0700, Andrew Lutomirski wrote:
I think it's because upgrading installs a new package and uninstalls an old package. Sounds like a bug in exim.
Yes, but there was no upgrade of exim. An update of smartmontools pulled it in but exim itself got installed for the first time.
Exim getting installed isn't a bug but getting enabled by default is. You should file it and similar issues in other packages if any as well
Rahul
On 04/21/2014 03:44 AM, Andrew Lutomirski wrote:
Would it make sense to audit all spec files to look for instances of 'systemctl.*enable'?
I'm attaching the hits for that pattern on the actual RPM scripts in Fedora rawhide (x86_64). This combines both regular scripts and trigger scripts. I can add additional columns with more information, but the text file will become a bit unwieldy.
On Mon, Apr 21, 2014 at 12:17 AM, Florian Weimer fweimer@redhat.com wrote:
On 04/21/2014 03:44 AM, Andrew Lutomirski wrote:
Would it make sense to audit all spec files to look for instances of 'systemctl.*enable'?
I'm attaching the hits for that pattern on the actual RPM scripts in Fedora rawhide (x86_64). This combines both regular scripts and trigger scripts. I can add additional columns with more information, but the text file will become a bit unwieldy.
Time to file a bunch of bugs? I can do it, but if someone has scripts, that could help.
Are there any currently supported upgrade paths from sysv to systemd for any of these services? If F19 already had all of these, then it may make sense to just remove the migration code.
--Andy
On Tue, 22 Apr 2014 10:33:12 -0700 Andrew Lutomirski luto@mit.edu wrote:
On Mon, Apr 21, 2014 at 12:17 AM, Florian Weimer fweimer@redhat.com wrote:
On 04/21/2014 03:44 AM, Andrew Lutomirski wrote:
Would it make sense to audit all spec files to look for instances of 'systemctl.*enable'?
I'm attaching the hits for that pattern on the actual RPM scripts in Fedora rawhide (x86_64). This combines both regular scripts and trigger scripts. I can add additional columns with more information, but the text file will become a bit unwieldy.
Time to file a bunch of bugs? I can do it, but if someone has scripts, that could help.
Please please please see: https://fedoraproject.org/wiki/Mass_bug_filing before you go filing any bugs.
kevin
On Mon, Apr 21, 2014 at 12:17 AM, Florian Weimer fweimer@redhat.com wrote:
On 04/21/2014 03:44 AM, Andrew Lutomirski wrote:
Would it make sense to audit all spec files to look for instances of 'systemctl.*enable'?
I'm attaching the hits for that pattern on the actual RPM scripts in Fedora rawhide (x86_64). This combines both regular scripts and trigger scripts. I can add additional columns with more information, but the text file will become a bit unwieldy.
Can you double-check this? nfs-utils isn't in this list, but I think it should be.
Also, how did you generate this?
Thanks, Andy
On 04/24/2014 01:57 AM, Andrew Lutomirski wrote:
On Mon, Apr 21, 2014 at 12:17 AM, Florian Weimer fweimer@redhat.com wrote:
On 04/21/2014 03:44 AM, Andrew Lutomirski wrote:
Would it make sense to audit all spec files to look for instances of 'systemctl.*enable'?
I'm attaching the hits for that pattern on the actual RPM scripts in Fedora rawhide (x86_64). This combines both regular scripts and trigger scripts. I can add additional columns with more information, but the text file will become a bit unwieldy.
Can you double-check this? nfs-utils isn't in this list, but I think it should be.
I accidentally used systemd.*enable as the pattern. The attached list was created using systemctl[^\n]*enable instead.
Also, how did you generate this?
I've got a tool which extracts interesting data from RPMs (metadata, but also Java method references, ELF symbols, Python imports). I've added the query I used as an example here:
https://github.com/fweimer/symboldb/blob/master/doc/examples/rpm-scripts.txt
On Thu, Apr 24, 2014 at 2:00 AM, Florian Weimer fweimer@redhat.com wrote:
On 04/24/2014 01:57 AM, Andrew Lutomirski wrote:
On Mon, Apr 21, 2014 at 12:17 AM, Florian Weimer fweimer@redhat.com wrote:
On 04/21/2014 03:44 AM, Andrew Lutomirski wrote:
Would it make sense to audit all spec files to look for instances of 'systemctl.*enable'?
I'm attaching the hits for that pattern on the actual RPM scripts in Fedora rawhide (x86_64). This combines both regular scripts and trigger scripts. I can add additional columns with more information, but the text file will become a bit unwieldy.
Can you double-check this? nfs-utils isn't in this list, but I think it should be.
I accidentally used systemd.*enable as the pattern. The attached list was created using systemctl[^\n]*enable instead.
Also, how did you generate this?
I've got a tool which extracts interesting data from RPMs (metadata, but also Java method references, ELF symbols, Python imports). I've added the query I used as an example here:
https://github.com/fweimer/symboldb/blob/master/doc/examples/rpm-scripts.txt
Want to help with further analysis? Setting up symboldb looks like a lot of work.
The issues so are are:
1. It turns out that a lot of the %triggerun things are okay -- they only run on upgrade from very old package versions. But postinstall is a problem, e.g. nfs-utils 2. I think you have data from RPMs that are retired, e.g. yum-cron. 3. The exim issue was caused by the --initscript option to alternatives. It would probably make sense to remove that option entirely, but it could also be good to find and fix everything that uses it.
--Andy
Am 21.04.2014 03:39, schrieb Lars Seipel:
Nicely aligning with the current firewall thread I noticed that one of my machines was running the exim MTA for the last few days, dutifully listening on all interfaces
and now it is *proven for sure* that disable the firewall by default is the most dumb thing a distribution can do
drago01 will now say again "that is a bug" yes, in that case in *two* packages at the same time but hwat matters is the impact of a bug
* smartmontools wanted sendmail instead MTA for sending sysmessages * sendmail obviously has a braindead default configuration listening on all ports * sendmail service is obviously enabled at install time even if smartmontools only need /usr/sbin/sendmail
all things i said that they are happening and will happen again and again while they get fixed here and there - again and again - that's life
so you can run in circles and shout "that is a bug" which is true and while you are fix it it brings people in trouble or you have by default a security layer which hopefully does not open port 25 automated because you install sendmail
the next problem: even if such a bug is fixed the affected users keep to be fucked because the updated smartmontools only require any MTA (which is correct) and so nothing will remove sendmail on that machines nor close port 25 after a update of smartmontools
https://koji.fedoraproject.org/koji/buildinfo?buildID=511458 * Thu Apr 17 2014 Michal Hlavinka mhlavink@redhat.com - 1:6.2-5 - require /usr/sbin/sendmail as MTA is not provided by all packages (#1048618) * Tue Apr 15 2014 Michal Hlavinka mhlavink@redhat.com - 1:6.2-4 - use MTA instead of sendmail as a requirement (#1048614) * Thu Apr 10 2014 Michal Hlavinka mhlavink@redhat.com - 1:6.2-3 - add mail requires (#1048614)
On Mon, Apr 21, 2014 at 3:42 AM, Reindl Harald h.reindl@thelounge.net wrote:
Am 21.04.2014 03:39, schrieb Lars Seipel:
Nicely aligning with the current firewall thread I noticed that one of my machines was running the exim MTA for the last few days, dutifully listening on all interfaces
and now it is *proven for sure* that disable the firewall by default is the most dumb thing a distribution can do
drago01 will now say again "that is a bug" yes, in that case in *two* packages at the same time but hwat matters is the impact of a bug
- smartmontools wanted sendmail instead MTA for sending sysmessages
- sendmail obviously has a braindead default configuration listening on all ports
- sendmail service is obviously enabled at install time even if smartmontools only need /usr/sbin/sendmail
all things i said that they are happening and will happen again and again while they get fixed here and there - again and again - that's life
so you can run in circles and shout "that is a bug" which is true and while you are fix it it brings people in trouble or you have by default a security layer which hopefully does not open port 25 automated because you install sendmail
the next problem: even if such a bug is fixed the affected users keep to be fucked because the updated smartmontools only require any MTA (which is correct) and so nothing will remove sendmail on that machines nor close port 25 after a update of smartmontools
If all smartmontools need is to just send emails out, I would suggest using something like ssmtp or msmtp.
https://koji.fedoraproject.org/koji/buildinfo?buildID=511458
- Thu Apr 17 2014 Michal Hlavinka mhlavink@redhat.com
- 1:6.2-5 - require /usr/sbin/sendmail as MTA is not provided by all packages (#1048618)
- Tue Apr 15 2014 Michal Hlavinka mhlavink@redhat.com
- 1:6.2-4 - use MTA instead of sendmail as a requirement (#1048614)
- Thu Apr 10 2014 Michal Hlavinka mhlavink@redhat.com - 1:6.2-3
- add mail requires (#1048614)
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Am 21.04.2014 12:58, schrieb Mauricio Tavares:
On Mon, Apr 21, 2014 at 3:42 AM, Reindl Harald h.reindl@thelounge.net wrote:
Am 21.04.2014 03:39, schrieb Lars Seipel:
Nicely aligning with the current firewall thread I noticed that one of my machines was running the exim MTA for the last few days, dutifully listening on all interfaces
and now it is *proven for sure* that disable the firewall by default is the most dumb thing a distribution can do
drago01 will now say again "that is a bug" yes, in that case in *two* packages at the same time but hwat matters is the impact of a bug
- smartmontools wanted sendmail instead MTA for sending sysmessages
- sendmail obviously has a braindead default configuration listening on all ports
- sendmail service is obviously enabled at install time even if smartmontools only need /usr/sbin/sendmail
all things i said that they are happening and will happen again and again while they get fixed here and there - again and again - that's life
so you can run in circles and shout "that is a bug" which is true and while you are fix it it brings people in trouble or you have by default a security layer which hopefully does not open port 25 automated because you install sendmail
the next problem: even if such a bug is fixed the affected users keep to be fucked because the updated smartmontools only require any MTA (which is correct) and so nothing will remove sendmail on that machines nor close port 25 after a update of smartmontools
If all smartmontools need is to just send emails out, I would suggest using something like ssmtp or msmtp
which needs configuration local mail-pickup don't
and no i am not interested in discussions who reads that mails serious users / admins do after they realized existence and after that also the mails from the past
but you missed the point: because such things can happen a OS must not be shipped with a disabled firewall these days - period
On Mon, Apr 21, 2014 at 06:58:56AM -0400, Mauricio Tavares wrote:
If all smartmontools need is to just send emails out, I would
suggest using something like ssmtp or msmtp.
/usr/sbin/sendmail is handled with alternatives and can be provided by e.g. ssmtp. Smartmontools was changed for exactly this reason.
On Mon, 2014-04-21 at 09:42 +0200, Reindl Harald wrote:
Am 21.04.2014 03:39, schrieb Lars Seipel:
Nicely aligning with the current firewall thread I noticed that one of my machines was running the exim MTA for the last few days, dutifully listening on all interfaces
and now it is *proven for sure* that disable the firewall by default is the most dumb thing a distribution can do
This doesn't make much sense to me.
Take a look at the wording of the proposed change: "The current level of integration into the desktop and applications does not justify enabling the firewalld service by default."
Now imagine the situation if we take the opposite approach — we *fix* the integration, and leave it enabled by default.
Fixing the integration means that installing packages which need to listen on a network socket should Just Work™. That means they'll talk to firewalld somehow, to enable their ports.
We need that, because from a usability point of view it just isn't acceptable to have things which *appear* to work when you test them from localhost, but silently fail when you connect from the outside. That's a really insidious failure mode which has bitten me a number of times when I've forgotten to turn off the misguided firewall on a newly-installed machine.
So when it's all finished and working properly, the firewall doesn't really buy you anything in this case. A package which is set up to listen by default will still do that, and it'll still be a bug in the package in question.
Actually, I think the best way to fix this is with SELinux, rather than iptables. Why go for an overly complex solution where authorised processes have to prod a firewall dæmon to change the iptables configuration, when the kernel has a perfectly good "firewall" built in as a fundamental part of the IP stack? Send a TCP SYN to a port which nobody's listening on, and you'll get a TCP RST back. Send a UDP packet to closed port, and you'll get an ICMP 'port unreachable' back. No need for iptables at all. All you need to do, if you really want to control incoming connections, is use SELinux to limit who can bind() and listen() to certain ports. And that approach has the advantage that you can make sure it's the *right* program listening. You can make sure that only the MTA is listening on port 25 and not anything else, for example.
Perhaps we'd end up with an SELinux boolean which enables incoming connections on port 25 — which could be disabled by default and which *would* protect you from packages listening by default when we really didn't want them to. And the failure mode would be clear and simple, as the listen() call fails and the dæmon would *know* that it's not working. The reporting for that is already hooked up to the user interface, and it would be really simple for the user/admin to use 'setsebool' to enable it when necessary. We'd stick a comment to that effect in the default config file by the 'local_interfaces' option, of course.
Am 28.04.2014 12:42, schrieb David Woodhouse:
On Mon, 2014-04-21 at 09:42 +0200, Reindl Harald wrote:
Am 21.04.2014 03:39, schrieb Lars Seipel:
Nicely aligning with the current firewall thread I noticed that one of my machines was running the exim MTA for the last few days, dutifully listening on all interfaces
and now it is *proven for sure* that disable the firewall by default is the most dumb thing a distribution can do
This doesn't make much sense to me
what exactly?
that open port 25 by a package error on the WAN is critical? that open whatever port by a package error on the WAN is critical?
Take a look at the wording of the proposed change: "The current level of integration into the desktop and applications does not justify enabling the firewalld service by default."
i know that wording
Now imagine the situation if we take the opposite approach — we *fix* the integration, and leave it enabled by default.
yes
Fixing the integration means that installing packages which need to listen on a network socket should Just Work™. That means they'll talk to firewalld somehow, to enable their ports.
yes but not *all ports* and not uncomprehensive at all
you really don't want to open SMB on the WAN because you want to share a folder
We need that, because from a usability point of view it just isn't acceptable to have things which *appear* to work when you test them from localhost, but silently fail when you connect from the outside. That's a really insidious failure mode which has bitten me a number of times when I've forgotten to turn off the misguided firewall on a newly-installed machine.
the user needs a way to decide where the port should be open
* local network * wan * only localhost
So when it's all finished and working properly, the firewall doesn't really buy you anything in this case. A package which is set up to listen by default will still do that, and it'll still be a bug in the package in question.
*no not on the WAN*
what you really refuse to understand is the implication of disable the firewall at all - frankly in the early KDE4 days there where ports from KDE applications listening on 0.0.0.0 which where for sure never intended to be reachable from the internet - yes that was all bugs
but realize that we can't pretend to live in a bugfree world
that would mean these ports below would be open to the internet - that's just ZendStudio (not a fedora package) where due start it tries to check if there is already a instance running on another computer with the same serial, not you nor i have to justify that, that's real life as it is
if you don't care about such cases stop to pretend you are building an operating system - on an operating system there is a world outside the distributions repos
[root@rh:~]$ netstat -l | grep java tcp 0 0 0.0.0.0:10137 0.0.0.0:* LISTEN 15717/java tcp 0 0 0.0.0.0:9000 0.0.0.0:* LISTEN 15717/java tcp 0 0 0.0.0.0:20080 0.0.0.0:* LISTEN 15717/java udp 0 0 0.0.0.0:4321 0.0.0.0:* 15717/java
You can make sure that only the MTA is listening on port 25 and not anything else
and even if - have a MTA reachable on the WAN after installing it before you have configured it for proudction use if you even intend to do that is the most possible dumb thing
that said from a professional mailserver admin!
2014-04-28 12:42 GMT+02:00 David Woodhouse dwmw2@infradead.org:
On Mon, 2014-04-21 at 09:42 +0200, Reindl Harald wrote:
Am 21.04.2014 03:39, schrieb Lars Seipel:
Nicely aligning with the current firewall thread I noticed that one of my machines was running the exim MTA for the last few days, dutifully listening on all interfaces
and now it is *proven for sure* that disable the firewall by default is the most dumb thing a distribution can do
This doesn't make much sense to me.
Take a look at the wording of the proposed change: "The current level of integration into the desktop and applications does not justify enabling the firewalld service by default."
Now imagine the situation if we take the opposite approach — we *fix* the integration, and leave it enabled by default.
Fixing the integration means that installing packages which need to listen on a network socket should Just Work™. That means they'll talk to firewalld somehow, to enable their ports.
No no no no no. If you want a firewall "integrated" *that* way, you are really better of uninstalling it or opening it up; it serves no purpose.
(Which is why I think opening up the firewall on Workstation might have been the right thing to do; it was the other parts of the proposal to the effect of "we'll make it secure later" that were a non-starter.)
Actually, I think the best way to fix this is with SELinux, rather than
iptables. Why go for an overly complex solution where authorised processes have to prod a firewall dæmon to change the iptables configuration, when the kernel has a perfectly good "firewall" built in as a fundamental part of the IP stack?
More generally, an application- instead of port-based firewall configuration might be interesting (aside from protecting "ownership" of some well-known ports I suppose). But that needs having a security-relevant *concept* of an application, something we don't have on the desktop with everything running as unconfined_t and ptrace() allowed, and something we... sort of have but not enough, with PHP scripts running in-process in the same domain as the main http server. Mirek
Am 28.04.2014 18:52, schrieb Miloslav Trmač:
2014-04-28 12:42 GMT+02:00 David Woodhouse <dwmw2@infradead.org mailto:dwmw2@infradead.org>:
On Mon, 2014-04-21 at 09:42 +0200, Reindl Harald wrote: > Am 21.04.2014 03:39, schrieb Lars Seipel: > > Nicely aligning with the current firewall thread I noticed that one of > > my machines was running the exim MTA for the last few days, dutifully > > listening on all interfaces > > and now it is *proven for sure* that disable the firewall > by default is the most dumb thing a distribution can do This doesn't make much sense to me. Take a look at the wording of the proposed change: "The current level of integration into the desktop and applications does not justify enabling the firewalld service by default." Now imagine the situation if we take the opposite approach — we *fix* the integration, and leave it enabled by default. Fixing the integration means that installing packages which need to listen on a network socket should Just Work™. That means they'll talk to firewalld somehow, to enable their ports.
No no no no no. If you want a firewall "integrated" /that/ way, you are really better of uninstalling it or opening it up; it serves no purpose.
no, even if that way is completly wrong it's better than no firewall as i have explained multiple times there may run software not from the Fedora repos which opens ports unintentionally from the users point of view and especially a user with no network expierience will not realize that - and yes that software matters because we are talking about a *operating system*
the next thing is when it comes to malware opening ports there are two types of malware:
* privilege escalation (you have lost) * crap try to open a unprivileged port with user permissions
the second one has to be stopped and please don't come with "that could be stopped with SElinux" -> layered security
you need to tealize security as a big picture with as much defense layers as possible and whoever thinks "no, this and that leayer is not needed because we have A, B, C" has no clue about security at all and nothing learned in the last few years from things which happened in the wild
2014-04-28 18:59 GMT+02:00 Reindl Harald h.reindl@thelounge.net:
Am 28.04.2014 18:52, schrieb Miloslav Trmač:
No no no no no. If you want a firewall "integrated" /that/ way, you are
really
better of uninstalling it or opening it up; it serves no purpose.
no, even if that way is completly wrong it's better than no firewall as i have explained multiple times there may run software not from the Fedora repos which opens ports unintentionally from the users point of view and especially a user with no network expierience will not realize that - and yes that software matters because we are talking about a *operating system*
Well if the users' expectations were that the firewall doesn't "interfere" with Fedora applications, why would they expect it to "interfere" with non-Fedora applications?
the next thing is when it comes to malware opening ports
there are two types of malware:
- privilege escalation (you have lost)
- crap try to open a unprivileged port with user permissions
The second case is a subset of the first one anyway :)
And doesn't every malware know to make an _outgoing_ connection to an IRC server nowadays? Stopping malware by blocking incoming connections is fairly illusory IMHO. Mire
Am 28.04.2014 19:04, schrieb Miloslav Trmač:
2014-04-28 18:59 GMT+02:00 Reindl Harald <h.reindl@thelounge.net mailto:h.reindl@thelounge.net>:
Am 28.04.2014 18:52, schrieb Miloslav Trmač: > No no no no no. If you want a firewall "integrated" /that/ way, you are really > better of uninstalling it or opening it up; it serves no purpose. no, even if that way is completly wrong it's better than no firewall as i have explained multiple times there may run software not from the Fedora repos which opens ports unintentionally from the users point of view and especially a user with no network expierience will not realize that - and yes that software matters because we are talking about a *operating system*
Well if the users' expectations were that the firewall doesn't "interfere" with Fedora applications, why would they expect it to "interfere" with non-Fedora applications?
do i really need to explain that?
you can make signed fedora packages trusted and allow them at install or first start to interact with firewalld
you can't do that for http://www.zend.com/de/products/studio/downloads you can't also explain zend they should not open ports with a IDE you can't do the same for any other software manufacturer you can#t do that even Fedora, see the thread-start for the sake of god
security don't work the way what people should do security works the way "what could people do wrong"
the next thing is when it comes to malware opening ports there are two types of malware: * privilege escalation (you have lost) * crap try to open a unprivileged port with user permissions
The second case is a subset of the first one anyway :)
no - privilege escalation is meant as get root permissions
And doesn't every malware know to make an _outgoing_ connection to an IRC server nowadays? Stopping malware by blocking incoming connections is fairly illusory IMHO
i find it pervert that such basics need to be discussed
* you can't reahc 100% security, never, in no way * you can only try to make it as tightas possible * each of your protections will stop some bad cases * enough of them with some luck the one user A, B, C would have hitted before updates
do you *really* not want to understand what people explaining? http://www.zend.com/de/products/studio/downloads opens ports to talk inside the LAN and prohibit starting the product on two machines with the same licencse key
*YOU DO NOT WANT THAT PORTS OPEN ON THE INTERNET BECAUSE WRONG OS-DECISIONS*
and that is besides VMware the only software not coming via yum in my case 1 out of 2 commercial products should failry explain why nobody right in his brain designs in 2014 a operating system with no packet filter at all
2014-04-28 19:13 GMT+02:00 Reindl Harald h.reindl@thelounge.net:
Am 28.04.2014 19:04, schrieb Miloslav Trmač:
2014-04-28 18:59 GMT+02:00 Reindl Harald <h.reindl@thelounge.net<mailto:
h.reindl@thelounge.net>>:
Am 28.04.2014 18:52, schrieb Miloslav Trmač: > No no no no no. If you want a firewall "integrated" /that/ way,
you are really
> better of uninstalling it or opening it up; it serves no purpose. no, even if that way is completly wrong it's better than no firewall as i have explained multiple times there may run software not from the Fedora repos which opens ports unintentionally from the users point of view and especially a user with no network expierience will not realize that - and yes that software matters because we are talking about a *operating system*
Well if the users' expectations were that the firewall doesn't
"interfere" with Fedora applications, why would they
expect it to "interfere" with non-Fedora applications?
do i really need to explain that?
you can make signed fedora packages trusted and allow them at install or first start to interact with firewalld
I can't; ptrace() doesn't make such a distinction.
And doesn't every malware know to make an _outgoing_ connection to an IRC server nowadays?
Stopping malware by blocking incoming connections is fairly illusory IMHO
i find it pervert that such basics need to be discussed
- you can't reahc 100% security, never, in no way
Still, the combined measures need to mitigate at least, say, 75% of cases, otherwise we're not really having enough impact. Mirek
Am 28.04.2014 19:27, schrieb Miloslav Trmač:
2014-04-28 19:13 GMT+02:00 Reindl Harald: > Well if the users' expectations were that the firewall doesn't "interfere" with Fedora applications, why would they > expect it to "interfere" with non-Fedora applications?
do i really need to explain that? you can make signed fedora packages trusted and allow them at install or first start to interact with firewalld
I can't; ptrace() doesn't make such a distinction.
than that needs to be improved or the current status no open ports at all without user confirmation unchanged
> And doesn't every malware know to make an _outgoing_ connection to an IRC server nowadays? > Stopping malware by blocking incoming connections is fairly illusory IMHO i find it pervert that such basics need to be discussed * you can't reach 100% security, never, in no way
Still, the combined measures need to mitigate at least, say, 75% of cases, otherwise we're not really having enough impact
in a perfect world yes, even more than 75%
in reality: only *the one an donly* case which affects me untila update is released we need the > 75% because we don't know what is needed when
but even if we reach only 25% it's better than 0% by giving up and drop the firewall
it makes me really sad that anybody ever can come to an idea disable the firewall as default because it makes things harder and that it needs discussions after 1st of April - are such people payed by the NSA and sent out to destory sceurity everywhere?
2014-04-28 19:33 GMT+02:00 Reindl Harald h.reindl@thelounge.net:
Am 28.04.2014 19:27, schrieb Miloslav Trmač:
2014-04-28 19:13 GMT+02:00 Reindl Harald: you can make signed fedora packages trusted and allow them at install or first start to interact with firewalld
I can't; ptrace() doesn't make such a distinction.
than that needs to be improved
We are working on improving it. It will still take quite a lot of time I'm afraid.
Still, the combined measures need to mitigate at least, say, 75% of
cases,
otherwise we're not really having enough impact
in a perfect world yes, even more than 75%
in reality: only *the one an donly* case which affects me untila update is released we need the > 75% because we don't know what is needed when
Good point, the "new system needs to be safely updatable" is an important case to consider. (It's also the easiest one to handle, by not having the service start, and testing for that.) Mirek
Am 28.04.2014 19:36, schrieb Miloslav Trmač:
2014-04-28 19:33 GMT+02:00 Reindl Harald <h.reindl@thelounge.net mailto:h.reindl@thelounge.net>:
Am 28.04.2014 19:27, schrieb Miloslav Trmač: > 2014-04-28 19:13 GMT+02:00 Reindl Harald: > you can make signed fedora packages trusted and allow them > at install or first start to interact with firewalld > > I can't; ptrace() doesn't make such a distinction. than that needs to be improved
We are working on improving it. It will still take quite a lot of time I'm afraid.
so the status quo needs to be unchanged until then
> Still, the combined measures need to mitigate at least, say, 75% of cases, > otherwise we're not really having enough impact in a perfect world yes, even more than 75% in reality: only *the one an donly* case which affects me untila update is released we need the > 75% because we don't know what is needed when
Good point, the "new system needs to be safely updatable" is an important case to consider. (It's also the easiest one to handle, by not having the service start, and testing for that.)
you can't do that even if you could in theory it must not be the only safety net
you choose at installation software XYZ wich may listen on ports that's the whole argumentation of dropping the firewall to make these things working out-of-theb-box the easy way
there is a timewindow between installation and get the latest updates well, you need the network to fetch that updates
and what is permanently ignored here and proves that the proposal disable the firewall completly is a clueless ignoring reality is that "i want saba to share files" *never ever* means "oh and samba should be reachable from the internet"
in no case - independent of possible vulerabilities which needs to be closed by fetch updates over the internet you want smaba be reachable on the WAN and the one idiot out of a million which wants that don't really so - he just don't know what he really wants
one of the goals of sane and secure OS defaults is to protect users from themself
even if the only thing you reach is a timewindow from start to find out how to disable the firewall until find how to do to think about that idea and come to the conclusion do that unconditionally is a bad idea you reached a lot -> a handful users not doing so
On 04/28/2014 12:42 PM, David Woodhouse wrote:
Actually, I think the best way to fix this is with SELinux, rather than iptables. Why go for an overly complex solution where authorised processes have to prod a firewall dæmon to change the iptables configuration, when the kernel has a perfectly good "firewall" built in as a fundamental part of the IP stack? Send a TCP SYN to a port which nobody's listening on, and you'll get a TCP RST back. Send a UDP packet to closed port, and you'll get an ICMP 'port unreachable' back. No need for iptables at all. All you need to do, if you really want to control incoming connections, is use SELinux to limit who can bind() and listen() to certain ports.
Can we make this stick for the unconfined_t user as well? How can system administrators configure exceptions? What about developers who need to bind to various ports, e.g. while running test suites? Will it be as straightforward as with firewalld?
An explicit failure on bind() might actually give us better error reporting (especially if the EPERM details idea is implemented). I like the SELinux idea.
On 04/28/2014 08:09 PM, Florian Weimer wrote:
On 04/28/2014 12:42 PM, David Woodhouse wrote:
Actually, I think the best way to fix this is with SELinux, rather than iptables. Why go for an overly complex solution where authorised processes have to prod a firewall dæmon to change the iptables configuration, when the kernel has a perfectly good "firewall" built in as a fundamental part of the IP stack? Send a TCP SYN to a port which nobody's listening on, and you'll get a TCP RST back. Send a UDP packet to closed port, and you'll get an ICMP 'port unreachable' back. No need for iptables at all. All you need to do, if you really want to control incoming connections, is use SELinux to limit who can bind() and listen() to certain ports.
Can we make this stick for the unconfined_t user as well? How can system administrators configure exceptions? What about developers who need to bind to various ports, e.g. while running test suites? Will it be as straightforward as with firewalld?
An explicit failure on bind() might actually give us better error reporting (especially if the EPERM details idea is implemented). I like the SELinux idea.
To be able to bind only in a "trusted" environment has advantages, but also disadvantages:
+ You have the possibility of error reporting if the app is designed in the way to fail gracefully in the "unable to open port" case. - Only works in a simple network environment that needs to be at best static. - Does not work with more than one active connection where some are "trusted" and others are not without adding mechanisms in all network services and apps that will take care about this internally with configuration and policies. - Is not working while switching the network environment from "trusted" to "untrusted" or vice versa without having network services and apps that will react gracefully on a now closed port or that are able to bind later on to. Rebooting the system, restarting all network services and apps or logging out and back in is not a good solution for this.
Ergo: You need to have very smart network services and apps with this.