The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Bug #11094

ruby-libshadow not being used on RHEL 6

Added by Dan Lowe about 3 years ago. Updated almost 2 years ago.

Status:AcceptedStart date:11/30/2011
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:security
Target version:-
Affected Puppet version:2.7.6 Branch:
Keywords:useradd passwords

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This ticket may be automatically exported to the PUP project on JIRA using the button below:


Description

To be honest, I am not sure if this should be a bug or feature request, but my reading of the documentation makes me think it’s a possible bug.

On my Solaris 8 and 10 systems, I have Puppet 2.7.6 running with ruby-libshadow, and users are added as expected, including their shadow passwords being handled.

On RHEL 6, the users are being added properly, but during an audit we determined that there is information leakage during the add process. The password hash is being supplied to useradd via the “-p” flag. (Presumably this is also the case with usermod when the user already exists at the time of password set/change.) That creates a small but extant leakage where the hash is exposed to any user on the system via the process table (if only briefly).

My understanding is that when libshadow is installed, Puppet is supposed to use it to handle shadow passwords, instead of using user{add,mod} -p. Is this intentional behavior, or is it abnormal that libshadow is not being used?

I wrote a wrapper around useradd to capture the arguments it was passed, here is an example test user that was added.

‘-s’ ‘/bin/bash’ ‘-u’ ‘9998’ ‘-g’ ‘root’ ‘-c’ ‘Dan Lowe’ ‘-d’ ‘/home/dantest8’ ‘-p’ ‘EAY9JzzcL3kSz’ ‘-M’ ‘dantest8’

libshadow is installed on this system.

$ gem list | grep shadow libshadow (1.0.0)

History

#1 Updated by Josh Cooper about 3 years ago

  • Status changed from Unreviewed to Investigating

Could you verify that puppet is able to load the libraries:

$ ruby -e "require 'puppet'; puts Puppet.features.libshadow?"

#2 Updated by Dan Lowe about 3 years ago

Yes, it is loading properly.

$ ruby -rpuppet -e 'puts Puppet.features.libshadow?'
true

#3 Updated by Josh Cooper about 3 years ago

  • Category set to security
  • Status changed from Investigating to Accepted
  • Keywords set to useradd passwords

So the solaris user_role_add provider does not leak the hashed password because it directly writes to /etc/shadow (using a tempfile). The useradd provider on the other hand only uses ruby-shadow to read the password entries — when determining if the passwords are in sync. However, when setting the password, it passes it on the command line, and has apparently done this forever. I’m not sure why it’s not using Shadow::Passwd.putspent to set it (with appropriate locking), but clearly it should.

#4 Updated by Dan Lowe about 3 years ago

Since Solaris also provides putspent(), sounds like a possible opportunity to factor out that Solaris-specific code…

Also available in: Atom PDF