Locking user accounts & deploying sudoers file

Puppet

In Puppet, the combined configuration to be applied to a host is called a catalog, and the process of applying it is called a run.

The Puppet client software is called the agent. Puppet calls the definition of the host itself a node. The Puppet server is called the master.

If we want to be able to block a user from logging in, we can do this by temporarily removing his SSH key in Puppet, modules/user/manifests/init.pp:

class user {
  user { 'k':
    ensure => present,
    comment => 'bogo user',
    home => '/home/k',
    managehome => true
  }
  ssh_authorized_key { 'k_ssh':
  user => 'k',
  type => 'rsa',
  key => '',
  }
}

The value for key in the example above is an empty single-quoted string (''). This will disable SSH logins for the user. If we have enabled password authentication (which I don't recommend, but you might need it in some situations) then this won't stop the user from logging in using his password. So, in this case, we need to set a password of a single star (*) in Puppet:

class user {
  user { 'k':
    ensure => present,
    comment => 'bogo user',
    home => '/home/k',
    managehome => true
    password => '*'
  }
}

This will block the user from logging in via password (though SSH will still work unless we also disable that, as shown above). To unlock the account, remove the password attribute and re-set the user's password using the passwd command.

# /etc/puppet/manifests/site.pp
node 'puppet-agent' {
  include user
}

sudo (substitute user do) allows users to run programs with the security privileges of another user (normally the superuser, or root). Unlike the su command, users typically supply their own password to sudo rather than the root password. After authentication, and if the /usr/local/etc/sudoers (or at /etc/sudoers) configuration file permits the user access. The sudoers configuration file enables a huge amount of configurability.

In short, the sudo command allows normal users to run commands with root privileges, if this is specifically authorized by the system administrator.

The set of users allowed to assume root privileges, and the specific commands they can run, is specified in the file /etc/sudoers. We can use Puppet to manage this file, and thus control user privileges on the machine.

1. Create the directories for a sudoers module:

   ubuntu@ip-172-31-45-62:/etc/puppet$ sudo mkdir -p modules/sudoers/manifests
   ubuntu@ip-172-31-45-62:/etc/puppet$ sudo mkdir -p modules/sudoers/files
   

   
2. Create the file modules/sudoers/manifests/init.pp with the following contents:

   # Manage the sudoers file
   class sudoers {
     file { '/etc/sudoers':
       source => 'puppet:///modules/sudoers/sudoers',
       mode => '0440', 
       owner => 'root',
       group => 'root',
     }
   }
   

3. User privileges, and permission for normal users to run certain commands as root, are controlled by the /etc/sudoers file. By managing this file (carefully) with Puppet, we can control all user sudo rights on a machine. Let's create the file modules/sudoers/files/sudoers with the following contents:

   # User privilege specification
   root ALL = (ALL) ALL
   ubuntu ALL = (ALL) NOPASSWD:ALL
   k ALL = (ALL) NOPASSWD: /bin/ls
   

   The line

   root ALL = (ALL) ALL
   

   allows user root to sudo any command as root. Though this might seem unnecessary, but it's included for consistency, and to make sure any scripts that use sudo don't suddenly fail if run as root.
   The line

   ubuntu ALL = (ALL) NOPASSWD:ALL
   

   allows user ubuntu to run any command, on any system, as any user, without having to enter a password. (We can have sudo require the user's password, if we use passwords, to make things a little more secure. However, in general, sudoers entries are used for scripts and automated jobs that can't enter a password anyway.)
   The line

   k ALL = (ALL) NOPASSWD: /bin/ls
   

   is more specific. It allows user 'k' to run only the command /bin/ls (with any arguments). No other commands will work.
   
   
4. Check the syntax of the sudoers file:

   ubuntu@ip-172-31-45-62:/etc/puppet$ visudo -c -f modules/sudoers/files/sudoers
   modules/sudoers/files/sudoers: parsed OK
   

5. If there are any errors, correct them before moving on. If we use Puppet to deploy a sudoers file that contains syntax errors, no users will be able to sudo anything, and we may need to log in as root in order to fix the problem. So whenever we make a change to Puppet's copy of the sudoers file, use the visudo command as above to check the syntax.
6. Add the following to node definition in manifests/site.pp:

   node 'puppet-agent' {
     include user
     include sudoers
   }
   

7. Run puppet:

   ubuntu@puppet-agent:/etc/puppet$ sudo puppet agent --test
   sudo: unable to resolve host puppet-agent
   Info: Retrieving plugin
   Info: Caching catalog for puppet-agent.ec2.internal
   Info: Applying configuration version '1419795358'
   Notice: Finished catalog run in 0.06 seconds
   

8. Run the following command as the ubuntu user to verify that the changes have taken effect:

   ubuntu@puppet-agent:/etc/puppet$ sudo whoami
   root
   

9. Run the following command as the ubuntu user to verify that the changes have taken effect:

   ubuntu@puppet-agent:/etc/puppet$ sudo whoami
   root
   

10. Run the following command as the user, 'k', to test whether he has the privilege to run /bin/ls as root :

    $ whoami
    k
    
    $ sudo /bin/ls -l /
    total 76
    drwxr-xr-x   2 root root  4096 Sep 27 10:37 bin
    drwxr-xr-x   3 root root  4096 Sep 27 10:37 boot
    drwxr-xr-x  13 root root  3980 Dec 26 05:10 dev
    drwxr-xr-x  91 root root  4096 Dec 28 19:36 etc
    drwxr-xr-x   4 root root  4096 Dec 28 00:50 home
    lrwxrwxrwx   1 root root    33 Sep 27 10:36 initrd.img -> boot/initrd.img-3.13.0-36-generic
    drwxr-xr-x  21 root root  4096 Sep 27 10:36 lib
    drwxr-xr-x   2 root root  4096 Sep 27 10:35 lib64
    drwx------   2 root root 16384 Sep 27 10:37 lost+found
    drwxr-xr-x   2 root root  4096 Sep 27 10:35 media
    drwxr-xr-x   2 root root  4096 Apr 10  2014 mnt
    drwxr-xr-x   2 root root  4096 Sep 27 10:35 opt
    dr-xr-xr-x 120 root root     0 Dec 26 05:09 proc
    drwx------   3 root root  4096 Dec 28 08:19 root
    drwxr-xr-x  19 root root   700 Dec 28 19:44 run
    drwxr-xr-x   2 root root  4096 Sep 27 10:37 sbin
    drwxr-xr-x   2 root root  4096 Sep 27 10:35 srv
    dr-xr-xr-x  13 root root     0 Dec 26 05:09 sys
    drwxrwxrwt   2 root root  4096 Dec 28 19:38 tmp
    drwxr-xr-x  10 root root  4096 Sep 27 10:35 usr
    drwxr-xr-x  12 root root  4096 Sep 27 10:37 var
    lrwxrwxrwx   1 root root    30 Sep 27 10:36 vmlinuz -> boot/vmlinuz-3.13.0-36-generic
    

When we use Puppet to deploy the sudoers file, the privilege settings listed in the file will immediately take effect. When any user runs a command using sudo, the system will look up /etc/sudoers to see whether or not the command is allowed.

Puppet