Control: severity -1 wishlist wontfix Control: tags -1 - security Rik Theys <rik.th...@esat.kuleuven.be> 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-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
