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.
wheel group enables you to define several
system administrators and none of them need the root password.
wheel was first used this way in Unix systems,
but by using PAM any system can enable this handy feature.
(Solaris uses the group
With proper PAM configuration any member of group
wheel can become root by using the
command without supplying any password.
wheel group can be used in other ways too, such
as enforcing a policy that allows only certain users access to
You can add users to the
wheel group by editing
On Linux you can use the
vigr command or the
gpasswd command for this.
Granting complete rootly power to many people is
Many system administrators don't use
and prefer to grant more specific permissions to individual
sudo package allows users permission to
perform some tasks that normally would require
sudo is configured by specifying who is
allow to run
which commands (and with what options or
Then those users can run those commands by supplying their
own password, not the root password.
(Solaris supports the third-party
but also includes a built-in facility known as role-based
access control with similar abilities.
See Role Based Access Control for more
sudo facility is configured by creating
/etc/sudoers with the
sudo has lots of options and can be tricky
to configure correctly.
For example the
sudo entry created in this
to change the
myaccount could become superuser with the
A proper configuration can prevent this, read the man page
(See the sample /etc/sudoers file
for an example of how to correctly setup multiple password
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:
chfnconfiguration so that only the system administrator can modify a user's
fingerinformation. What change(s) did you make? (Show using
wheelgroup authentication for
su: Only users who are members of the group
wheelshould be allowed to use the
sucommand (they still need to supply a password.) What change(s) did you make? (Show using
diffoutput.) 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
suto verify your PAM changes worked. What were the results?
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_pwquality 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
you can create one by running (as
# useradd -c "Ann User" -m auser # passwd auser
You also need to remove yourself from group
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
wheel for convenience.)
visudocommand (as root) to edit the
/etc/sudoersfile 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/sudoersdirectly!) 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?
myaccount(or whatever your normal non-root account is called). Use the
passwdto try to lock the account for
passwd -l auserWhat happened?
sudo. This is done by running the command as normal, but with the word
sudo passwd -l auser
What output did you see from
Did you lock the account this time?
passwd -S auser
passwd -u auserWhat output did you see this time? Is the account unlocked now?
sudo. What happened this time?
sudoeditcommand. What changes did you make to the sudoers file for this?
Red Hat has (finally) documented PAM in the
man pam for an overview.
(On other systems look for PAM documentation in
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
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
For Red Hat systems the
system-auth file is
regenerated whenever the
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
Linux has a file
(similar to Solaris's
This file is part of the shadow suite and is used to
specify a number of settings used by
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
the command will ensure the new password meets the
policy requirements from both PAM as well as
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_pwquality, but provides
other methods of configuring
As of Solaris 10
pam_unix has been replaced with
a number of new modules.
pam_authtok_check module to set password
strength criteria, similar to
pam_pwquality, you don't pass any options to
It is configured by settings in
Remember you can use your
YborStudent account to read
man pages and other documentation, and to examine
/etc/pam.d/* configuration files.
This should make it easier to work from off-campus.
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.