Bug#778891: [Pkg-puppet-devel] Bug#778891: puppet: systemd unit file does not load environment from /etc/default/puppet - breaks upgrades
Hi all,
I'd like to note that since 3.2.4-1, the package's maintainer scripts
actually _remove_ /etc/default/puppet if it's unmodified or save it as
/etc/default/puppet.dpkg-bak if it has been modified by the user. The
latter means that even for sysvinit users where the initscript is
functional, upgrading from wheezy to jessie will break their setups if
they used /etc/default/puppet to pass daemon arguments.
In my understanding to fix all of these issues the following actions are
required:
- change puppet.service to read /etc/default/puppet and use
$DAEMON_OPTS.
- remove the dpkg-maintscript-helper rm_conffile calls from the
maintainer scripts. We still will not be shipping
/etc/default/puppet, put we don't want to remove it since the
initscript and the systemd unit file will be using it if it exists.
- apart from new installations, also disable the agent when upgrading
from pre-3.2.4-1 versions if /etc/default/puppet exists *and* $START
is not true.
If so, the attached patch should¹ fix this bug.
Regards,
Apollon
¹ still untested
diff --git a/debian/puppet-common.preinst b/debian/puppet-common.preinst
index 6039b2a..ea34e2a 100644
--- a/debian/puppet-common.preinst
+++ b/debian/puppet-common.preinst
@@ -18,7 +18,7 @@ disable_puppet_agent() {
tmp_lockfile=$(mktemp /var/lib/puppet/state/agent_disabled.lock.)
lockfile=/var/lib/puppet/state/agent_disabled.lock
-printf '{"disabled_message":"Disabled by default on new installations"}' \
+printf '{"disabled_message":"Disabled by default on new or unconfigured old installations"}' \
> $tmp_lockfile
mv $tmp_lockfile $lockfile
@@ -30,6 +30,17 @@ case "$1" in
if [ -z "$2" ]; then
disable_puppet_agent
fi
+
+ if dpkg --compare-versions "$2" lt "3.2.4-1~" && \
+ [ -e "/etc/default/puppet" ]; then
+ . /etc/default/puppet
+
+ if [ "x$START" != "xtrue" -a "x$START" != "xyes" -a "x$START" != "x0" ]; then
+ # Note that "0" is not a typo, it reflects the checks done
+ # in wheezy's initscript.
+ disable_puppet_agent
+ fi
+ fi
;;
upgrade)
diff --git a/debian/puppet.postinst b/debian/puppet.postinst
deleted file mode 100644
index a04c65a..000
--- a/debian/puppet.postinst
+++ /dev/null
@@ -1,44 +0,0 @@
-#!/bin/sh
-# postinst script for puppet
-#
-# see: dh_installdeb(1)
-
-set -e
-
-# summary of how this script can be called:
-#* `configure'
-#* `abort-upgrade'
-#* `abort-remove' `in-favour'
-#
-#* `abort-remove'
-#* `abort-deconfigure' `in-favour'
-#`removing'
-#
-# for details, see http://www.debian.org/doc/debian-policy/ or
-# the debian-policy package
-
-
-case "$1" in
-configure)
-;;
-
-abort-upgrade|abort-remove|abort-deconfigure)
-;;
-
-*)
-echo "postinst called with unknown argument \`$1'" >&2
-exit 1
-;;
-esac
-
-if dpkg-maintscript-helper supports rm_conffile; then
-dpkg-maintscript-helper rm_conffile \
-/etc/default/puppet 3.2.3-1 puppet -- "$@"
-fi
-
-# dh_installdeb will replace this with shell code automatically
-# generated by other debhelper scripts.
-
-#DEBHELPER#
-
-exit 0
diff --git a/debian/puppet.postrm b/debian/puppet.postrm
deleted file mode 100644
index e0370f9..000
--- a/debian/puppet.postrm
+++ /dev/null
@@ -1,42 +0,0 @@
-#!/bin/sh
-# postrm script for puppet
-#
-# see: dh_installdeb(1)
-
-set -e
-
-# summary of how this script can be called:
-#* `remove'
-#* `purge'
-#* `upgrade'
-#* `failed-upgrade'
-#* `abort-install'
-#* `abort-install'
-#* `abort-upgrade'
-#* `disappear'
-#
-# for details, see http://www.debian.org/doc/debian-policy/ or
-# the debian-policy package
-
-
-case "$1" in
-purge|remove|upgrade|failed-upgrade|abort-install|abort-upgrade|disappear)
-if dpkg-maintscript-helper supports rm_conffile; then
-dpkg-maintscript-helper rm_conffile \
-/etc/default/puppet 3.2.3-1 puppet -- "$@"
-fi
-
-;;
-
-*)
-echo "postrm called with unknown argument \`$1'" >&2
-exit 1
-;;
-esac
-
-# dh_installdeb will replace this with shell code automatically
-# generated by other debhelper scripts.
-
-#DEBHELPER#
-
-exit 0
diff --git a/debian/puppet.preinst b/debian/puppet.preinst
deleted file mode 100644
index 18b6061..000
--- a/debian/puppet.preinst
+++ /dev/null
@@ -1,40 +0,0 @@
-#!/bin/sh
-# preinst script for #PACKAGE#
-#
-# see: dh_installdeb(1)
-
-set -e
-
-# summary of how this script can be called:
-#* `install'
-#* `install'
-#* `upgrade'
-#* `abort-upgrade'
-# for details, see http://www.debian.org/doc/debian-policy/ or
-# the debian-policy package
-
-
-case "$1" in
-install|upgrade)
-;;
-
-abort-upgrade)
-;;
-
-*)
-echo "preinst call
Bug#778891: [Pkg-puppet-devel] Bug#778891: puppet: systemd unit file does not load environment from /etc/default/puppet - breaks upgrades
Hi, On 02/23/2015 11:56 AM, Stig Sandbeck Mathisen wrote: I'm not going to add it back, but unless I'm missing something in the scenario I've outlined above, I don't agree there are no security implications here. There is a bug, which should be fixed. I've upgraded it to "serious" again, so it is "release critical". Thanks. Can you also remove the 'wontfix' tag? There are security implications, but as it needs administrative privileges to your DNS server or physical access to your network to exploit. (Or, you need to place your laptop running puppet on a hostile network, which is more likely.) In our environment we have systems managed centrally and systems managed by research groups but they share the same dns domain. I don't think they would appreciate it if their systems suddenly started to contact our puppet server :-). Regards, Rik -- Rik Theys System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 bus 2440 - B-3001 Leuven-Heverlee +32(0)16/32.11.07 <> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778891: [Pkg-puppet-devel] Bug#778891: puppet: systemd unit file does not load environment from /etc/default/puppet - breaks upgrades
Control: severity -1 serious Rik Theys writes: > I was under the impression that upgrades from Wheezy to Jessie would > switch the init system to systemd by default, unless a pin was > configured prior to the upgrade (as instructed in the draft release > notes)? Or do you mean upgrades from Jessie to Jessie+1 (Stretch?)? No, you are right. The last message[1] on debian-devel-announce says "upgrade from wheezy to jessie will switch to systemd". Last time I read about it, it was "new installs get systemd, upgrades keep sysvinit". [1] https://lists.debian.org/debian-devel-announce/2015/02/msg00013.html > I installed the puppet package on a different Wheezy system to verify > and it gets installed. 'dpkg -L puppet' also lists the file. I tested the unstable packages, and not wheezy. I probably should have tested wheezy. > You've lost me. Where in the init script is puppet started with > --disable? The preinst script of the puppet-common package installs a lock file, /var/lib/puppet/state/agent_disabled.lock to prevent it from applying a catalog. The first packaged version of puppet which had this is 3.2.4-1, which is … not in wheezy. > Imagine I have a wheezy system with puppet installed and I've never > updated /etc/default/puppet to change the START variable to have it > started, my system would never have contacted any puppet master and > would not have any certs. (we can argue that is doesn't make sense to > have it installed if you're not using it, but there would be no > security impact if you did as it wouldn't start by default). It is also common to run puppet in "masterless" mode. If they install the "puppet" package, they have the tools needed for that. > When I then upgrade this wheezy system to jessie, my system will > suddenly start puppet (as the init script/systemd unit no longer > checks the START condition) and will send a certificate request to a > "puppet" host on my network, which might not be under my control. If > the admin of this "rogue" puppet master signs it and configures a > manifest for my system, my system will happily apply it. Am I missing > something? If this is correct, my opinion is that this has security > implications. I would argue that having someone else connect a server on your network, and adding a "puppet" alias to your DNS pointing to this server has security implications. An installed puppet agent which has been disabled in wheezy will be enabled in jessie is a bug. This would need to be solved before release of jessie. > Looking at the puppet postinst snippet of the jessie package I don't > see any logic to only enable puppet when it was already enabled (by > checking the START variable) before? I've not used Debian stable for years, so I looked in the wrong place, and misjudged the severity. Sorry. > I'm not going to add it back, but unless I'm missing something in the > scenario I've outlined above, I don't agree there are no security > implications here. There is a bug, which should be fixed. I've upgraded it to "serious" again, so it is "release critical". There are security implications, but as it needs administrative privileges to your DNS server or physical access to your network to exploit. (Or, you need to place your laptop running puppet on a hostile network, which is more likely.) -- Stig Sandbeck Mathisen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778891: [Pkg-puppet-devel] Bug#778891: puppet: systemd unit file does not load environment from /etc/default/puppet - breaks upgrades
Hi, On Sat, 21 Feb 2015, Stig Sandbeck Mathisen wrote: Rik Theys writes: During an upgrade from wheezy to jessie, puppet was upgraded to 3.7.2 and systemd became the default init system. When jessie is released, an upgrade should keep the current init system. I was under the impression that upgrades from Wheezy to Jessie would switch the init system to systemd by default, unless a pin was configured prior to the upgrade (as instructed in the draft release notes)? Or do you mean upgrades from Jessie to Jessie+1 (Stretch?)? In our environment, our puppet master is not called "puppet" and we override this setting using the DAEMON_OPTS variable in /etc/default/puppet: DAEMON_OPTS="--server our-puppet-master.ourdomain.tld" The wheezy (and jessie) init script supports this, but the systemd unit file for puppet does not read this environment file and defaults back to the "puppet" DNS name for puppet masters. The fix for this is simple and a patch for the systemd unit file is attached: the unit file should have an EnvironmentFile statement to load the environment from /etc/default/puppet (if it exists). The /etc/default/puppet file is not shipped with the puppet packaging, but is checked for in the sysv init script as a means to override the configuration. I installed the puppet package on a different Wheezy system to verify and it gets installed. 'dpkg -L puppet' also lists the file. For systemd, please use override your systemd unit with one of: * A fragment in /etc/systemd/system/puppet.service.d/something.conf This is how I've done if for now. Please consider setting "server" under the "[main]" section in /etc/puppet/puppet.conf. This will work no matter which init is used. This is probably indeed the best solution. I've flagged this as security as an upgrade from wheezy to jessie could open a system to a puppet server controlled by someone else. In case the puppet client did not yet have signed certificate it could be signed by the "puppet" puppet master, which could then execute arbitrary actions on the system. The puppet agent starts disabled with "puppet agent --disable", and has to be manually enabled with "puppet agent --enable". Even disabled, the puppet agent will connect to the master, send its CSR, and ask for a signed certificate periodically. You've lost me. Where in the init script is puppet started with --disable? Imagine I have a wheezy system with puppet installed and I've never updated /etc/default/puppet to change the START variable to have it started, my system would never have contacted any puppet master and would not have any certs. (we can argue that is doesn't make sense to have it installed if you're not using it, but there would be no security impact if you did as it wouldn't start by default). When I then upgrade this wheezy system to jessie, my system will suddenly start puppet (as the init script/systemd unit no longer checks the START condition) and will send a certificate request to a "puppet" host on my network, which might not be under my control. If the admin of this "rogue" puppet master signs it and configures a manifest for my system, my system will happily apply it. Am I missing something? If this is correct, my opinion is that this has security implications. Looking at the puppet postinst snippet of the jessie package I don't see any logic to only enable puppet when it was already enabled (by checking the START variable) before? If it is manually enabled, and still connects to a master someone has successfully installed on your network after having changed your domain to add the "puppet" name to point to that puppet master, I would suggest this is not primarily a security fault in the puppet agent packaging. If you need to configure /etc/default/puppet with command line options for a puppet master, install puppet agent, have it not to connect to the master, upgrade it from wheezy to jessie, then change init systems, and _then_ start the puppet agent, the window of opportunity for such an attacker is rather small. If the puppet agent has a puppet certificate, the puppet agent will abort with a SSL error when connecting to the new master, since the CA will differ. I know but if the wheezy installation had the puppet package installed but never had the START variable adjusted, it would not have any certificates to verify. If your puppet master is not called "puppet" in your enterprise it would not make a difference as the client would not be able to resolve it. But once it connects to a network that does have a 'puppet' machine, it would send its CSR to that node. This scenario is not very likely; I have removed the "security" tag. I'm not going to add it back, but unless I'm missing something in the scenario I've outlined above, I don't agree there are no security implications here. Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@l
Bug#778891: [Pkg-puppet-devel] Bug#778891: puppet: systemd unit file does not load environment from /etc/default/puppet - breaks upgrades
Control: severity -1 wishlist wontfix Control: tags -1 - security Rik Theys writes: > During an upgrade from wheezy to jessie, puppet was upgraded to 3.7.2 > and systemd became the default init system. When jessie is released, an upgrade should keep the current init system. > In our environment, our puppet master is not called "puppet" and we > override this setting using the DAEMON_OPTS variable in > /etc/default/puppet: > > DAEMON_OPTS="--server our-puppet-master.ourdomain.tld" > > The wheezy (and jessie) init script supports this, but the systemd >unit file for puppet does not read this environment file and defaults >back to the "puppet" DNS name for puppet masters. > > The fix for this is simple and a patch for the systemd unit file is > attached: the unit file should have an EnvironmentFile statement to > load the environment from /etc/default/puppet (if it exists). The /etc/default/puppet file is not shipped with the puppet packaging, but is checked for in the sysv init script as a means to override the configuration. For systemd, please use override your systemd unit with one of: * A fragment in /etc/systemd/system/puppet.service.d/something.conf * Complete override with /etc/systemd/system/puppet.service Please consider setting "server" under the "[main]" section in /etc/puppet/puppet.conf. This will work no matter which init is used. > I've flagged this as security as an upgrade from wheezy to jessie > could open a system to a puppet server controlled by someone else. In > case the puppet client did not yet have signed certificate it could be > signed by the "puppet" puppet master, which could then execute > arbitrary actions on the system. The puppet agent starts disabled with "puppet agent --disable", and has to be manually enabled with "puppet agent --enable". Even disabled, the puppet agent will connect to the master, send its CSR, and ask for a signed certificate periodically. If it is manually enabled, and still connects to a master someone has successfully installed on your network after having changed your domain to add the "puppet" name to point to that puppet master, I would suggest this is not primarily a security fault in the puppet agent packaging. If you need to configure /etc/default/puppet with command line options for a puppet master, install puppet agent, have it not to connect to the master, upgrade it from wheezy to jessie, then change init systems, and _then_ start the puppet agent, the window of opportunity for such an attacker is rather small. If the puppet agent has a puppet certificate, the puppet agent will abort with a SSL error when connecting to the new master, since the CA will differ. ,[ error when connecting to fake master ] | Warning: SSL_connect returned=1 errno=0 state=unknown state: | certificate verify failed: [self signed certificate in certificate | chain for /CN=Puppet CA: mallet.example.com] ` In theory, the impersonating node could be a current puppet agent, signed by the legitimate CA, but it would have to have "puppet" (or the hostname configured as "server" in puppet.conf) as an alternate name in the agent sertificate. Signing a puppet agent certificate on the puppet master with alternate names requires extra commandline options to "puppet cert sign", and prompts you with a message in the master log, and on the agent node: ,[ error when signing a host certificate with extra hostnames ] | Error: CSR 'mallet.example.com' contains subject alternative names | (DNS:mallet.example.com, DNS:puppet), which are disallowed. Use | `puppet cert --allow-dns-alt-names sign mallet.example.com` to sign | this request. ` This scenario is not very likely; I have removed the "security" tag. > I did not check if the postinst script only enables the systemd unit > when the START variable in /etc/default/puppet is set to "yes". If it > doesn't, the puppet service will be started on upgrades to jessie (and > systemd), even if it was disabled before. It would also introduce the > problem above by contacting the wrong puppet master. The init script only uses DAEMON_OPTS if set. This is only a historic feature for the sysvinit script. The START variable is not used at all. I'll keep this bug open with "wishlist" and "wontfix" tags, until the use of /etc/default/* with multiple init systems have settled, or diminished over time. -- Stig Sandbeck Mathisen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778891: puppet: systemd unit file does not load environment from /etc/default/puppet - breaks upgrades
Package: puppet Version: 3.7.2-2 Severity: grave Tags: patch security Justification: user security hole Hi, During an upgrade from wheezy to jessie, puppet was upgraded to 3.7.2 and systemd became the default init system. In our environment, our puppet master is not called "puppet" and we override this setting using the DAEMON_OPTS variable in /etc/default/puppet: DAEMON_OPTS="--server our-puppet-master.ourdomain.tld" The wheezy (and jessie) init script supports this, but the systemd unit file for puppet does not read this environment file and defaults back to the "puppet" DNS name for puppet masters. The fix for this is simple and a patch for the systemd unit file is attached: the unit file should have an EnvironmentFile statement to load the environment from /etc/default/puppet (if it exists). The patch only brings back support for the DAEMON_OPTS option, and not for the variable to prevent startup. I've flagged this as security as an upgrade from wheezy to jessie could open a system to a puppet server controlled by someone else. In case the puppet client did not yet have signed certificate it could be signed by the "puppet" puppet master, which could then execute arbitrary actions on the system. I did not check if the postinst script only enables the systemd unit when the START variable in /etc/default/puppet is set to "yes". If it doesn't, the puppet service will be started on upgrades to jessie (and systemd), even if it was disabled before. It would also introduce the problem above by contacting the wrong puppet master. Regards, Rik -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages puppet depends on: ii init-system-helpers 1.22 ii puppet-common 3.7.2-2 ii ruby1:2.1.0.4 ii ruby2.1 [ruby-interpreter] 2.1.5-1 puppet recommends no packages. Versions of packages puppet suggests: pn etckeeper pn puppet-el pn vim-puppet -- Configuration Files: /etc/default/puppet e3a89dd703e6b796ef7889ba75af2df7 [Errno 2] No such file or directory: u'/etc/default/puppet e3a89dd703e6b796ef7889ba75af2df7' /etc/logrotate.d/puppet 037c34a239a8895833388ccfce278adc [Errno 2] No such file or directory: u'/etc/logrotate.d/puppet 037c34a239a8895833388ccfce278adc' -- no debconf information --- puppet.service.orig 2015-02-21 12:05:48.26000 +0100 +++ puppet.service 2015-02-21 12:06:07.37600 +0100 @@ -4,7 +4,8 @@ [Service] Type=forking PIDFile=/run/puppet/agent.pid -ExecStart=/usr/bin/puppet agent +EnvironmentFile=-/etc/default/puppet +ExecStart=/usr/bin/puppet agent $DAEMON_OPTS [Install] WantedBy=multi-user.target
