CTS 2322 (Unix/Linux Administration II) Project
Setting Security Policies With PAM and sudo

 

Due: by the start of class on the date shown on the syllabus

Background:

All Unix and Linux system will ship with different default security policies.  Usually these policies don't match the local policies, such as which users are allowed what kind of access to which resources and when.  (This is often referred to as an acceptable use policy or AUP.)  In addition security policies may require non-default authentication and/or logging.

A system administrator must examine the system's configuration files and update them if necessary to enforce local policies.  On modern systems PAM (Pluggable Authentication Modules) can be used to configure a wide range of security policies, including which databases to use to authenticate users, minimum password length, max login attempts, special permissions for console users (to various commands and devices), and many other policies.

As an example consider the wheel group policy.  The wheel group enables you to define several system administrators and none of them need the root password.  The group wheel was first used this way in Unix systems, but by using PAM any system can enable this handy feature.  (Solaris uses the group sysadmin similarly.)  With proper PAM configuration any member of group wheel can become root by using the su command without supplying any password.  The wheel group can be used in other ways too, such as enforcing a policy that allows only certain users access to the su command.  You can add users to the wheel group by editing /etc/group.  On Linux you can use the vigr command or the gpasswd command for this.

Granting complete rootly power to many people is risky.  Many system administrators don't use wheel and prefer to grant more specific permissions to individual users.  The sudo package allows users permission to perform some tasks that normally would require root login.  sudo is configured by specifying who is allow to run which commands (and with what options or exclusions).  Then those users can run those commands by supplying their own password, not the root password.  (Solaris supports the third-party sudo command, but also includes a built-in facility known as role-based access control with similar abilities.  See Role Based Access Control for more information.)

The sudo facility is configured by creating the file /etc/sudoers with the visudo command.  sudo has lots of options and can be tricky to configure correctly.  For example the sudo entry created in this assignment allows myaccount to change the root password.  Then myaccount could become superuser with the su command.  A proper configuration can prevent this, read the man page for details.  (See the sample /etc/sudoers file for an example of how to correctly setup multiple password administrators.)

Requirements:

For this assignment you must learn enough about PAM and sudo to examine and update some of the security policies on a system.  Then perform the following tasks by updating the PAM and sudo configuration files, granting the minimum privilege required.  Then answer the following questions:

  1. PAM Configuration

    1. Modify the chfn configuration so that only the system administrator can modify a user's finger information.  What change(s) did you make?  (Show using diff output.)
    2. Enable wheel group authentication for su:  Only users who are members of the group wheel should be allowed to use the su command (they still need to supply a password.)  What change(s) did you make?  (Show using diff output.)  Add your user account to the group wheel.  Now logout and then login again (to force the group membership changes to be noticed).  Try to use su to verify your PAM changes worked.  What were the results?
    3. Set the minimum acceptable password length to 8 characters, regardless of the type of characters.  (So “AAAAAAAA” would be acceptable, but not “AAAAAAA”.)  See note about login.defs.  (Note the documentation for pam_pwquality (based on the older pam_cracklib, and compatible with it) can be hard to understand.  See Notes on pam_cracklib for a better explanation.  Ask for help (or post to the class wiki) if you get stuck.) What change(s) did you make?  (Show using diff output.)
  2. sudo Configuration

    1. For this part you will need a second user account.  If you don't already have an account for auser you can create one by running (as root):
           # useradd -c "Ann User" -m auser
           # passwd auser
    2. Run the visudo command (as root) to edit the /etc/sudoers file to allow your normal user account (myaccount is used below) to change passwords for other users except root (and don't give additional privilege beyond this) .  (Never edit /etc/sudoers directly!)  The new entry should look like this (assume your account name is myaccount), at the bottom of the file:
           myaccount  ALL = /usr/bin/passwd

      What are some of the security risks associated with this addition?  What change(s) would you suggest to this entry, to make it safer?

    3. Login as myaccount (or whatever your normal non-root account is called).  Use the passwd to try to lock the account for auser as follows:
           passwd -l auser
      What happened?
    4. Now try it again using sudo.  This is done by running the command as normal, but with the word sudo in front:
          sudo passwd -l auser

      What output did you see from sudo?  Did you lock the account this time?  (Check with passwd -S auser.)

    5. Try to unlock the account without using sudo:
           passwd -u auser
      What output did you see this time?  Is the account unlocked now?
    6. Unlock the account using sudoWhat happened this time?
    7. Using what you have learned about finding and reading system documentation, enable your normal user account to edit the file /etc/hosts using the sudoedit command.  What changes did you make to the sudoers file for this?

Hints:

Red Hat has (finally) documented PAM in the man pages, see man pam for an overview.  (On other systems look for PAM documentation in /usr/doc or /usr/share/doc, or look on-line at the Linux PAM System Administrator's Guide and also Sun's Solaris 10 PAM Guide.)

All the PAM configuration tasks for this assignment can be done by editing some PAM configuration files in /etc/pam.d.  Usually it is easier to look at several of these files to figure out the syntax, than to read the documentation.  A walk-through of one of these files, along with detailed comments can be found on the PAM Help guide.  Take a look at the files chfn, su, passwd, and system-auth.

For Red Hat systems the system-auth file is regenerated whenever the authconfig command is run.  That means you must edit this file each time the authconfig command is run since your changes get wiped out.  (I consider this a bug in Red Hat and similar systems.  But until they put me in charge I suggest you carefully document your changes and backup the original and modified versions of the system-auth file.)

Linux has a file /etc/login.defs (similar to Solaris's /etc/default/passwd).  This file is part of the shadow suite and is used to specify a number of settings used by login and passwd when the shadow suite is used.  Note that if you don't use the shadow suite (e.g., using NIS, LDAP, or Kerberos instead) the file may not be consulted.  You don't need to modify login.defs since you should use PAM to configure password policies.  When changing a password using passwd, the command will ensure the new password meets the policy requirements from both PAM as well as from login.defs, so be sure you use compatible settings for both!  Also note the passwd command has a few hard-coded policies that can't be changed or over-ridden (and are poorly documented if documented at all).

Solaris doesn't come with pam_cracklib or pam_pwquality, but provides other methods of configuring passwd.  As of Solaris 10 pam_unix has been replaced with a number of new modules.  Use pam_authtok_check module to set password strength criteria, similar to pam_pwquality.  (Unlike pam_pwquality, you don't pass any options to pam_authtok_check.  It is configured by settings in /etc/default/passwd.)

Remember you can use your YborStudent account to read man pages and other documentation, and to examine the /etc/pam.d/* configuration files.  This should make it easier to work from off-campus.

To Be Turned In:

A copy of your journal pages, showing all system changes made as a result of this project.  Don't turn in your whole journal, you will need to add to it every day in class!  It is common in fact to keep the journal as a text file on the system (with a paper backup of course).  You can send as email to (preferred).  Please see your syllabus for more information about submitting projects.