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:
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
72a73,74
> # Allow any one to use chfn
> CHFN_RESTRICT no
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?
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.)
sudo Configuration 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.)
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.)
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? 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? 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?
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 17c17 < UserDir disabled --- > # UserDir disabled 24c24 < #UserDir public_html --- > UserDir public_html
After making this change, restart the web server and verify it is running.
index.html” in your
(non-root user's) ~/public_html directory, with the following
contents:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Sample Web Page</title>
</head>
<body>
<h1>If you can see this text, it works!</h1>
</body>
</html>
Make sure this file is readable by everyone.
http://localhost/~yourUserName/
(only substitute your user name of course).
What was the result?
(Did you see your web page display correctly?)
Forbidden
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?
access_log and
error_log.
Which log files (if any) contained relevant log
messages?
What did the messages (if any) mean?
(Say in your own words.)
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.
# 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?
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?
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!
# 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.
# 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.)
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.
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.
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.