Your message dated Tue, 20 Jan 2015 11:47:37 +0100
with message-id
<CAOkSjBg47w9rOY_Gx0iA69RJHV9q5sV=tgwu3ht2fb492rh...@mail.gmail.com>
and subject line Re: Bug#775544: nftables: init system stop action shouldn't
flush rules
has caused the Debian Bug report #775544,
regarding nftables: init system stop action shouldn't flush rules
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
775544: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775544
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: nftables
Version: 0.4-2
Severity: important
Tags: security
Hi.
I had the same discussion basically already for netfilter-prsistent:
IMHO, init system stop action shouldn't lead to firewall rules being
flushed.
First, there is a security reason, i.e. when you shut down the system
there would be a small amount of time, where daemons (that depend on
being secured by the firewall) may be exposed (which is why I marked
this bug important/security).
Secondly, it doesn't sound conceptually reasonable to equalise
"stop firewall" with "flush rulsets".
Especially since it's rather undefined what actually happens
when you stop a firewall.... is it all traffic goes throuh? Or is
it nothing goes through any longer.
I'd strongly tend to the later (not only for security reasons),...
consider you'd have a harware firewall and you stop that (i.e.
pull the plug),.. then networking would be dead.
Similarly, if you take it meaphorically, i.e. you have a wall with
doors (that let some packets through automatically),.. if you stop
the system the doors won't no longer open.
Long story short, init actions might be invoked via many ways,
but completely opening up the firewall's gates, should be really some
clear, distinctive and special command (i.e. like nft flush).
Cheers,
Chris.
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_DE.utf8, LC_CTYPE=en_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages nftables depends on:
ii init-system-helpers 1.22
ii libc6 2.19-13
ii libgmp10 2:6.0.0+dfsg-6
ii libmnl0 1.0.3-5
ii libnftnl0 1.0.3-4
ii libreadline6 6.3-8+b3
nftables recommends no packages.
nftables suggests no packages.
-- Configuration Files:
/etc/nftables/bridge-filter 13af207b629f3c157cde9569fc36e0b3 [Errno 2] No such
file or directory: u'/etc/nftables/bridge-filter
13af207b629f3c157cde9569fc36e0b3'
/etc/nftables/inet-filter 58921ae85fd0c1c903ef1b334f3d6fc5 [Errno 2] No such
file or directory: u'/etc/nftables/inet-filter 58921ae85fd0c1c903ef1b334f3d6fc5'
/etc/nftables/ipv4-filter 03c4f6169a9e3f6af9dfc841d7e74a34 [Errno 2] No such
file or directory: u'/etc/nftables/ipv4-filter 03c4f6169a9e3f6af9dfc841d7e74a34'
/etc/nftables/ipv4-mangle d42443803049ad6493713d7ca4148b77 [Errno 2] No such
file or directory: u'/etc/nftables/ipv4-mangle d42443803049ad6493713d7ca4148b77'
/etc/nftables/ipv4-nat 4c761d1dc90c7639d32671c402216aaa [Errno 2] No such file
or directory: u'/etc/nftables/ipv4-nat 4c761d1dc90c7639d32671c402216aaa'
/etc/nftables/ipv6-filter 9e8cdd55559c335ab759f8d9fece8e86 [Errno 2] No such
file or directory: u'/etc/nftables/ipv6-filter 9e8cdd55559c335ab759f8d9fece8e86'
/etc/nftables/ipv6-mangle b865abc1691df2a00c95c07a7d7af38c [Errno 2] No such
file or directory: u'/etc/nftables/ipv6-mangle b865abc1691df2a00c95c07a7d7af38c'
/etc/nftables/ipv6-nat 2c2ac8c0d03e48a6d9573b62e89cd222 [Errno 2] No such file
or directory: u'/etc/nftables/ipv6-nat 2c2ac8c0d03e48a6d9573b62e89cd222'
-- no debconf information
--- End Message ---
--- Begin Message ---
Hi Christoph,
thanks for your interest.
I understand your position.
As I said before, the intended behaviour of stopping the firewall
service is firewalling happening no longer in the machine.
I believe such behaviour is the widest possible approach, to cover:
laptop users, desktop users and sysadmin (which mostly don't care
about the behaviour since they are likely going to manually configure
it).
>From my point of view, after several years of dealing with firewalls
as a system administrators, after knowing how other distributions do
the thing (centos, rhel), after two or three years being an upstream
netfilter developer, I feel confident enough to say: this is not a
bug, is a feature.
To give some perspective: we are talking about a by-default-disabled
service in a still-in-development optional package in a distribution
which doesn't ship a firewall by default.
Just to let you know, I've shown this bug on #debian-security, and
they agree on this bug being closed.
So, for me the discussion on this matter has come to an end actually.
Closing the bug now.
May I ask you to don't play ping-pong? If you want further discussion,
I would suggest to switch to debian-firewall@l.d.o or even
debian-devel@l.d.o.
best regards.
--
Arturo Borrero González
--- End Message ---
