Bug#780407: netfilter-persistent: boot continues if netfilter-persistent fails
Hey. I haven't seen that bug until I've read about it in the changelog from iptables-persistent. AFAIU it's not really fixed though, is it? A buggy line in the rules file will still lead to no iptables rules being present, while the boot continues just normally, daemons start up and may be (depending on how they're used and configured and whether they'd depend for their security on iptables - which is very easily possible) totally open at risk. I've had thought about that problem already much earlier and how it could be properly solved now with systemd. The basic idea would be the following: https://bugs.freedesktop.org/show_bug.cgi?id=80169 respectively: http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2014-May/002174.html The goals are: - support for multiple programs that may bring up iptables rules (or similar things) - iptables (or similar) rules are guaranteed to be loaded successfully before any networking is brought up i.e. other services that the admin considers essential for network- security should be easy to hook in (with no other unit files needed to be rewritten) - daemons/services should themselves be generally configured to depend on the network-securing systemd unit (see below why having this as well) - it should be *easy* for a sysadmin to selectively weaken these requirements: - get away of the *hard* "no networking at all if no iptables/etc" - selectively control per service/unit, whether it has a *hard* or *soft* dependency on secured-network "easiy" here again means, that it shouldn't be necessary for the admin to re-write the unit files of all services, but just a few As you can see from the above two URLs, both, upstream and Debian maintainers rather just placed obstacles into my way. I guess there is simply no interest in having some more hard/guaranteed security state with respect to securing up the networking A little bit later, upstream introduced networking-pre.target,... but I'd explicitly call that rubbish. It's nearly as vaguely defined as network.target itself and therefore not really suited to make any assumptions on it, and more important, it's the whole part of my framework proposal with services hooking in and so on is completely missing. Well maybe some people here are interested in the above and want to do some lobbying either upstream or at Debian. But apart from it,... Jonathan, I don't think this is really fixed, because AFAICS, a simple error in the rules-files will still lead to a networking but non-iptables-secured system, right? So shouldn't we rather re-open that issue? Thanks, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#780407: netfilter-persistent: boot continues if netfilter-persistent fails
Control: severity -1 important On Fri, 13 Mar 2015 15:01:15 +0100 Jann jann+report...@thejh.net wrote: Package: netfilter-persistent Version: 1.0.3 Severity: grave Tags: security If netfilter-persistent or one of its dependencies fails to load, system boot continues normally with a wide-open netfilter configuration. IMO, this should fail secure: If the firewall can't be brought up, at least networking should not be brought up either. Thanks for reporting this issue. I have also been affected by this in the past and took some time to realize that my system was running without a firewall. However I am not sure that stopping the boot process or disabling networking is the right action to take if netfilter configuration fails. That could render a remote-administered system unreachable, which would make the life of sysadmins rather painful. IMHO, the solution is rather to increase the visibility of the problem so that the sysadmin quickly notices the failure. That could be through a desktop notice for desktop systems, or a mail to root@ on servers. I am also downgrading the severity of this bug. The issue described here is not a security hole in netfilter-persistent per se, because the latter works well when properly configured and actually increases security. It's rather the handling of an error condition that could be improved. Cheers, -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://sebastien.villemot.name `- GPG Key: 4096R/381A7594 signature.asc Description: This is a digitally signed message part
Bug#780407: netfilter-persistent: boot continues if netfilter-persistent fails
Package: netfilter-persistent Version: 1.0.3 Severity: grave Tags: security Justification: user security hole If netfilter-persistent or one of its dependencies fails to load, system boot continues normally with a wide-open netfilter configuration. IMO, this should fail secure: If the firewall can't be brought up, at least networking should not be brought up either. In my case, netfilter was not brought up because the lp module was not present in the custom kernel I'm using, causing systemd-modules-load to fail. These are the relevant syslog lines: Mar 11 17:51:00 pc systemd-modules-load[307]: Failed to find module 'lp' Mar 11 17:51:00 pc systemd-modules-load[307]: Module 'ppdev' is builtin Mar 11 17:51:00 pc systemd-modules-load[307]: Module 'parport_pc' is builtin Mar 11 17:51:00 pc systemd-modules-load[307]: Module 'fuse' is builtin Mar 11 17:51:00 pc systemd[1]: systemd-modules-load.service: main process exited, code=exited, status=1/FAILURE Mar 11 17:51:00 pc systemd[1]: Failed to start Load Kernel Modules. Mar 11 17:51:00 pc systemd[1]: Dependency failed for netfilter persistent configuration. Mar 11 17:51:00 pc systemd[1]: Unit systemd-modules-load.service entered failed state. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.18.6jann (SMP w/8 CPU cores; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages netfilter-persistent depends on: ii init-system-helpers 1.22 ii lsb-base 4.1+Debian13+nmu1 netfilter-persistent recommends no packages. netfilter-persistent suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
