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


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


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.)

For best security, each host should run mandatory access controls (MAC), such as SELinux.  Unfortunately, many developers do not supply the correct SELinux policy with their software.  Even when the vendor (Fedora in our case) supplies a policy, it often contains errors in the default settings.  What most system administrators do not realize is how easy it is to fix and change SELinux policies.  Here you will practice changing an SELinux “boolean” and also changing the default policy to allow a server to work properly.


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 PAM configuration for chfn so that only the system administrator “root” can modify a user's finger information.  What change(s) did you make?  (Show using diff output.)

      On modern Fedora Linux systems when using the shadow suite (and we are in class), the file /etc/login.defs restricts chfn to root user only regardless of PAM settings.  To enable this in login.defs so your PAM changes will work correctly, add the line to the end of /etc/login.defs as shown in the diff output below:

          [root@localhost etc]# diff ~/login.defs login.defs
          > # Allow any one to use chfn
          > CHFN_RESTRICT no
    2. Enable wheel group authentication (with PAM) 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. Using PAM alone, set the minimum acceptable password complexity to this policy:

      Require passwords to be at least eight characters long, with at least one each of a digit, an uppercase letter, and a lowercase letter.

      (So “Hpiffl52” would be acceptable, but not “hpiffl52”.)  What change(s) did you make?  (Show using diff output.)

      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_pwquality for a better explanation.  Ask for help (or post to the class wiki) if you get stuck.)

  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

      You also need to remove yourself from group wheel.  This is because by default all members of group wheel can run any command at all, as root.  So unless you remove yourself, then log out and back in, you won't know if your sudo changes worked or not.  (When you are done with this project, you can add yourself back to group wheel for convenience.)

    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 (and don't give additional privilege beyond this) .  (Never edit /etc/sudoers directly!)  The new entry should look similar to 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?  (Hint: remember the sample /etc/sudoers file in the class resources.)

    3. Login as myaccount (or whatever your normal non-root account is called).  Use the passwd command 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?
  3. SELinux Troubleshooting

    1. In this section, we will explore troubleshooting and updating SELinux.  First, install the Apache web server, and start it.  What is the name of the package you installed?  How did you figure that out?  What command did you run to determine that the web server started correctly and is running now?
    2. As a regular (non-root) user, go to your home directory and create a sub-directory named public_html.  Set the permissions on this folder so that all users have search permission.  Add search permission for all users to your home directory as well.  What were the exact command lines you used for this?
    3. Now configure the web server to allow per-user web sites.  As root, cd into /etc/httpd/conf.d, then make the following change to the file userdir.conf:
      [root@localhost conf.d]# diff userdir.conf-orig userdir.conf
      <     UserDir disabled
      > #   UserDir disabled
      <     #UserDir public_html
      >     UserDir public_html

      After making this change, restart the web server and verify it is running.

    4. Next, create a file named “index.html” in your (non-root user's) ~/public_html directory, with the following contents:
      <!DOCTYPE html>
      <html lang="en">
          <meta charset="utf-8">
          <title>Sample Web Page</title>
          <h1>If you can see this text, it works!</h1>

      Make sure this file is readable by everyone.

    5. At this point, the web server should have per-user websites working, and you have a valid website with the correct permissions.  You should try to view your web page in a web browser, using the URL of http://localhost/~yourUserName/ (only substitute your user name of course).  What was the result?  (Did you see your web page display correctly?)
    6. If you followed these directions exactly, you should see the message:

      You don't have permission to access /~yourUserName/ on this server.

      Time to troubleshoot the problem!  The message says the issue is with permissions, but these were set correctly, so that's not the problem.  Maybe the log files have more information.  What directory contains the Apache web server (httpd) log files?

    7. Examine two log files for useful messages: access_log and error_logWhich log files (if any) contained relevant log messages?  What did the messages (if any) mean?  (Say in your own words.)
    8. Since the problem is with permissions, but not the standard DAC permissions, maybe the issue is with SELinux?  To check, examine the audit log for SELinux errors from today for the command httpd:
      # ausearch -m avc -c httpd -ts today

      What is the meaning of the three options used?  What is the meaning of the error message shown?  The fact that you got an error message that denied access to your web site means SELinux is the problem.

    9. The first step to fixing SELinux problems is to let SELinux attempt to find a solution for you.  Run the following command:
      # ausearch -m avc -c httpd -ts today |audit2why

      Along with some incorrect guesses, the result tells you what must be done to allow access.  You need to set a Boolean.  Run the command (as root) to enable user home directories:

      # setsebool -P httpd_enable_homedirs 1

      Try reloading your website in your web browser.  It should be working now, yea!  What is the meaning of the command option used?

  4. SELinux Policy Updating

    1. In this section, we will install the popular Nagios monitoring system.  As we will see, the default SELinux policy won't permit it to run.  In this section, you will update the policy to allow Nagios to run.

      Install Nagios and run it:

      # dnf install nagios nagios-plugins-all
      # setenforce 0  # Stop enforcing SELinux policy
      # systemctl start nagios

      What must you do to ensure Nagios will start automatically after each boot?

    2. Next, open a web browser to http://localhost/nagios/.  If Nagios is running, you should be asked for a user name and password.  The default for both is nagiosadmin.  Thoroughly explore Nagios.  Be sure to visit every menu item.  Generate reports and charts.  Note some of the pages take minutes to completely load, such as the “Services” page unter the “Current Status” section of the menu.  Patiently wait!
    3. Next, find all the SELinux denied messages for nagios.  (Remember, in permissive mode SELinux generates the error messages in the audit log, but doesn't actually prevent anything.)  Run the command:
      # grep nagios /var/log/audit/audit.log

      You should see several messages.  The next step is to pipe the output of that command through audit2why.  Sadly, there's no simple Boolean we can set this time to allow access.  To fix this issue, we will need to update the policy.

    4. SELinux includes another utility that can turn a set of error messages into a policy module that you can add to your system.  Run the commands (as root):
      # cd
      # grep nagios /var/log/audit/audit.log |audit2allow -M mynagios

      What two files were created in your current directory as a result of running this command?  What is the contents of the file with the “.te” extension that was generated?  (Copy the output of cat.)

    5. As root, install the new SELinux policy module.  What was the exact (and complete) command line you used?
    6. The next step is to set SELinux back to Enforcing mode and see if Nagios is still working.  What is the command used to enable enforcing mode for SELinux?

      To prevent your web browser from showing cached pages, exit your browser then restart it.  (If you can, also use your web browser's settings to empty its cache.)  Now try using Nagios again.

      One final test is needed.  You must make sure Nagios still works after a reboot.  Reboot your system and retest Nagios.  Does Nagios still work correctly after a reboot?  If not, try to figure out what must be done to make it work.

    7. I hope you got it working!  Be sure to make backups of your SELinux module files, in case you ever need to set up a system with Nagios again.  If Nagios still wasn't working, what should your next trouble-shooting step be?


PAM modules are documented in the man pages.  See man pam for an overview of PAM.  (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.)

Note 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 PAM, and if using the shadow suite, 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).  Use Canvas and submit to the project's drop-box.  Please see your syllabus for more information about submitting projects.