Colvard's Logical Premises:
All probabilities are 50%. Either a thing will happen or
it won't.
Colvard's Unconscionable Commentary:
This is especially true when dealing with someone you're
attracted to.
Grelb's Commentary
Likelihoods, however, are 90% against you.
You will be adding a new script to your system to perform auto-updates to your machine on a weekly basis. You will also be configuring an Network Time Protocol (NTP) server on your machine in order to keep your clock synced with the rest of campus (and hopefully the world). You will also be adding some password restrictions to your Pluggable Authentication Modules (PAM) configuration to force strong passwords as well as no re-use of previous passwords.
In this lab (and subsequent labs), I will be simply giving you a list of things to do, and links to pages on the internet that have all of the information you need to complete the tasks set in front of you.
For your reading, you can take a look at these pages for auto-update, NTP, and PAM configuration information.
This lab is due at 9:30am, Tuesday Feb 19th, 2008.
You must complete all the following tasks for this lab.
libpam-cracklib' package on your machine. This will also install packages cracklib-runtime, cracklib2, dictionaries-common, and wfinnish./etc/pam.d/common-password'. I require that passwords are at least eight (8) characters in length. Beware the credits that pam_cracklib gives you for certain special characters! Look at the documentation for the pam_cracklib module for more information on the arguments for pam_cracklib. You may also find this documentation on enforcing strong passwords to be helpful.pam_unix' module. Look at the documentation for the pam_unix module, specifically the section regarding the use of pam_unix in the password component type. You may also find this documentation on restricting use of previous passwords to be useful.ntpdate time-a.nist.gov in a terminal (as root). If you have trouble with sudo commands after you run this command, check the clarifications section below for how to fix this problem.ntp-server' package./etc/ntp.conf' to query servers 'time.colorado.edu', 'time.nist.gov', and 'time-a.nist.gov'.The file /etc/pam.d/common-password already has the two lines you need for the lab commented out. These lines are NOT complete and you will have to configure them properly to match the rules I set above for this lab. You will need to first comment out the only line in the file that is active, and uncomment the other two, and then spend the quality time necessary to enforce passwords strength and password re-use restriction.
I mentioned above in the requirements that you must pay close attention to how the pam_cracklib module gives 'credits' for using special characters. I will be testing with different passwords with many types of characters, and ALL of them must be enforced by the system to be at least 8 characters long.
This problem arises when trying to save previous passwords with the pam_unix.so module. The way to solve this problem is by creating the file with which pam_unix.so can save old passwords.
chris@coolname:~$ sudo touch /etc/security/opasswd
The documentation for the 'remember' option does specify that this file is used to remember old passwords, but does not say how it handles things if the file doesn't exist. Basically it just errors out without telling you why.
"remember=n"
"The last n passwords for each user are saved in /etc/security/opasswd in order to force
password change history and keep the user from alternating between the same password
too frequently."
To test the NTP settings, we need to change our system time. To print the time and date we can use the 'date' command. Well this is all good and everything but how do we set the time? Well actually by using the same command. If we take a look at the man pages for date we see that setting the date has the following format:
% date MMDDhhmm
So if we wanted to set the clock to April 12 2:09 am we can just type:
% date 04120209
Two important notes about NTP is that NTPD is a daemon with a startup script in /etc/init.d, and the daemon barfs and quits if the system time is +/- 10 minutes from the actual time. You will see a log entry in your syslog like the following:
Feb 21 21:35:49 coolname ntpd[6359]: time correction of 53015 seconds exceeds sanity limit (1000); <wrap> set clock manually to the correct UTC time.
So if you are going to test your machine, you may first set your clock using the following command (when NTPD is not running):
chris@coolname:~$ sudo ntpdate time.colorado.edu 22 Feb 12:22:47 ntpdate[6406]: step time server 128.138.82.156 offset 53014.853909 sec
...and then set your clock ahead 5 minutes using the date command and restart NTPD and see if your clock gets set to the correct time.
NTPD does not immediately synchronize your clock to the NTP servers that you list in ntp.conf. The command 'ntpdate' will immediately synchronize your time, which is why I have you run it FIRST, and then enable NTPD. The way to tell whether or not NTPD is doing what it should is to check your log files. Logs will save you a lot of pain and heartache when trying to debug a problem (although not always true). The log file for you to look at specifically '/var/log/syslog'.
Lines you want to look for are the following (from class machine flamingweasel):
Feb 18 16:39:30 flamingweasel ntpd[3857]: synchronized to 128.138.82.156, stratum 2 Feb 18 16:39:35 flamingweasel ntpd[3857]: synchronized to 129.6.15.28, stratum 1
Sudo keeps timestamps of the last time you were required to type your password to run a command with sudo. These timestamps exist in '/var/run/sudo/<username>'. You'll notice in this directory has files with numbers. Those numbers are associated with each tty you currently have open. You can check which tty you have per terminal with the following command:
chris@coolname:~$ who am i chris pts/0 2007-02-27 10:34 (supervillian.cs.colorado.edu)
Notice the 'pts/0'. If I look in '/var/run/sudo/chris' I'll see files for that tty (and any others I may have open):
chris@coolname:~$ sudo ls -l /var/run/sudo/chris -rw------- 1 root root 0 2007-02-28 03:00 0
The timestamp of the file (which is actually the modified time, mtime) is what sudo uses to track the last authentication time.
Now if the current time of the machine is too far BEHIND the timestamp on the above file, sudo will barf and not allow you to do anything. What needs to happen are those files need to be removed from your '/var/run/sudo/<username>' directory. There are two ways you can fix this situation:
One caveat with 'Recovery Mode' is that if you have set a root password at all, you must enter it before it gives you a root shell.