[Pkg-puppet-devel] Bug#778891: Bug#778891: puppet: systemd unit file does not load environment from /etc/default/puppet - breaks upgrades

[Stig Sandbeck Mathisen]

Control: severity -1 wishlist wontfix
Control: tags -1 - security

Rik Theys <Rik.Theys at 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