8:39 p.m.
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
[0] https://fedoraproject.org/wiki/Features/PackagePresets
8:44 p.m.
On Sun, Apr 20, 2014 at 6:39 PM, Lars Seipel <lars.seipel(a)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
9:41 p.m.
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
10:32 p.m.
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
2:17 a.m.
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.
--
Florian Weimer / Red Hat Product Security Team
12:33 p.m.
On Mon, Apr 21, 2014 at 12:17 AM, Florian Weimer <fweimer(a)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
1:32 p.m.
On Tue, 22 Apr 2014 10:33:12 -0700
Andrew Lutomirski <luto(a)mit.edu> wrote:
On Mon, Apr 21, 2014 at 12:17 AM, Florian Weimer
<fweimer(a)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
6:57 p.m.
On Mon, Apr 21, 2014 at 12:17 AM, Florian Weimer <fweimer(a)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
4 a.m.
On 04/24/2014 01:57 AM, Andrew Lutomirski wrote:
On Mon, Apr 21, 2014 at 12:17 AM, Florian Weimer
<fweimer(a)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....
--
Florian Weimer / Red Hat Product Security Team
1:35 p.m.
On Thu, Apr 24, 2014 at 2:00 AM, Florian Weimer <fweimer(a)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(a)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....
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
2:42 a.m.
New subject: an that is why we need a firewall -> Re: When a yum update sets up an MTA ...
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(a)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(a)redhat.com>
- 1:6.2-4 - use MTA instead of sendmail as a requirement (#1048614)
* Thu Apr 10 2014 Michal Hlavinka <mhlavink(a)redhat.com> - 1:6.2-3
- add mail requires (#1048614)
5:58 a.m.
New subject: an that is why we need a firewall -> Re: When a yum update sets up an MTA ...
On Mon, Apr 21, 2014 at 3:42 AM, Reindl Harald <h.reindl(a)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(a)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(a)redhat.com>
- 1:6.2-4 - use MTA instead of sendmail as a requirement (#1048614)
* Thu Apr 10 2014 Michal Hlavinka <mhlavink(a)redhat.com> - 1:6.2-3
- add mail requires (#1048614)
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
6:02 a.m.
New subject: and that is why we need a firewall -> Re: When a yum update sets up an MTA ...
Am 21.04.2014 12:58, schrieb Mauricio Tavares:
On Mon, Apr 21, 2014 at 3:42 AM, Reindl Harald
<h.reindl(a)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
6:22 a.m.
New subject: an that is why we need a firewall -> Re: When a yum update sets up an MTA ...
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.
5:42 a.m.
New subject: an that is why we need a firewall -> Re: When a yum update sets up an MTA ...
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.
--
dwmw2
6:01 a.m.
New subject: and that is why we need a firewall -> Re: When a yum update sets up an MTA ...
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!
11:52 a.m.
New subject: an that is why we need a firewall -> Re: When a yum update sets up an MTA ...
2014-04-28 12:42 GMT+02:00 David Woodhouse <dwmw2(a)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
11:59 a.m.
New subject: an that is why we need a firewall -> Re: When a yum update sets up an MTA ...
Am 28.04.2014 18:52, schrieb Miloslav Trmač:
2014-04-28 12:42 GMT+02:00 David Woodhouse <dwmw2(a)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
12:04 p.m.
New subject: an that is why we need a firewall -> Re: When a yum update sets up an MTA ...
2014-04-28 18:59 GMT+02:00 Reindl Harald <h.reindl(a)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
12:13 p.m.
New subject: an that is why we need a firewall -> Re: When a yum update sets up an MTA ...
Am 28.04.2014 19:04, schrieb Miloslav Trmač:
2014-04-28 18:59 GMT+02:00 Reindl Harald <h.reindl(a)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
12:27 p.m.
New subject: an that is why we need a firewall -> Re: When a yum update sets up an MTA ...
2014-04-28 19:13 GMT+02:00 Reindl Harald <h.reindl(a)thelounge.net>:
Am 28.04.2014 19:04, schrieb Miloslav Trmač:
> 2014-04-28 18:59 GMT+02:00 Reindl Harald <h.reindl(a)thelounge.net<mailto:
h.reindl(a)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
12:33 p.m.
New subject: an that is why we need a firewall -> Re: When a yum update sets up an MTA ...
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?
12:36 p.m.
New subject: an that is why we need a firewall -> Re: When a yum update sets up an MTA ...
2014-04-28 19:33 GMT+02:00 Reindl Harald <h.reindl(a)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
12:47 p.m.
New subject: an that is why we need a firewall -> Re: When a yum update sets up an MTA ...
Am 28.04.2014 19:36, schrieb Miloslav Trmač:
2014-04-28 19:33 GMT+02:00 Reindl Harald <h.reindl(a)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
1:09 p.m.
New subject: an that is why we need a firewall -> Re: When a yum update sets up an MTA ...
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.
--
Florian Weimer / Red Hat Product Security Team
5:37 a.m.
New subject: an that is why we need a firewall -> Re: When a yum update sets up an MTA ...
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.
3686
days inactive
3694
days old
26 comments
10 participants
participants (10)
-
Andrew Lutomirski -
David Woodhouse -
Florian Weimer -
Kevin Fenzi -
Lars Seipel -
Mauricio Tavares -
Miloslav Trmač -
Rahul Sundaram -
Reindl Harald -
Thomas Woerner