Hi,
On Sat, 21 Feb 2015, Stig Sandbeck Mathisen wrote:
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.
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...@lists.debian.org
