[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 serious

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