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 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:
chfn configuration so that only
the system administrator can modify a user's finger
information. wheel group authentication.
(Any user who is a member of the group wheel is
considered an administrator with the same security privileges
as the root user.
Such a user can use the su command without
supplying a password.)
Add your user account to the group wheel.
Now logout and then login again.
Try to use su to verify your PAM changes worked.
login.defs.
(Note the documentation for pam_cracklib 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.)
sudo Configuration auserroot):
# useradd -c "Ann User" -m auser
# passwd auser
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
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? 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
sudo:
passwd -u auser
What output did you see this time?
Is the account unlocked now? sudo.
What happened this time? /etc/hosts using the sudoedit
command.
What changes did you make to the sudoers
file for this?
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 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_cracklib.
(Unlike pam_cracklib 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.
A copy of your journal pages. 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.