2000-04-26 18:26:31 +00:00
|
|
|
<!doctype linuxdoc system>
|
|
|
|
|
|
|
|
<!-- This is the Linux Shadow Password HOWTO, please forward any comments
|
|
|
|
or suggestions to the author: mhjack@tscnet.com -->
|
|
|
|
|
|
|
|
<article>
|
|
|
|
|
|
|
|
<!-- Title information -->
|
|
|
|
|
|
|
|
<title>Linux Shadow Password HOWTO
|
|
|
|
<author>Michael H. Jackson, <tt>mhjack@tscnet.com</tt>
|
|
|
|
<date>v1.3, 3 April 1996
|
|
|
|
|
|
|
|
<abstract>
|
|
|
|
This document aims to describe how to obtain, install, and configure the Linux
|
2016-01-17 22:23:53 +00:00
|
|
|
password Shadow Suite. It also discusses obtaining, and
|
|
|
|
[re]installing other software and network daemons that require access to user
|
2000-04-26 18:26:31 +00:00
|
|
|
passwords. This other software is not actually part of the Shadow Suite, but
|
2016-01-17 22:23:53 +00:00
|
|
|
these programs will need to be recompiled to support the Shadow
|
|
|
|
Suite. This document also contains a programming example for adding
|
2000-04-26 18:26:31 +00:00
|
|
|
shadow support to a program. Answers to some of the more frequently asked
|
|
|
|
questions are included near the end of this document.
|
|
|
|
</abstract>
|
|
|
|
|
|
|
|
<!-- Table of contents -->
|
|
|
|
<toc>
|
|
|
|
|
|
|
|
<!-- Begin the document -->
|
|
|
|
|
|
|
|
<sect><heading>Introduction.
|
|
|
|
<p>
|
|
|
|
This is the Linux Shadow-Password-HOWTO. This document describes why and how
|
|
|
|
to add shadow password support on a Linux system. Some examples of how to
|
|
|
|
use some of the <em>Shadow Suite's</em> features is also included.
|
|
|
|
<p>
|
|
|
|
When installing the <em>Shadow Suite</em> and when using many of the utility
|
|
|
|
programs, you must be logged in as <em>root</em>. When installing the
|
|
|
|
<em>Shadow Suite</em> you will be making changes to system software, and it
|
|
|
|
is highly recommended that you make backup copies of programs as indicated.
|
|
|
|
I also recommend that you read and understand all the instructions before
|
|
|
|
you begin.
|
|
|
|
|
|
|
|
<sect1><heading>Changes from the previous release.
|
|
|
|
<p>
|
|
|
|
<verb>Additions:
|
|
|
|
Added a sub-section on why you might not want to install shadow
|
|
|
|
Added a sub-section on updating the xdm program
|
|
|
|
Added a section on how to put Shadow Suite features to work
|
|
|
|
Added a section containing frequently asked questions
|
|
|
|
|
|
|
|
Corrections/Updates:
|
|
|
|
Corrected html references on Sunsite
|
|
|
|
Corrected section on wu-ftp to reflect adding -lshadow to the Makefile
|
|
|
|
Corrected minor spelling and verbiage errors
|
|
|
|
Changed section on wu-ftpd to support ELF
|
|
|
|
Updated to reflect security problems in various login programs
|
|
|
|
Updated to recommend the Linux Shadow Suite by Marek Michalkiewicz
|
|
|
|
|
|
|
|
</verb>
|
|
|
|
|
|
|
|
<sect1><heading>New versions of this document.
|
|
|
|
<p>
|
|
|
|
The latest released version of this document can always be retrieved by
|
|
|
|
anonymous FTP from:
|
|
|
|
|
|
|
|
<bf>sunsite.unc.edu</bf>
|
|
|
|
<verb>/pub/Linux/docs/HOWTO/Shadow-Password-HOWTO</verb>
|
|
|
|
or:
|
|
|
|
<verb>/pub/Linux/docs/HOWTO/other-formats/Shadow-Password-HOWTO{-html.tar,ps,dvi}.gz</verb>
|
|
|
|
|
|
|
|
or via the World Wide Web from the
|
|
|
|
<url url="http://sunsite.unc.edu/mdw/linux.html"
|
|
|
|
name="Linux Documentation Project Web Server">, at page:
|
|
|
|
<url url="http://sunsite.unc.edu/linux/HOWTO/Shadow-Password-HOWTO.html"
|
|
|
|
name="Shadow-Password-HOWTO">
|
|
|
|
or directly from me, <tt><mhjack@tscnet.com></tt>. It will
|
|
|
|
also be posted to the newsgroup: <tt>comp.os.linux.answers</tt>
|
|
|
|
<p>
|
|
|
|
This document is now packaged with the Shadow-YYDDMM packages.
|
|
|
|
|
|
|
|
|
|
|
|
<sect1><heading>Feedback.
|
|
|
|
<p>
|
|
|
|
Please send any comments, updates, or suggestions to me:
|
|
|
|
<htmlurl url="mailto:mhjack@tscnet.com"
|
|
|
|
name="Michael H. Jackson <mhjack@tscnet.com>"> The sooner I get feedback,
|
|
|
|
the sooner I can update and correct this document. If you find any problems
|
|
|
|
with it, please mail me directly as I very rarely stay up-to-date on the
|
|
|
|
newsgroups.
|
|
|
|
|
|
|
|
<sect><heading>Why shadow your passwd file?
|
|
|
|
<p>
|
|
|
|
By default, most current Linux distributions do not contain the
|
|
|
|
<em>Shadow Suite</em> installed. This includes Slackware 2.3, Slackware 3.0,
|
|
|
|
and other popular distributions. One of the reasons for this is that
|
|
|
|
the copyright notices in the original <em>Shadow Suite</em> were not clear
|
|
|
|
on redistribution if a fee was charged. Linux uses a GNU Copyright
|
|
|
|
(sometimes refereed to as a Copyleft) that allows people to package it into a
|
|
|
|
convenient package (like a CD-ROM distribution) and charge a fee for it.
|
|
|
|
<p>
|
|
|
|
The current maintainer of the <em>Shadow Suite</em>, <htmlurl
|
|
|
|
url="mailto:marekm@i17linuxb.ists.pwr.wroc.pl"
|
|
|
|
name="Marek Michalkiewicz <marekm@i17linuxb.ists.pwr.wroc.pl>">
|
|
|
|
received the source code from the original author under a BSD style
|
|
|
|
copyright that allowed redistribution. Now that the copyright issues
|
|
|
|
are resolved, it is expected that future distributions will contain
|
|
|
|
password shadowing by default. Until then, you will need to install it
|
|
|
|
yourself.
|
|
|
|
<p>
|
|
|
|
If you installed your distribution from a CD-ROM, you may find that, even
|
|
|
|
though the distribution did not have the <em>Shadow Suite</em> installed,
|
|
|
|
some of the files you need to install the <em>Shadow Suite</em> may be on
|
|
|
|
the CD-ROM.
|
|
|
|
<p>
|
|
|
|
<em>However, Shadow Suite versions 3.3.1, 3.3.1-2, and shadow-mk all have
|
|
|
|
security problems with their login program and several other <em>suid
|
|
|
|
root</em> programs that came with them, and should no longer be used.</em>
|
|
|
|
<p>
|
|
|
|
All of the necessary files may be obtained via anonymous FTP or through the
|
|
|
|
World Wide Web.
|
|
|
|
<p>
|
|
|
|
On a Linux system without the <em>Shadow Suite</em> installed, user
|
|
|
|
information including passwords is stored in the <tt>/etc/passwd</tt> file.
|
|
|
|
The password is stored in an <em>encrypted</em> format. If you ask a
|
|
|
|
cryptography expert, however, he or she will tell you that the password
|
|
|
|
is actually in an <em>encoded</em> rather than <em>encrypted</em> format
|
|
|
|
because when using crypt(3), the text is set to null and the password is the
|
|
|
|
key. Therefore, from here on, I will use the term <em>encoded</em> in this
|
|
|
|
document.
|
|
|
|
<p>
|
|
|
|
The algorithm used to encode the password field is technically
|
|
|
|
referred to as a <em>one way hash function</em>. This is an algorithm that
|
|
|
|
is easy to compute in one direction, but very difficult to calculate in the
|
|
|
|
reverse direction. More about the actual algorithm used can be found
|
|
|
|
in section 2.4 or your crypt(3) manual page.
|
|
|
|
<p>
|
|
|
|
When a user picks or is assigned a password, it is encoded with a randomly
|
|
|
|
generated value called the <em>salt</em>. This means that any particular
|
|
|
|
password could be stored in 4096 different ways. The <em>salt</em> value
|
|
|
|
is then stored with the encoded password.
|
|
|
|
<p>
|
|
|
|
When a user logs in and supplies a password, the <em>salt</em> is first
|
|
|
|
retrieved from the stored encoded password. Then the supplied password is
|
|
|
|
<em>encoded</em> with the <em>salt</em> value, and then compared with the
|
|
|
|
<em>encoded</em> password. If there is a match, then the user is
|
|
|
|
authenticated.
|
|
|
|
<p>
|
|
|
|
It is computationally difficult (but not impossible) to take a randomly
|
|
|
|
<em>encoded</em> password and recover the original password. However, on
|
|
|
|
any system with more than just a few users, at least some of the passwords
|
|
|
|
will be common words (or simple variations of common words).
|
|
|
|
<p>
|
|
|
|
System crackers know all this, and will simply encrypt a dictionary of
|
|
|
|
words and common passwords using all possible 4096 <em>salt</em> values.
|
|
|
|
Then they will compare the encoded passwords in your <tt>/etc/passwd</tt>
|
|
|
|
file with their database. Once they have found a match, they have the
|
|
|
|
password for another account. This is referred to as a <em>dictionary
|
|
|
|
attack</em>, and is one of the most common methods for gaining or expanding
|
|
|
|
unauthorized access to a system.
|
|
|
|
<p>
|
|
|
|
If you think about it, an 8 character password encodes to 4096 * 13 character
|
|
|
|
strings. So a dictionary of say 400,000 common words, names, passwords, and
|
|
|
|
simple variations would easily fit on a 4GB hard drive. The attacker need
|
|
|
|
only sort them, and then check for matches. Since a 4GB hard drive can be
|
|
|
|
had for under $1000.00, this is well within the means of most system
|
|
|
|
crackers.
|
|
|
|
<p>
|
|
|
|
Also, if a cracker obtains your <tt>/etc/passwd</tt> file first, they only
|
|
|
|
need to encode the dictionary with the <tt>salt</tt> values actually
|
|
|
|
contained in your <tt>/etc/passwd</tt> file. This method is usable by your
|
|
|
|
average teenager with a couple of hundred spare Megabytes and a 486 class
|
|
|
|
computer.
|
|
|
|
<p>
|
|
|
|
Even without lots of drive space, utilities like crack(1) can usually break
|
|
|
|
at least a couple of passwords on a system with enough users (assuming the
|
|
|
|
users of the system are allowed to pick their own passwords).
|
|
|
|
<p>
|
|
|
|
The <tt>/etc/passwd</tt> file also contains information like user ID's and
|
|
|
|
group ID's that are used by many system programs. Therefore, the
|
|
|
|
<tt>/etc/passwd</tt> file <em>must</em> remain world readable. If you were
|
|
|
|
to change the <tt>/etc/passwd</tt> file so that nobody can read it, the
|
|
|
|
first thing that you would notice is that the <tt>ls -l</tt> command now
|
|
|
|
displays user ID's instead of names!
|
|
|
|
<p>
|
|
|
|
The <em>Shadow Suite</em> solves the problem by relocating the passwords to
|
|
|
|
another file (usually <tt>/etc/shadow</tt>). The <tt>/etc/shadow</tt> file is set so
|
|
|
|
that it cannot be read by just anyone. Only <em>root</em> will be able to
|
|
|
|
read and write to the <tt>/etc/shadow</tt> file. Some programs (like xlock)
|
|
|
|
don't need to be able to change passwords, they only need to be able to
|
|
|
|
verify them. These programs can either be run <em>suid root</em> or you can
|
|
|
|
set up a group <em>shadow</em> that is allowed read only access to the
|
|
|
|
<tt>/etc/shadow</tt> file. Then the program can be run <em>sgid
|
|
|
|
shadow</em>.
|
|
|
|
<p>
|
|
|
|
By moving the passwords to the <tt>/etc/shadow</tt> file, we are effectively
|
|
|
|
keeping the attacker from having access to the encoded passwords with which
|
|
|
|
to perform a <em>dictionary attack</em>.
|
|
|
|
<p>
|
|
|
|
Additionally, the <em>Shadow Suite</em> adds lots of other nice features:
|
|
|
|
<itemize>
|
|
|
|
<item>A configuration file to set login defaults (<tt>/etc/login.defs</tt>)
|
|
|
|
<item>Utilities for adding, modifying, and deleting user accounts and groups
|
|
|
|
<item>Password aging and expiration
|
|
|
|
<item>Account expiration and locking
|
|
|
|
<item>Shadowed group passwords (optional)
|
2016-01-17 22:23:53 +00:00
|
|
|
<item>Double length passwords (16 character passwords) [NOT RECOMMENDED]
|
2000-04-26 18:26:31 +00:00
|
|
|
<item>Better control over user's password selection
|
|
|
|
<item>Dial-up passwords
|
2016-01-17 22:23:53 +00:00
|
|
|
<item>Secondary authentication programs [NOT RECOMMENDED]
|
2000-04-26 18:26:31 +00:00
|
|
|
</itemize>
|
|
|
|
<p>
|
|
|
|
Installing the <em>Shadow Suite</em> contributes toward a more
|
|
|
|
secure system, but there are many other things that can also be done to
|
|
|
|
improve the security of a Linux system, and there will eventually be a
|
|
|
|
series of Linux Security HOWTO's that will discuss other security measures
|
|
|
|
and related issues.
|
|
|
|
<p>
|
|
|
|
For current information on other Linux security issues, including warnings on
|
|
|
|
known vulnerabilities see the <url
|
|
|
|
url="http://bach.cis.temple.edu/linux/linux-security/"
|
|
|
|
name="Linux Security home page.">
|
|
|
|
|
|
|
|
|
|
|
|
<sect1><heading>Why you might NOT want to shadow your passwd file.
|
|
|
|
<p>
|
|
|
|
There are a few circumstances and configurations in which installing the
|
|
|
|
<em>Shadow Suite</em> would <em>NOT</em> be a good idea:
|
|
|
|
<itemize>
|
|
|
|
<item>The machine does not contain user accounts.
|
|
|
|
<item>Your machine is running on a LAN and is using NIS (Network Information
|
|
|
|
Services) to get or supply user names and passwords to other machines on
|
|
|
|
the network. (This can actually be done, but is beyond the scope of this
|
|
|
|
document, and really won't increase security much anyway)
|
|
|
|
<item>Your machine is being used by terminal servers to verify users via NFS
|
|
|
|
(Network File System), NIS, or some other method.
|
|
|
|
<item>Your machine runs other software that validates users, and there is no
|
|
|
|
shadow version available, and you don't have the source code.
|
|
|
|
</itemize>
|
|
|
|
|
|
|
|
|
|
|
|
<sect1><heading>Format of the /etc/passwd file
|
|
|
|
<p>
|
|
|
|
A non-shadowed <tt>/etc/passwd</tt> file has the following format:
|
|
|
|
<tscreen><verb>username:passwd:UID:GID:full_name:directory:shell</verb></tscreen>
|
|
|
|
Where:
|
|
|
|
<descrip>
|
|
|
|
<tag/<tt>username</tt></tag> The user (login) name
|
|
|
|
<tag/<tt>passwd</tt></tag> The encoded password
|
|
|
|
<tag/<tt>UID</tt></tag> Numerical user ID
|
|
|
|
<tag/<tt>GID</tt></tag> Numerical default group ID
|
|
|
|
<tag/<tt>full_name</tt></tag> The user's full name - Actually this field is
|
|
|
|
called the GECOS (General Electric Comprehensive Operating System) field
|
|
|
|
and can store information other than just the full name. The Shadow
|
|
|
|
commands and manual pages refer to this field as the comment field.
|
|
|
|
<tag/<tt>directory</tt></tag> User's home directory (Full pathname)
|
|
|
|
<tag/<tt>shell</tt></tag> User's login shell (Full Pathname)
|
|
|
|
</descrip>
|
|
|
|
For example:
|
|
|
|
<tscreen><verb>username:Npge08pfz4wuk:503:100:Full Name:/home/username:/bin/sh</verb></tscreen>
|
|
|
|
Where <tt>Np</tt> is the salt and <tt>ge08pfz4wuk</tt> is the <em>encoded</em>
|
|
|
|
password. The encoded salt/password could just as easily have been
|
|
|
|
<tt>kbeMVnZM0oL7I</tt> and the two are exactly the same password. There are
|
|
|
|
4096 possible encodings for the same password. (The example password in
|
|
|
|
this case is 'password', a really <em>bad</em> password).
|
|
|
|
<p>
|
|
|
|
Once the shadow suite is installed, the <tt>/etc/passwd</tt> file would
|
|
|
|
instead contain:
|
|
|
|
<tscreen><verb>username:x:503:100:Full Name:/home/username:/bin/sh</verb></tscreen>
|
|
|
|
The <tt>x</tt> in the second field in this case is now just a place holder.
|
|
|
|
The format of the <tt>/etc/passwd</tt> file really didn't change, it just no
|
|
|
|
longer contains the <em>encoded</em> password. This means that any program
|
|
|
|
that reads the <tt>/etc/passwd</tt> file but does not actually need to verify
|
|
|
|
passwords will still operate correctly.
|
|
|
|
<p>
|
|
|
|
The passwords are now relocated to the shadow file (usually
|
|
|
|
<tt>/etc/shadow</tt> file).
|
|
|
|
|
|
|
|
<sect1><heading>Format of the shadow file
|
|
|
|
<p>
|
|
|
|
The <tt>/etc/shadow</tt> file contains the following information:
|
|
|
|
<tscreen><verb>username:passwd:last:may:must:warn:expire:disable:reserved</verb></tscreen>
|
|
|
|
Where:
|
|
|
|
<descrip>
|
|
|
|
<tag/<tt>username</tt></tag> The User Name
|
|
|
|
<tag/<tt>passwd</tt></tag> The Encoded password
|
|
|
|
<tag/<tt>last</tt></tag> Days since Jan 1, 1970 that password was last changed
|
|
|
|
<tag/<tt>may</tt></tag> Days before password may be changed
|
|
|
|
<tag/<tt>must</tt></tag> Days after which password must be changed
|
|
|
|
<tag/<tt>warn</tt></tag> Days before password is to expire that user is warned
|
|
|
|
<tag/<tt>expire</tt></tag> Days after password expires that account is disabled
|
|
|
|
<tag/<tt>disable</tt></tag> Days since Jan 1, 1970 that account is disabled
|
|
|
|
<tag/<tt>reserved</tt></tag> A reserved field
|
|
|
|
</descrip>
|
|
|
|
The previous example might then be:
|
|
|
|
<tscreen><verb>username:Npge08pfz4wuk:9479:0:10000::::</verb></tscreen>
|
|
|
|
|
|
|
|
<sect1><heading>Review of crypt(3).
|
|
|
|
<p>
|
|
|
|
From the crypt(3) manual page:
|
|
|
|
<p>
|
|
|
|
&dquot;<em>crypt</em> is the password encryption function. It is based on
|
|
|
|
the <em>Data Encryption Standard</em> algorithm with variations intended (among
|
|
|
|
other things) to discourage use of hardware implementations of a key search.
|
|
|
|
<p>
|
|
|
|
[The] key is a user's typed password. [The encoded string is all NULLs]
|
|
|
|
<p>
|
|
|
|
[The] <em>salt</em> is a two-character string chosen from the set
|
|
|
|
[a-zA-Z0-9./]. This string is used to perturb the algorithm in one of 4096
|
|
|
|
different ways.
|
|
|
|
<p>
|
|
|
|
By taking the lowest 7 bit[s] of each character of the key, a 56-bit key is
|
|
|
|
obtained. This 56-bit key is used to encrypt repeatedly a constant string
|
|
|
|
(usually a string consisting of all zeros). The returned value points to
|
|
|
|
the encrypted password, a series of 13 printable ASCII characters (the first
|
|
|
|
two characters represent the salt itself). The return value points to static
|
|
|
|
data whose content is overwritten by each call.
|
|
|
|
<p>
|
|
|
|
<bf>Warning:</bf> The key space consists of 2**56 equal 7.2e16 possible values.
|
|
|
|
Exhaustive searches of this key space <bf>are possible</bf> using massively
|
|
|
|
parallel computers. Software, such as <tt>crack(1)</tt>, is available which
|
|
|
|
will search the portion of this key space that is generally used by humans
|
|
|
|
for passwords. Hence, password selection should, at minimum, avoid common
|
|
|
|
words and names. The use of a <tt>passwd(1)</tt> program that checks for
|
|
|
|
crackable passwords during the selection process is recommended.
|
|
|
|
<p>
|
|
|
|
The DES algorithm itself has a few quirks which make the use of the
|
|
|
|
<tt>crypt(3)</tt> interface a very poor choice for anything other than
|
|
|
|
password authentication. If you are planning on using the <tt>crypt(3)</tt>
|
|
|
|
interface for a cryptography project, don't do it: get a good book on
|
|
|
|
encryption and one of the widely available DES libraries.&dquot;
|
|
|
|
<p>
|
|
|
|
Most <em>Shadow Suites</em> contain code for doubling the length of the
|
|
|
|
password to 16 characters. Experts in <tt>des</tt> recommend against this,
|
|
|
|
as the encoding is simply applied first to the left half and then to the
|
|
|
|
right half of the longer password. Because of the way <tt>crypt</tt> works,
|
|
|
|
this may make for a <em>less</em> secure encoded password then if double
|
|
|
|
length passwords were not used in the first place. Additionally, it is less
|
|
|
|
likely that a user will be able to remember a 16 character password.
|
|
|
|
<p>
|
|
|
|
There is development work under way that would allow the authentication
|
|
|
|
algorithm to be replaced with something more secure and with support for
|
|
|
|
longer passwords (specifically the MD5 algorithm) and retain compatibility
|
|
|
|
with the <tt>crypt</tt> method.
|
|
|
|
<p>
|
|
|
|
If you are looking for a good book on encryption, I recommend:
|
|
|
|
<verb>
|
|
|
|
"Applied Cryptography: Protocols, Algorithms, and Source Code in C"
|
|
|
|
by Bruce Schneier <schneier@chinet.com>
|
|
|
|
ISBN: 0-471-59756-2
|
|
|
|
</verb>
|
|
|
|
|
|
|
|
|
|
|
|
<sect><heading>Getting the Shadow Suite.
|
|
|
|
|
|
|
|
<sect1><heading>History of the Shadow Suite for Linux
|
|
|
|
<p>
|
|
|
|
<em>DO NOT USE THE PACKAGES IN THIS SECTION, THEY HAVE SECURITY PROBLEMS</em>
|
|
|
|
<p>
|
|
|
|
The original <em>Shadow Suite</em> was written by <tt>John F. Haugh II</tt>.
|
|
|
|
<p>
|
|
|
|
There are several versions that have been used on Linux systems:
|
|
|
|
<itemize>
|
|
|
|
<item><tt>shadow-3.3.1</tt> is the original.
|
|
|
|
<item><tt>shadow-3.3.1-2</tt> is Linux specific patch made by
|
|
|
|
<htmlurl url="mailto:flla@stud.uni-sb.de"
|
|
|
|
name="Florian La Roche <flla@stud.uni-sb.de>"> and contains some further
|
|
|
|
enhancements.
|
|
|
|
<item><tt>shadow-mk</tt> was specifically packaged for Linux.
|
|
|
|
</itemize>
|
|
|
|
<p>
|
|
|
|
The <tt>shadow-mk</tt> package contains the <tt>shadow-3.3.1</tt> package
|
|
|
|
distributed by <tt>John F. Haugh II</tt> with the <tt>shadow-3.3.1-2 patch</tt>
|
|
|
|
installed, a few fixes made by <htmlurl
|
|
|
|
url="mailto:magnus@texas.net"
|
|
|
|
name="Mohan Kokal <magnus@texas.net>">
|
|
|
|
that make installation a lot easier, a patch by <tt>Joseph R.M. Zbiciak</tt>
|
|
|
|
for <tt>login1.c</tt> (login.secure) that eliminates the -f, -h security
|
|
|
|
holes in /bin/login, and some other miscellaneous patches.
|
|
|
|
<p>
|
|
|
|
The <tt>shadow.mk</tt> package was the <em>previously</em> recommended
|
|
|
|
package, but should be replaced due to a <em>security problem</em> with the
|
|
|
|
<tt>login</tt> program.
|
|
|
|
<p>
|
|
|
|
There are <em>security problems</em> with Shadow versions 3.3.1, 3.3.1-2,
|
|
|
|
and shadow-mk involving the <tt>login</tt> program. This <tt>login</tt> bug
|
|
|
|
involves not checking the length of a login name. This causes the buffer to
|
|
|
|
overflow causing crashes or worse. It has been rumored that this buffer
|
|
|
|
overflow can allow someone with an account on the system to use this bug and
|
|
|
|
the shared libraries to gain <em>root</em> access. I won't discuss exactly
|
|
|
|
how this is possible because there are a lot of Linux systems that are
|
|
|
|
affected, but systems with these <em>Shadow Suites</em> installed, and
|
|
|
|
most pre-ELF distributions <em>without</em> the <em>Shadow Suite</em>
|
|
|
|
are vulnerable!
|
|
|
|
<p>
|
|
|
|
For more information on this and other Linux security issues, see the <url
|
|
|
|
url="http://bach.cis.temple.edu/linux/linux-security/Linux-Security-FAQ/Linux-telnetd.html"
|
|
|
|
name="Linux Security home page (Shared Libraries and login Program
|
|
|
|
Vulnerability)">
|
|
|
|
|
|
|
|
|
|
|
|
<sect1><heading>Where to get the Shadow Suite.
|
|
|
|
<p>
|
|
|
|
The only recommended <em>Shadow Suite</em> is still in BETA testing, however
|
|
|
|
the latest versions are safe in a production environment and don't contain a
|
|
|
|
vulnerable <tt>login</tt> program.
|
|
|
|
<p>
|
|
|
|
The package uses the following naming convention:
|
|
|
|
<tscreen><verb>shadow-YYMMDD.tar.gz</verb></tscreen>
|
|
|
|
where <tt>YYMMDD</tt> is the issue date of the Suite.
|
|
|
|
<p>
|
|
|
|
This version will eventually be <em>Version 3.3.3</em> when it is released
|
|
|
|
from Beta testing, and is maintained by
|
|
|
|
<htmlurl
|
|
|
|
url="mailto:marekm@i17linuxb.ists.pwr.wroc.pl" name="Marek Michalkiewicz <marekm@i17linuxb.ists.pwr.wroc.pl>">.
|
|
|
|
It's available as:
|
|
|
|
<url
|
|
|
|
url="ftp://i17linuxb.ists.pwr.wroc.pl/pub/linux/shadow/shadow-current.tar.gz"
|
|
|
|
name="shadow-current.tar.gz">.
|
|
|
|
<p>
|
|
|
|
The following mirror sites have also been established:
|
|
|
|
<itemize>
|
|
|
|
<item><htmlurl url="ftp://ftp.icm.edu.pl/pub/Linux/shadow/shadow-current.tar.gz"
|
|
|
|
name="ftp://ftp.icm.edu.pl/pub/Linux/shadow/shadow-current.tar.gz">
|
|
|
|
<item><htmlurl url="ftp://iguana.hut.fi/pub/linux/shadow/shadow-current.tar.gz"
|
|
|
|
name="ftp://iguana.hut.fi/pub/linux/shadow/shadow-current.tar.gz">
|
|
|
|
<item><htmlurl url="ftp://ftp.cin.net/usr/ggallag/shadow/shadow-current.tar.gz"
|
|
|
|
name="ftp://ftp.cin.net/usr/ggallag/shadow/shadow-current.tar.gz">
|
|
|
|
<item><htmlurl url="ftp://ftp.netural.com/pub/linux/shadow/shadow-current.tar.gz"
|
|
|
|
name="ftp://ftp.netural.com/pub/linux/shadow/shadow-current.tar.gz">
|
|
|
|
</itemize>
|
|
|
|
<p>
|
|
|
|
You should use the currently available version.
|
|
|
|
<p>
|
|
|
|
You should NOT use a version <em>older</em> than <tt>shadow-960129</tt> as
|
|
|
|
they also have the <tt>login</tt> security problem discussed above.
|
|
|
|
<p>
|
|
|
|
When this document refers to the <em>Shadow Suite</em> I am referring to the
|
|
|
|
this package. It is assumed that this is the package that you are using.
|
|
|
|
<p>
|
|
|
|
For reference, I used <tt>shadow-960129</tt> to make these installation
|
|
|
|
instructions.
|
|
|
|
<p>
|
|
|
|
If you were previously using <tt>shadow-mk</tt>, you should upgrade to this
|
|
|
|
version and rebuild everything that you originally compiled.
|
|
|
|
|
|
|
|
<sect1><heading>What is included with the Shadow Suite.
|
|
|
|
<p>
|
|
|
|
The <em>Shadow Suite</em> contains replacement programs for:
|
|
|
|
<p>
|
|
|
|
<tt>su, login, passwd, newgrp, chfn, chsh, and id</tt>
|
|
|
|
<p>
|
|
|
|
The package also contains the new programs:
|
|
|
|
<p>
|
|
|
|
<tt>chage, newusers, dpasswd, gpasswd, useradd, userdel, usermod, groupadd,
|
|
|
|
groupdel, groupmod, groups, pwck, grpck, lastlog, pwconv, and pwunconv</tt>
|
|
|
|
<p>
|
|
|
|
Additionally, the library: <tt>libshadow.a</tt> is included for writing and/or
|
|
|
|
compiling programs that need to access user passwords.
|
|
|
|
<p>
|
|
|
|
Also, manual pages for the programs are also included.
|
|
|
|
<p>
|
|
|
|
There is also a configuration file for the login program which will be
|
|
|
|
installed as <tt>/etc/login.defs</tt>.
|
|
|
|
|
|
|
|
<sect><heading>Compiling the programs.
|
|
|
|
|
|
|
|
<sect1><heading>Unpacking the archive.
|
|
|
|
<p>
|
|
|
|
The first step after retrieving the package is unpacking it. The package
|
|
|
|
is in the tar (tape archive) format and compressed using gzip, so first move
|
|
|
|
it to <tt>/usr/src</tt>, then type:
|
|
|
|
<tscreen><verb>tar -xzvf shadow-current.tar.gz</verb></tscreen>
|
|
|
|
<p>
|
|
|
|
This will unpack it into the directory: <tt>/usr/src/shadow-YYMMDD</tt>
|
|
|
|
|
|
|
|
<sect1><heading>Configuring with the config.h file
|
|
|
|
<p>
|
|
|
|
The first thing that you need to do is to copy over the <tt>Makefile</tt>
|
|
|
|
and the <tt>config.h</tt> file:
|
|
|
|
<tscreen><verb>cd /usr/src/shadow-YYMMDD
|
|
|
|
cp Makefile.linux Makefile
|
|
|
|
cp config.h.linux config.h</verb></tscreen>
|
|
|
|
<p>
|
|
|
|
You should then take a look at the <tt>config.h</tt> file. This file
|
|
|
|
contains definitions for some of the configuration options. If you are
|
|
|
|
using the <em>recommended</em> package, I recommend that you disable group
|
|
|
|
shadow support for your first time around.
|
|
|
|
<p>
|
|
|
|
By default shadowed group passwords are enabled. To disable these edit the
|
|
|
|
<tt>config.h</tt> file, and change the <tt>#define SHADOWGRP</tt> to
|
|
|
|
<tt>#undef SHADOWGRP</tt>. I recommend that you disable them to start
|
|
|
|
with, and then if you really want group passwords and group administrators
|
|
|
|
that you enable it later and recompile. If you leave it enabled, you
|
|
|
|
<em>must</em> create the file <tt>/etc/gshadow</tt>.
|
|
|
|
<p>
|
|
|
|
Enabling the long passwords option is NOT recommended as discussed above.
|
|
|
|
<p>
|
|
|
|
<em>Do NOT</em> change the setting: <tt>#undef AUTOSHADOW</tt>
|
|
|
|
<p>
|
|
|
|
The <tt>AUTOSHADOW</tt> option was originally designed so that programs
|
|
|
|
that were shadow ignorant would still function. This sounds good in theory,
|
|
|
|
but does not work correctly. If you enable this option, and the program runs
|
|
|
|
as root, it may call <tt>getpwnam()</tt> as root, and later write the modified
|
|
|
|
entry back to the <tt>/etc/passwd</tt> file (with the <em>no-longer-shadowed
|
|
|
|
password</em>). Such programs include chfn and chsh. (You can't get around
|
|
|
|
this by swapping real and effective uid before calling <tt>getpwnam()</tt>
|
|
|
|
because root may use chfn and chsh too.)
|
|
|
|
<p>
|
|
|
|
The same warning is also valid if you are building libc, it has a
|
|
|
|
<tt>SHADOW_COMPAT</tt> option which does the same thing. It <em>should
|
|
|
|
NOT</em> be used! If you start getting encoded passwords back in your
|
|
|
|
<tt>/etc/passwd</tt> file, this is the problem.
|
|
|
|
<p>
|
|
|
|
If you are using a <tt>libc</tt> version prior to 4.6.27, you will need to
|
|
|
|
make a couple more changes to <tt>config.h</tt> and the <tt>Makefile</tt>.
|
|
|
|
To <tt>config.h</tt> edit and change:
|
|
|
|
<tscreen><verb>#define HAVE_BASENAME</verb></tscreen>
|
|
|
|
to:
|
|
|
|
<tscreen><verb>#undef HAVE_BASENAME</verb></tscreen>
|
|
|
|
And then in the <tt>Makefile</tt>, change:
|
|
|
|
|
|
|
|
<tscreen><verb>SOBJS = smain.o env.o entry.o susetup.o shell.o \
|
|
|
|
sub.o mail.o motd.o sulog.o age.o tz.o hushed.o
|
|
|
|
|
|
|
|
SSRCS = smain.c env.c entry.c setup.c shell.c \
|
|
|
|
pwent.c sub.c mail.c motd.c sulog.c shadow.c age.c pwpack.c rad64.c \
|
|
|
|
tz.c hushed.c
|
|
|
|
</verb></tscreen>
|
|
|
|
<tscreen><verb>SOBJS = smain.o env.o entry.o susetup.o shell.o \
|
|
|
|
sub.o mail.o motd.o sulog.o age.o tz.o hushed.o basename.o
|
|
|
|
|
|
|
|
SSRCS = smain.c env.c entry.c setup.c shell.c \
|
|
|
|
pwent.c sub.c mail.c motd.c sulog.c shadow.c age.c pwpack.c rad64.c \
|
|
|
|
tz.c hushed.c basename.c
|
|
|
|
</verb></tscreen>
|
|
|
|
These changes add the code contained in <tt>basename.c</tt> which is
|
|
|
|
contained in <tt>libc 4.6.27</tt> and later.
|
|
|
|
|
|
|
|
<sect1><heading>Making backup copies of your original programs.
|
|
|
|
<p>
|
|
|
|
It would also be a good idea to track down and make backup copies of the
|
|
|
|
programs that the shadow suite will replace. On a Slackware 3.0 system
|
|
|
|
these are:
|
|
|
|
<itemize>
|
|
|
|
<item>/bin/su
|
|
|
|
<item>/bin/login
|
|
|
|
<item>/usr/bin/passwd
|
|
|
|
<item>/usr/bin/newgrp
|
|
|
|
<item>/usr/bin/chfn
|
|
|
|
<item>/usr/bin/chsh
|
|
|
|
<item>/usr/bin/id
|
|
|
|
</itemize>
|
|
|
|
<p>
|
|
|
|
The BETA package has a <em>save</em> target in the Makefile, but it's
|
|
|
|
commented out because different distributions place the programs in
|
|
|
|
different places.
|
|
|
|
<p>
|
|
|
|
You should also make a backup copy of your <tt>/etc/passwd</tt> file, but be
|
|
|
|
careful to name it something else if you place it in the same directory
|
|
|
|
so you don't overwrite the <tt>passwd</tt> command.
|
|
|
|
|
|
|
|
<sect1><heading>Running make
|
|
|
|
<p>
|
|
|
|
<em>You need to be logged as root to do most of the installation</em>.
|
|
|
|
<p>
|
|
|
|
Run make to compile the executables in the package:
|
|
|
|
<tscreen><verb>make all</verb></tscreen>
|
|
|
|
<p>
|
|
|
|
You may see the warning: <tt>rcsid defined but not used</tt>. This is fine,
|
|
|
|
it just happens because the author is using a version control package.
|
|
|
|
|
|
|
|
<sect><heading>Installing
|
|
|
|
|
|
|
|
<sect1><heading>Have a boot disk handy in case you break anything.
|
|
|
|
<p>
|
|
|
|
If something goes terribly wrong, it would be handy to have a boot disk.
|
|
|
|
If you have a boot/root combination from your installation, that will work,
|
|
|
|
otherwise see the <url url="http://sunsite.unc.edu/mdw/HOWTO/Bootdisk-HOWTO.html"
|
|
|
|
name="Bootdisk-HOWTO">, which describes how to make a bootable disk.
|
|
|
|
|
|
|
|
<sect1><heading>Removing duplicate man pages
|
|
|
|
<p>
|
|
|
|
You should also move the manual pages that are about to be replaced. Even
|
|
|
|
if you are brave enough install the Shadow Suite without making backups, you
|
|
|
|
will still want to remove the old manual pages. The new manual pages won't
|
|
|
|
normally overwrite the old ones because the old ones are probably compressed.
|
|
|
|
<p>
|
|
|
|
You can use a combination of: <tt>man -aW command</tt> and <tt>locate
|
|
|
|
command</tt> to locate the manual pages that need to be (re)moved. It's
|
|
|
|
generally easier to figure out which are the older pages before you run
|
|
|
|
<tt>make install</tt>.
|
|
|
|
<p>
|
|
|
|
If you are using the Slackware 3.0 distribution, then the manual pages you
|
|
|
|
want to remove are:
|
|
|
|
<itemize>
|
|
|
|
<item>/usr/man/man1/chfn.1.gz
|
|
|
|
<item>/usr/man/man1/chsh.1.gz
|
|
|
|
<item>/usr/man/man1/id.1.gz
|
|
|
|
<item>/usr/man/man1/login.1.gz
|
|
|
|
<item>/usr/man/man1/passwd.1.gz
|
|
|
|
<item>/usr/man/man1/su.1.gz
|
|
|
|
<item>/usr/man/man5/passwd.5.gz
|
|
|
|
</itemize>
|
|
|
|
<p>
|
|
|
|
There may also be man pages of the same name in the <tt>/var/man/cat[1-9]</tt>
|
|
|
|
subdirectories that should also be deleted.
|
|
|
|
|
|
|
|
<sect1><heading>Running make install
|
|
|
|
<p>
|
|
|
|
You are now ready to type: (do this as root)
|
|
|
|
<tscreen<verb>make install</verb></tscreen>
|
|
|
|
<p>
|
|
|
|
This will install the new and replacement programs and fix-up the file
|
|
|
|
permissions. It will also install the man pages.
|
|
|
|
<p>
|
|
|
|
This also takes care of installing the Shadow Suite include files in the
|
|
|
|
correct places in <tt>/usr/include/shadow</tt>.
|
|
|
|
<p>
|
|
|
|
Using the BETA package you must manually copy the file <tt>login.defs</tt>
|
|
|
|
to the <tt>/etc</tt> subdirectory and make sure that only <em>root</em> can
|
|
|
|
make changes to it.
|
|
|
|
<tscreen><verb>cp login.defs /etc
|
|
|
|
chmod 700 /etc/login.defs</verb></tscreen>
|
|
|
|
<p>
|
|
|
|
This file is the configuration file for the <em>login</em> program.
|
|
|
|
You should review and make changes to this file for your particular system.
|
|
|
|
This is where you decide which tty's root can login from, and set other
|
|
|
|
security policy settings (like password expiration defaults).
|
|
|
|
|
|
|
|
<sect1><heading>Running pwconv
|
|
|
|
<p>
|
|
|
|
The next step is to run <tt>pwconv</tt>. This must also be done as
|
|
|
|
<em>root</em>, and is best done from the <tt>/etc</tt> subdirectory:
|
|
|
|
<tscreen><verb>cd /etc
|
|
|
|
/usr/sbin/pwconv</verb></tscreen>
|
|
|
|
<p>
|
|
|
|
<tt>pwconv</tt> takes your <tt>/etc/passwd</tt> file and strips out the
|
|
|
|
fields to create two files: <tt>/etc/npasswd</tt> and <tt>/etc/nshadow</tt>.
|
|
|
|
<p>
|
|
|
|
A <tt>pwunconv</tt> program is also provided if you need to make a normal
|
|
|
|
<tt>/etc/passwd</tt> file out of an <tt>/etc/passwd</tt> and
|
|
|
|
<tt>/etc/shadow</tt> combination.
|
|
|
|
|
|
|
|
<sect1><heading>Renaming npasswd and nshadow
|
|
|
|
<p>
|
|
|
|
Now that you have run <tt>pwconv</tt> you have created the files
|
|
|
|
<tt>/etc/npasswd</tt> and <tt>/etc/nshadow</tt>. These need to be copied
|
|
|
|
over to <tt>/etc/passwd</tt> and <tt>/etc/shadow</tt>. We also want to make
|
|
|
|
a backup copy of the original <tt>/etc/passwd</tt> file, and make sure only
|
|
|
|
root can read it. We'll put the backup in root's home directory:
|
|
|
|
<tscreen><verb>cd /etc
|
|
|
|
cp passwd ~passwd
|
|
|
|
chmod 600 ~passwd
|
|
|
|
mv npasswd passwd
|
|
|
|
mv nshadow shadow</verb></tscreen>
|
|
|
|
<p>
|
|
|
|
You should also ensure that the file ownerships and permissions are
|
|
|
|
correct. If you are going to be using <em>X-Windows</em>, the
|
|
|
|
<tt>xlock</tt> and <tt>xdm</tt> programs need to be able to read the
|
|
|
|
<tt>shadow</tt> file (but not write it).
|
|
|
|
<p>
|
|
|
|
There are two ways that this can be done. You can set <tt>xlock</tt> to
|
|
|
|
suid root (<tt>xdm</tt> is usually run as root anyway). Or you can make
|
|
|
|
the <tt>shadow</tt> file owned by <tt>root</tt> with a group of
|
|
|
|
<tt>shadow</tt>, but before you do this, make sure that you have a shadow
|
|
|
|
group (look in <tt>/etc/group</tt>). None of the users on the system
|
|
|
|
should actually be in the shadow group.
|
|
|
|
<tscreen><verb>chown root.root passwd
|
|
|
|
chown root.shadow shadow
|
|
|
|
chmod 0644 passwd
|
|
|
|
chmod 0640 shadow</verb></tscreen>
|
|
|
|
<p>
|
|
|
|
Your system now has the password file shadowed. You <em>should</em> now pop
|
|
|
|
over to another virtual terminal and verify that you can login.
|
|
|
|
<p>
|
|
|
|
<em>Really, do this now!</em>
|
|
|
|
<p>
|
|
|
|
If you can't, then something is wrong! To get back to a non-shadowed state,
|
|
|
|
do the following the following:
|
|
|
|
<tscreen><verb>cd /etc
|
|
|
|
cp ~passwd passwd
|
|
|
|
chmod 644 passwd</verb></tscreen>
|
|
|
|
<p>
|
|
|
|
You would then restore the files that you saved earlier to their proper
|
|
|
|
locations.
|
|
|
|
|
|
|
|
|
|
|
|
<sect><heading>Other programs you may need to upgrade or patch
|
|
|
|
<p>
|
|
|
|
Even though the shadow suite contains replacement programs for most
|
|
|
|
programs that need to access passwords, there are a few additional programs
|
|
|
|
on most systems that require access to passwords.
|
|
|
|
<p>
|
|
|
|
If you are running a <em>Debian Distribution</em> (or even if you are not),
|
|
|
|
you can obtain Debian sources for the programs that need to be rebuild from:
|
|
|
|
ftp://ftp.debian.org/debian/stable/source/
|
|
|
|
<p>
|
|
|
|
The remainder of this section discusses how to upgrade <tt>adduser</tt>,
|
|
|
|
<tt>wu_ftpd</tt>, <tt>ftpd</tt>, <tt>pop3d</tt>, <tt>xlock</tt>,
|
|
|
|
<tt>xdm</tt> and <tt>sudo</tt> so that they support the shadow suite.
|
|
|
|
<p>
|
|
|
|
See the section <ref id="sec-adding" name="Adding Shadow Support to a C program">
|
|
|
|
for a discussion on how to put shadow support into any other program
|
|
|
|
that needs it (although the program must then be run SUID root or SGID shadow
|
|
|
|
to be able to actually access the shadow file).
|
|
|
|
|
|
|
|
<sect1><heading>Slackware adduser program
|
|
|
|
<p>
|
|
|
|
Slackware distributions (and possibly some others) contain a interactive
|
|
|
|
program for adding users called <tt>/sbin/adduser</tt>. A shadow version
|
|
|
|
of this program can be obtained from <htmlurl
|
|
|
|
url="ftp://sunsite.unc.edu/pub/Linux/system/Admin/accounts/adduser.shadow-1.4.tgz"
|
|
|
|
name="ftp://sunsite.unc.edu/pub/Linux/
|
|
|
|
system/Admin/accounts/adduser.shadow-1.4.tar.gz">.
|
|
|
|
<p>
|
|
|
|
I would encourage you to use the programs that are supplied with the
|
|
|
|
<em>Shadow Suite</em> (<tt>useradd</tt>, <tt>usermod</tt>, and
|
|
|
|
<tt>userdel</tt>) instead of the slackware <tt>adduser</tt> program. They
|
|
|
|
take a little time to learn how to use, but it's well worth the effort
|
|
|
|
because you have much more control and they perform proper file locking on
|
|
|
|
the <tt>/etc/passwd</tt> and <tt>/etc/shadow</tt> file (<tt>adduser</tt>
|
|
|
|
doesn't).
|
|
|
|
<p>
|
|
|
|
See the section on
|
|
|
|
<ref id="sec-work" name="Putting the Shadow Suite to use">
|
|
|
|
for more information.
|
|
|
|
<p>
|
|
|
|
But if you gotta have it, here is what you do:
|
|
|
|
<tscreen><verb>tar -xzvf adduser.shadow-1.4.tar.gz
|
|
|
|
cd adduser
|
|
|
|
make clean
|
|
|
|
make adduser
|
|
|
|
chmod 700 adduser
|
|
|
|
cp adduser /sbin</verb></tscreen>
|
|
|
|
|
|
|
|
<sect1><heading>The wu_ftpd Server
|
|
|
|
<p>
|
|
|
|
Most Linux systems some with the <tt>wu_ftpd</tt> server. If your
|
|
|
|
distribution does not come with shadow installed, then your <tt>wu_ftpd</tt>
|
|
|
|
will not be compiled for shadow. <tt>wu_ftpd</tt> is launched from
|
|
|
|
<tt>inetd/tcpd</tt> as a <em>root</em> process. If you are running an old
|
|
|
|
<tt>wu_ftpd</tt> daemon, you will want to upgrade it anyway because older
|
|
|
|
ones had a bug that would allow the <em>root</em> account to be compromised
|
|
|
|
(For more info see the <url
|
|
|
|
url="http://bach.cis.temple.edu/linux/linux-security/Linux-Security-FAQ/Linux-wu.ftpd-2.4-Update.html" name="Linux security home page">).
|
|
|
|
<p>
|
|
|
|
Fortunately, you only need to get the source code and recompile it
|
|
|
|
with shadow enabled.
|
|
|
|
<p>
|
|
|
|
If you are not running an ELF system, The <tt>wu_ftp</tt> server can be
|
|
|
|
found on Sunsite as <url
|
|
|
|
url="ftp://sunsite.unc.edu/pub/Linux/system/Network/file-transfer/wu-ftpd-2.4-fixed.tar.gz"
|
|
|
|
name="wu-ftp-2.4-fixed.tar.gz">
|
|
|
|
<p>
|
|
|
|
Once you retrieve the server, put it in <tt>/usr/src</tt>, then type:
|
|
|
|
<tscreen><verb>cd /usr/src
|
|
|
|
tar -xzvf wu-ftpd-2.4-fixed.tar.gz
|
|
|
|
cd wu-ftpd-2.4-fixed
|
|
|
|
cp ./src/config/config.lnx.shadow ./src/config/config.lnx</verb></tscreen>
|
|
|
|
<p>
|
|
|
|
Then edit <tt>./src/makefiles/Makefile.lnx</tt>, and change the line:
|
|
|
|
<tscreen><verb>LIBES = -lbsd -support</verb></tscreen>
|
|
|
|
to:
|
|
|
|
<tscreen><verb>LIBES = -lbsd -support -lshadow</verb></tscreen>
|
|
|
|
<p>
|
|
|
|
Now you are ready to run the build script and install:
|
|
|
|
<tscreen><verb>cd /usr/src/wu-ftpd-2.4-fixed
|
|
|
|
/usr/src/wu-ftp-2.4.fixed/build lnx
|
|
|
|
cp /usr/sbin/wu.ftpd /usr/sbin/wu.ftpd.old
|
|
|
|
cp ./bin/ftpd /usr/sbin/wu.ftpd</verb></tscreen>
|
|
|
|
<p>
|
|
|
|
This uses the Linux shadow configuration file, compiles and installs
|
|
|
|
the server.
|
|
|
|
<p>
|
|
|
|
On my Slackware 2.3 system I also had to do the following before running
|
|
|
|
<tt>build</tt>:
|
|
|
|
<tscreen><verb>cd /usr/include/netinet
|
|
|
|
ln -s in_systm.h in_system.h
|
|
|
|
cd -</verb></tscreen>
|
|
|
|
<p>
|
|
|
|
Problems have been reported compiling this package under ELF systems, but
|
|
|
|
the Beta version of the next release works fine.
|
|
|
|
It can be found as <url
|
|
|
|
url="ftp://tscnet.com/pub/linux/network/ftp/wu-ftpd-2.4.2-beta-10.tar.gz"
|
|
|
|
name="wu-ftp-2.4.2-beta-10.tar.gz">
|
|
|
|
<p>
|
|
|
|
Once you retrieve the server, put it in <tt>/usr/src</tt>, then type:
|
|
|
|
<tscreen><verb>cd /usr/src
|
|
|
|
tar -xzvf wu-ftpd-2.4.2-beta-9.tar.gz
|
|
|
|
cd wu-ftpd-beta-9
|
|
|
|
cd ./src/config</verb></tscreen>
|
|
|
|
<p>Then edit <tt>config.lnx</tt>, and change:
|
|
|
|
<tscreen><verb>#undef SHADOW.PASSWORD</verb></tscreen>
|
|
|
|
to:
|
|
|
|
<tscreen><verb>#define SHADOW.PASSWORD</verb></tscreen>
|
|
|
|
Then,
|
|
|
|
<tscreen><verb>cd ../Makefiles</verb></tscreen>
|
|
|
|
and edit the file <tt>Makefile.lnx</tt>
|
|
|
|
and change:
|
|
|
|
<tscreen><verb>LIBES = -lsupport -lbsd # -lshadow</verb></tscreen>
|
|
|
|
to:
|
|
|
|
<tscreen><verb>LIBES = -lsupport -lbsd -lshadow</verb></tscreen>
|
|
|
|
Then build and install:
|
|
|
|
<tscreen><verb>cd ..
|
|
|
|
build lnx
|
|
|
|
cp /usr/sbin/wu.ftpd /usr/sbin/wu.ftpd.old
|
|
|
|
cp ./bin/ftpd /usr/sbin/wu.ftpd</verb></tscreen>
|
|
|
|
<p>
|
|
|
|
Note that you should check your <tt>/etc/inetd.conf</tt> file to make sure
|
|
|
|
that this is where your wu.ftpd server really lives. It has been reported
|
|
|
|
that some distributions place the server daemons in different places, and
|
|
|
|
then wu.ftpd in particular may be named something else.
|
|
|
|
|
|
|
|
<sect1><heading>Standard ftpd
|
|
|
|
<p>
|
|
|
|
If you are running the standard <tt>ftpd</tt> server, I would recommend that
|
|
|
|
you upgrade to the <tt>wu_ftpd</tt> server. Aside from the known bug
|
|
|
|
discussed above, it's generally thought to be more secure.
|
|
|
|
<p>
|
|
|
|
If you insist on the standard one, or you need <em>NIS</em> support, Sunsite
|
|
|
|
has
|
|
|
|
<url url="ftp://sunsite.unc.edu/pub/Linux/system/Network/file-transfer/ftpd-shadow-nis.tgz"
|
|
|
|
name="ftpd-shadow-nis.tgz">
|
|
|
|
|
|
|
|
<sect1><heading>pop3d (Post Office Protocol 3)
|
|
|
|
<p>
|
|
|
|
If you need to support the third <em>Post Office Protocol (POP3)</em>, you
|
|
|
|
will need to recompile a <tt>pop3d</tt> program. <tt>pop3d</tt> is normally
|
|
|
|
run by <tt>inetd/tcpd</tt> as <tt>root</tt>.
|
|
|
|
<p>
|
|
|
|
There are two versions available from Sunsite:
|
|
|
|
<url url="ftp://sunsite.unc.edu/pub/Linux/system/Mail/pop/pop3d-1.00.4.linux.shadow.tar.gz"
|
|
|
|
name="pop3d-1.00.4.linux.shadow.tar.gz">
|
|
|
|
and
|
|
|
|
<url url="ftp://sunsite.unc.edu/pub/Linux/system/Mail/pop/pop3d+shadow+elf.tar.gz"
|
|
|
|
name="pop3d+shadow+elf.tar.gz">
|
|
|
|
<p>
|
|
|
|
Both of these are fairly straight forward to install.
|
|
|
|
|
|
|
|
<sect1><heading>xlock
|
|
|
|
<p>
|
|
|
|
If you install the shadow suite, and then run <em>X Windows System</em> and
|
|
|
|
lock the screen without upgrading your <tt>xlock</tt>, you will have to use
|
|
|
|
<tt>CNTL-ALT-Fx</tt> to switch to another <em>tty</em>, login, and kill the
|
|
|
|
<tt>xlock</tt> process (or use <tt>CNTL-ALT-BS</tt> to kill the X server).
|
|
|
|
Fortunately it's fairly easy to upgrade your <tt>xlock</tt> program.
|
|
|
|
<p>
|
|
|
|
If you are running XFree86 Versions 3.x.x, you are probably using
|
|
|
|
<tt>xlockmore</tt> (which is a great screen-saver in addition to a lock).
|
|
|
|
This package supports <em>shadow</em> with a recompile. If you have an
|
|
|
|
older <tt>xlock</tt>, I recommend that you upgrade to this one.
|
|
|
|
<p>
|
|
|
|
<tt>xlockmore-3.5.tgz</tt> is available at:
|
|
|
|
<url
|
|
|
|
url="ftp://sunsite.unc.edu/pub/Linux/X11/xutils/screensavers/xlockmore-3.7.tgz">
|
|
|
|
<p>
|
|
|
|
Basically, this is what you need to do:
|
|
|
|
<p>
|
|
|
|
Get the <tt>xlockmore-3.7.tgz</tt> file and put it in <tt>/usr/src</tt> unpack it:
|
|
|
|
<tscreen><verb>tar -xzvf xlockmore-3.7.tgz</verb></tscreen>
|
|
|
|
<p>
|
|
|
|
Edit the file: <tt>/usr/X11R6/lib/X11/config/linux.cf</tt>, and change the line:
|
|
|
|
<tscreen><verb>#define HasShadowPasswd NO
|
|
|
|
|
|
|
|
to
|
|
|
|
|
|
|
|
#define HasShadowPasswd YES</verb></tscreen>
|
|
|
|
<p>
|
|
|
|
Then build the executables:
|
|
|
|
<tscreen><verb>cd /usr/src/xlockmore
|
|
|
|
xmkmf
|
|
|
|
make depend
|
|
|
|
make</verb></tscreen>
|
|
|
|
<p>
|
|
|
|
Then move everything into place and update file ownerships and permissions:
|
|
|
|
<tscreen><verb>cp xlock /usr/X11R6/bin/
|
|
|
|
cp XLock /var/X11R6/lib/app-defaults/
|
|
|
|
chown root.shadow /usr/X11R6/bin/xlock
|
|
|
|
chmod 2755 /usr/X11R6/bin/xlock
|
|
|
|
chown root.shadow /etc/shadow
|
|
|
|
chmod 640 /etc/shadow</verb></tscreen>
|
|
|
|
<p>
|
|
|
|
Your xlock will now work correctly.
|
|
|
|
|
|
|
|
<sect1><heading>xdm
|
|
|
|
<p>
|
|
|
|
<tt>xdm</tt> is a program that presents a login screen for X-Windows. Some
|
|
|
|
systems start <tt>xdm</tt> when the system is told to goto a specified run
|
|
|
|
level (see <tt>/etc/inittab</tt>.
|
|
|
|
<P>
|
|
|
|
With the <em>Shadow Suite</em> install, <tt>xdm</tt> will need to be
|
|
|
|
updated. Fortunately it's fairly easy to upgrade your <tt>xdm</tt> program.
|
|
|
|
<p>
|
|
|
|
<p>
|
|
|
|
<tt>xdm.tar.gz</tt> is available at:
|
|
|
|
<url url="ftp://sunsite.unc.edu/pub/Linux/X11/xutils/xdm.tar.gz">
|
|
|
|
<p>
|
|
|
|
Get the <tt>xdm.tar.gz</tt> file and put it in <tt>/usr/src</tt>, then to
|
|
|
|
unpack it:
|
|
|
|
<tscreen><verb>tar -xzvf xdm.tar.gz</verb></tscreen>
|
|
|
|
<p>
|
|
|
|
Edit the file: <tt>/usr/X11R6/lib/X11/config/linux.cf</tt>, and change the line:
|
|
|
|
<tscreen><verb>#define HasShadowPasswd NO
|
|
|
|
|
|
|
|
to
|
|
|
|
|
|
|
|
#define HasShadowPasswd YES</verb></tscreen>
|
|
|
|
<p>
|
|
|
|
Then build the executables:
|
|
|
|
<tscreen><verb>cd /usr/src/xdm
|
|
|
|
xmkmf
|
|
|
|
make depend
|
|
|
|
make</verb></tscreen>
|
|
|
|
<p>
|
|
|
|
Then move everything into place:
|
|
|
|
<tscreen><verb>cp xdm /usr/X11R6/bin/</verb></tscreen>
|
|
|
|
<p>
|
|
|
|
<tt>xdm</tt> is run as <em>root</em> so you don't need to change it file
|
|
|
|
permissions.
|
|
|
|
|
|
|
|
|
|
|
|
<sect1><heading>sudo
|
|
|
|
<p>
|
|
|
|
The program <tt>sudo</tt> allows a system administrator to let users run
|
|
|
|
programs that would normally require root access. This is handy because it
|
|
|
|
lets the administrator limit access to the root account itself while still
|
|
|
|
allowing users to do things like mounting drives.
|
|
|
|
<p>
|
|
|
|
<tt>sudo</tt> needs to read passwords because it verifies the users password
|
|
|
|
when it's invoked. <tt>sudo</tt> already runs SUID root, so accessing the
|
|
|
|
<tt>/etc/shadow</tt> file is not a problem.
|
|
|
|
<p>
|
|
|
|
<tt>sudo</tt> for the shadow suite, is available as at:
|
|
|
|
<url url="ftp://sunsite.unc.edu/pub/Linux/system/Admin/sudo-1.2-shadow.tgz">
|
|
|
|
<p>
|
|
|
|
<em>Warning</em>: When you install <tt>sudo</tt> your <tt>/etc/sudoers</tt>
|
|
|
|
file will be replaced with a default one, so you need to make a backup of it
|
|
|
|
if you have added anything to the default one. (you could also edit the
|
|
|
|
Makefile and remove the line that copies the default file to <tt>/etc</tt>).
|
|
|
|
<p>
|
|
|
|
The package is already setup for shadow, so all that's required is to
|
|
|
|
recompile the package (put it in <tt>/usr/src</tt>):
|
|
|
|
<tscreen><verb>cd /usr/src
|
|
|
|
tar -xzvf sudo-1.2-shadow.tgz
|
|
|
|
cd sudo-1.2-shadow
|
|
|
|
make all
|
|
|
|
make install</verb></tscreen>
|
|
|
|
|
2016-01-17 22:23:53 +00:00
|
|
|
<sect1><heading>imapd (E-Mail [pine package])
|
2000-04-26 18:26:31 +00:00
|
|
|
<p>
|
|
|
|
<tt>imapd</tt> is an e-mail server similar to <tt>pop3d</tt>.
|
|
|
|
<tt>imapd</tt> comes with the <em>Pine E-mail</em> package. The
|
|
|
|
documentation that comes with the package states that the default for
|
|
|
|
Linux systems is to include support for shadow. However, I have found
|
|
|
|
that this is not true. Furthermore, the build script / Makefile combination
|
|
|
|
on this package is makes it very difficult to add the <tt>libshadow.a</tt>
|
|
|
|
library at compile time, so I was unable to add shadow support for
|
|
|
|
<tt>imapd</tt>.
|
|
|
|
<p>
|
|
|
|
If anyone has this figured out, please E-mail me, and I'll include the
|
|
|
|
solution here.
|
|
|
|
|
|
|
|
<sect1><heading>pppd (Point-to-Point Protocol Server)
|
|
|
|
<p>
|
|
|
|
The pppd server can be setup to use several types of authentication:
|
|
|
|
<em>Password Authentication Protocol</em> (PAP) and <em>Cryptographic
|
|
|
|
Handshake Authentication Protocol</em> (CHAP). The pppd server usually
|
|
|
|
reads the password strings that it uses from <tt>/etc/ppp/chap-secrets</tt>
|
|
|
|
and/or <tt>/etc/ppp/pap-secrets</tt>. If you are using this default behavior
|
|
|
|
of pppd, it is not necessary to reinstall pppd.
|
|
|
|
<p>
|
|
|
|
pppd also allows you to use the <em>login</em> parameter (either on the
|
|
|
|
command line, or in the configuration or <tt>options</tt> file). If the
|
|
|
|
<em>login</em> option is given, then pppd will use the <tt>/etc/passwd</tt>
|
|
|
|
file for the username and passwords for the <em>PAP</em>. This, of course,
|
|
|
|
will no longer work now that our password file is shadowed. For pppd-1.2.1d
|
|
|
|
this requires adding code for shadow support.
|
|
|
|
<p>
|
|
|
|
The example given in the next section is adding shadow support to
|
|
|
|
<tt>pppd-1.2.1d</tt> (an older version of pppd).
|
|
|
|
<p>
|
|
|
|
<tt>pppd-2.2.0</tt> already contains shadow support.
|
|
|
|
|
|
|
|
<sect><heading>Putting the Shadow Suite to use.<label id="sec-work">
|
|
|
|
<p>
|
|
|
|
This section discusses some of the things that you will want to know now
|
|
|
|
that you have the <em>Shadow Suite</em> installed on your system. More
|
|
|
|
information is contained in the manual pages for each command.
|
|
|
|
|
|
|
|
<sect1><heading>Adding, Modifying, and deleting users
|
|
|
|
<p>
|
|
|
|
The <em>Shadow Suite</em> added the following command line oriented commands
|
|
|
|
for adding, modifying, and deleting users. You may also have installed the
|
|
|
|
<tt>adduser</tt> program.
|
|
|
|
|
|
|
|
<sect2><heading>useradd
|
|
|
|
<p>
|
|
|
|
The <tt>useradd</tt> command can be used to add users to the system. You
|
|
|
|
also invoke this command to change the default settings.
|
|
|
|
<p>
|
|
|
|
The first thing that you should do is to examine the default settings and
|
|
|
|
make changes specific to your system:
|
|
|
|
<tscreen><verb>useradd -D</verb></tscreen><code>
|
|
|
|
GROUP=1
|
|
|
|
HOME=/home
|
|
|
|
INACTIVE=0
|
|
|
|
EXPIRE=0
|
|
|
|
SHELL=
|
|
|
|
SKEL=/etc/skel</code>
|
|
|
|
<p>
|
|
|
|
The defaults are probably not what you want, so if you started adding users
|
|
|
|
now you would have to specify all the information for each user. However, we
|
|
|
|
can and should change the default values.
|
|
|
|
<p>
|
|
|
|
On my system:
|
|
|
|
<itemize>
|
|
|
|
<item>I want the default group to be 100
|
|
|
|
<item>I want passwords to expire every 60 days
|
|
|
|
<item>I don't want to lock an account because the password is expired
|
|
|
|
<item>I want to default shell to be <tt>/bin/bash</tt>
|
|
|
|
</itemize>
|
|
|
|
To make these changes I would use:
|
|
|
|
<tscreen><verb>useradd -D -g100 -e60 -f0 -s/bin/bash</verb></tscreen>
|
|
|
|
<p>
|
|
|
|
Now running <tt>useradd -D</tt> will give:
|
|
|
|
<code>
|
|
|
|
GROUP=100
|
|
|
|
HOME=/home
|
|
|
|
INACTIVE=0
|
|
|
|
EXPIRE=60
|
|
|
|
SHELL=/bin/bash
|
|
|
|
SKEL=/etc/skel
|
|
|
|
</code>
|
|
|
|
<p>
|
|
|
|
Just in case you wanted to know, these defaults are stored in the file
|
|
|
|
<tt>/etc/default/useradd</tt>.
|
|
|
|
<p>
|
|
|
|
Now you can use <tt>useradd</tt> to add users to the system. For example,
|
|
|
|
to add the user <tt>fred</tt>, using the defaults, you would use the
|
|
|
|
following:
|
|
|
|
<tscreen><verb>useradd -m -c "Fred Flintstone" fred</verb></tscreen>
|
|
|
|
This will create the following entry in the <tt>/etc/passwd</tt> file:
|
|
|
|
<tscreen><verb>fred:*:505:100:Fred Flintstone:/home/fred:/bin/bash</verb></tscreen>
|
|
|
|
And the following entry in the <tt>/etc/shadow</tt> file:
|
|
|
|
<tscreen><verb>fred:!:0:0:60:0:0:0:0</verb></tscreen>
|
|
|
|
<tt>fred</tt>'s home directory will be created and the contents of
|
|
|
|
<tt>/etc/skel</tt> will be copied there because of the <tt>-m</tt> switch.
|
|
|
|
<p>
|
|
|
|
Also, since we did not specify a UID, the next available one was used.
|
|
|
|
<p>
|
|
|
|
<tt>fred</tt>'s account is created, but <tt>fred</tt> still won't be able to
|
|
|
|
login until we unlock the account. We do this by changing the password.
|
|
|
|
<tscreen><verb>passwd fred</verb></tscreen>
|
|
|
|
<code>
|
|
|
|
Changing password for fred
|
|
|
|
Enter the new password (minimum of 5 characters)
|
|
|
|
Please use a combination of upper and lower case letters and numbers.
|
|
|
|
New Password: *******
|
|
|
|
Re-enter new password: *******
|
|
|
|
</code>
|
|
|
|
Now the <tt>/etc/shadow</tt> will contain:
|
|
|
|
<tscreen><verb>fred:J0C.WDR1amIt6:9559:0:60:0:0:0:0</verb></tscreen>
|
|
|
|
And <tt>fred</tt> will now be able to login and use the system. The nice
|
|
|
|
thing about <tt>useradd</tt> and the other programs that come with the
|
|
|
|
<em>Shadow Suite</em> is that they make changes to the <tt>/etc/passwd</tt>
|
|
|
|
and <tt>/etc/shadow</tt> files atomically. So if you are adding a user, and
|
|
|
|
another user is changing their password at the same time, both operations
|
|
|
|
will be performed correctly.
|
|
|
|
<p>
|
|
|
|
You should use the supplied commands rather than directly editing
|
|
|
|
<tt>/etc/passwd</tt> and <tt>/etc/shadow</tt>. If you were editing the
|
|
|
|
<tt>/etc/shadow</tt> file, and a user were to change his password while you
|
|
|
|
are editing, and then you were to save the file you were editing, the user's
|
|
|
|
password change would be lost.
|
|
|
|
<p>
|
|
|
|
Here is a small interactive script that adds users using <tt>useradd</tt>
|
|
|
|
and <tt>passwd</tt>:
|
|
|
|
<code>
|
|
|
|
#!/bin/bash
|
|
|
|
#
|
|
|
|
# /sbin/newuser - A script to add users to the system using the Shadow
|
|
|
|
# Suite's useradd and passwd commands.
|
|
|
|
#
|
|
|
|
# Written my Mike Jackson <mhjack@tscnet.com> as an example for the Linux
|
|
|
|
# Shadow Password Howto. Permission to use and modify is expressly granted.
|
|
|
|
#
|
|
|
|
# This could be modified to show the defaults and allow modification similar
|
|
|
|
# to the Slackware Adduser program. It could also be modified to disallow
|
|
|
|
# stupid entries. (i.e. better error checking).
|
|
|
|
#
|
|
|
|
##
|
|
|
|
# Defaults for the useradd command
|
|
|
|
##
|
|
|
|
GROUP=100 # Default Group
|
|
|
|
HOME=/home # Home directory location (/home/username)
|
|
|
|
SKEL=/etc/skel # Skeleton Directory
|
|
|
|
INACTIVE=0 # Days after password expires to disable account (0=never)
|
|
|
|
EXPIRE=60 # Days that a passwords lasts
|
|
|
|
SHELL=/bin/bash # Default Shell (full path)
|
|
|
|
##
|
|
|
|
# Defaults for the passwd command
|
|
|
|
##
|
|
|
|
PASSMIN=0 # Days between password changes
|
|
|
|
PASSWARN=14 # Days before password expires that a warning is given
|
|
|
|
##
|
|
|
|
# Ensure that root is running the script.
|
|
|
|
##
|
|
|
|
WHOAMI=`/usr/bin/whoami`
|
|
|
|
if [ $WHOAMI != "root" ]; then
|
|
|
|
echo "You must be root to add news users!"
|
|
|
|
exit 1
|
|
|
|
fi
|
|
|
|
##
|
|
|
|
# Ask for username and fullname.
|
|
|
|
##
|
|
|
|
echo ""
|
|
|
|
echo -n "Username: "
|
|
|
|
read USERNAME
|
|
|
|
echo -n "Full name: "
|
|
|
|
read FULLNAME
|
|
|
|
#
|
|
|
|
echo "Adding user: $USERNAME."
|
|
|
|
#
|
|
|
|
# Note that the "" around $FULLNAME is required because this field is
|
|
|
|
# almost always going to contain at least on space, and without the "'s
|
|
|
|
# the useradd command would think that you we moving on to the next
|
|
|
|
# parameter when it reached the SPACE character.
|
|
|
|
#
|
|
|
|
/usr/sbin/useradd -c"$FULLNAME" -d$HOME/$USERNAME -e$EXPIRE \
|
|
|
|
-f$INACTIVE -g$GROUP -m -k$SKEL -s$SHELL $USERNAME
|
|
|
|
##
|
|
|
|
# Set password defaults
|
|
|
|
##
|
|
|
|
/bin/passwd -n $PASSMIN -w $PASSWARN $USERNAME >/dev/null 2>&1
|
|
|
|
##
|
|
|
|
# Let the passwd command actually ask for password (twice)
|
|
|
|
##
|
|
|
|
/bin/passwd $USERNAME
|
|
|
|
##
|
|
|
|
# Show what was done.
|
|
|
|
##
|
|
|
|
echo ""
|
|
|
|
echo "Entry from /etc/passwd:"
|
|
|
|
echo -n " "
|
|
|
|
grep "$USERNAME:" /etc/passwd
|
|
|
|
echo "Entry from /etc/shadow:"
|
|
|
|
echo -n " "
|
|
|
|
grep "$USERNAME:" /etc/shadow
|
|
|
|
echo "Summary output of the passwd command:"
|
|
|
|
echo -n " "
|
|
|
|
passwd -S $USERNAME
|
|
|
|
echo ""
|
|
|
|
</code>
|
|
|
|
<p>
|
|
|
|
Using a script to add new users is really much more preferable than editing
|
|
|
|
the <tt>/etc/passwd</tt> or <tt>/etc/shadow</tt> files directly or using a
|
|
|
|
program like the Slackware <tt>adduser</tt> program. Feel free to use and
|
|
|
|
modify this script for your particular system.
|
|
|
|
<p>
|
|
|
|
For more information on the <tt>useradd</tt> see the online manual page.
|
|
|
|
|
|
|
|
<sect2><heading>usermod
|
|
|
|
<p>
|
|
|
|
The <tt>usermod</tt> program is used to modify the information on a user.
|
|
|
|
The switches are similar to the <tt>useradd</tt> program.
|
|
|
|
<p>
|
|
|
|
Let's say that you want to change <tt>fred</tt>'s shell, you would do the
|
|
|
|
following:
|
|
|
|
<tscreen><verb>usermod -s /bin/tcsh fred</verb></tscreen>
|
|
|
|
Now <tt>fred</tt>'s <tt>/etc/passwd</tt> file entry would be change to this:
|
|
|
|
<tscreen><verb>fred:*:505:100:Fred Flintstone:/home/fred:/bin/tcsh</verb></tscreen>
|
|
|
|
Let's make <tt>fred</tt>'s account expire on 09/15/97:
|
|
|
|
<tscreen><verb>usermod -e 09/15/97 fred</verb></tscreen>
|
|
|
|
Now <tt>fred</tt>'s entry in <tt>/etc/shadow</tt> becomes:
|
|
|
|
<tscreen><verb>fred:J0C.WDR1amIt6:9559:0:60:0:0:10119:0</verb></tscreen>
|
|
|
|
<p>
|
|
|
|
For more information on the <tt>usermod</tt> command see the online manual
|
|
|
|
page.
|
|
|
|
|
|
|
|
<sect2><heading>userdel
|
|
|
|
<p>
|
|
|
|
<tt>userdel</tt> does just what you would expect, it deletes the user's
|
|
|
|
account. You simply use:
|
|
|
|
<tscreen><verb>userdel -r username</verb></tscreen>
|
|
|
|
The <tt>-r</tt> causes all files in the user's home directory to be removed
|
|
|
|
along with the home directory itself. Files located in other file system
|
|
|
|
will have to be searched for and deleted manually.
|
|
|
|
<p>
|
|
|
|
If you want to simply lock the account rather than delete it, use the
|
|
|
|
<tt>passwd</tt> command instead.
|
|
|
|
|
|
|
|
<sect1><heading>The passwd command and passwd aging.
|
|
|
|
<p>
|
|
|
|
The <tt>passwd</tt> command has the obvious use of changing passwords.
|
|
|
|
Additionally, it is used by the <em>root</em> user to:
|
|
|
|
<itemize>
|
|
|
|
<item>Lock and unlock accounts (<tt>-l</tt> and <tt>-u</tt>)
|
|
|
|
<item>Set the maximum number of days that a password remains valid
|
|
|
|
(<tt>-x</tt>)
|
|
|
|
<item>Set the minimum days between password changes (<tt>-n</tt>)
|
|
|
|
<item>Sets the number of days of warning that a password is about to expire
|
|
|
|
(<tt>-w</tt>)
|
|
|
|
<item>Sets the number of days after the password expires before the account
|
|
|
|
is locked (<tt>-i</tt>)
|
|
|
|
<item>Allow viewing of account information in a clearer format (<tt>-S</tt>)
|
|
|
|
</itemize>
|
|
|
|
<p>
|
|
|
|
For example, let look again at <tt>fred</tt>
|
|
|
|
<tscreen><verb>passwd -S fred
|
|
|
|
fred P 03/04/96 0 60 0 0</verb></tscreen>
|
|
|
|
This means that <tt>fred</tt>'s password is valid, it was last changed on
|
|
|
|
03/04/96, it can be changed at any time, it expires after 60 days, fred will
|
2016-10-24 11:40:00 +00:00
|
|
|
not be warned, and the account won't be disabled when the password
|
2000-04-26 18:26:31 +00:00
|
|
|
expires.
|
|
|
|
<p>
|
|
|
|
This simply means that if <tt>fred</tt> logs in after the password expires,
|
|
|
|
he will be prompted for a new password at login.
|
|
|
|
<p>
|
|
|
|
If we decide that we want to warn <tt>fred</tt> 14 days before his password
|
|
|
|
expires and make his account inactive 14 days after he lets it expire, we
|
|
|
|
would need to do the following:
|
|
|
|
<tscreen><verb>passwd -w14 -i14 fred</verb></tscreen>
|
|
|
|
Now <tt>fred</tt> is changed to:
|
|
|
|
<tscreen><verb>fred P 03/04/96 0 60 14 14</verb></tscreen>
|
|
|
|
For more information on the <tt>passwd</tt> command see the online manual
|
|
|
|
page.
|
|
|
|
|
|
|
|
<sect1><heading>The login.defs file.
|
|
|
|
<p>
|
|
|
|
The file <tt>/etc/login</tt> is the configuration file for the
|
|
|
|
<tt>login</tt> program and also for the <em>Shadow Suite</em> as a whole.
|
|
|
|
<p>
|
|
|
|
<tt>/etc/login</tt> contains settings from what the prompts will look like
|
|
|
|
to what the default expiration will be when a user changes his password.
|
|
|
|
<p>
|
|
|
|
The <tt>/etc/login.defs</tt> file is quite well documented just by the
|
|
|
|
comments that are contained within it. However, there are a few things to
|
|
|
|
note:
|
|
|
|
<itemize>
|
|
|
|
<item>It contains flags that can be turned on or off that determine the
|
|
|
|
amount of logging that takes place.
|
|
|
|
<item>It contains pointers to other configuration files.
|
|
|
|
<item>It contains defaults assignments for things like password aging.
|
|
|
|
</itemize>
|
|
|
|
<p>
|
|
|
|
From the above list you can see that this is a rather important file, and
|
|
|
|
you should make sure that it is present, and that the settings are what you
|
|
|
|
desire for your system.
|
|
|
|
|
|
|
|
<sect1><heading>Group passwords.
|
|
|
|
<p>
|
|
|
|
The <tt>/etc/groups</tt> file may contain passwords that permit a user to
|
|
|
|
become a member of a particular group. This function is enabled if you
|
|
|
|
define the constant <tt>SHADOWGRP</tt> in the
|
|
|
|
<tt>/usr/src/shadow-YYMMDD/config.h</tt> file.
|
|
|
|
<p>
|
|
|
|
If you define this constant and then compile, you must create an
|
|
|
|
<tt>/etc/gshadow</tt> file to hold the group passwords and the group
|
|
|
|
administrator information.
|
|
|
|
<p>
|
|
|
|
When you created the <tt>/etc/shadow</tt>, you used a program called
|
|
|
|
<tt>pwconv</tt>, there no equivalent program to create the
|
|
|
|
<tt>/etc/gshadow</tt> file, but it really doesn't matter, it takes care of
|
|
|
|
itself.
|
|
|
|
<p>
|
|
|
|
To create the initial <tt>/etc/gshadow</tt> file do the following:
|
|
|
|
<tscreen><verb>touch /etc/gshadow
|
|
|
|
chown root.root /etc/gshadow
|
|
|
|
chmod 700 /etc/gshadow</verb></tscreen>
|
|
|
|
<p>
|
|
|
|
Once you create new groups, they will be added to the <tt>/etc/group</tt>
|
|
|
|
and the <tt>/etc/gshadow</tt> files. If you modify a group by adding or
|
|
|
|
removing users or changing the group password, the <tt>/etc/gshadow</tt>
|
|
|
|
file will be changed.
|
|
|
|
<p>
|
|
|
|
The programs <tt>groups</tt>, <tt>groupadd</tt>, <tt>groupmod</tt>, and
|
|
|
|
<tt>groupdel</tt> are provided as part of the <em>Shadow Suite</em> to
|
|
|
|
modify groups.
|
|
|
|
<p>
|
|
|
|
The format of the <tt>/etc/group</tt> file is as follows:
|
|
|
|
<tscreen><verb>groupname:!:GID:member,member,...</verb></tscreen>
|
|
|
|
Where:
|
|
|
|
<descrip>
|
|
|
|
<tag/<tt>groupname</tt></tag> The name of the group
|
|
|
|
<tag/<tt>!</tt></tag> The field that normally holds the password, but that
|
|
|
|
is now relocated to the <tt>/etc/gshadow</tt> file.
|
|
|
|
<tag/<tt>GID</tt></tag> The numerical group ID number
|
|
|
|
<tag/<tt>member</tt></tag> List of group members
|
|
|
|
</descrip>
|
|
|
|
<p>
|
|
|
|
The format of the <tt>/etc/gshadow</tt> file is as follows:
|
|
|
|
<tscreen><verb>groupname:password:admin,admin,...:member,member,...</verb></tscreen>
|
|
|
|
Where:
|
|
|
|
<descrip>
|
|
|
|
<tag/<tt>groupname</tt></tag> The name of the group
|
|
|
|
<tag/<tt>password</tt></tag> The encoded group password.
|
|
|
|
<tag/<tt>admin</tt></tag> List of group administrators
|
|
|
|
<tag/<tt>member</tt></tag> List of group members
|
|
|
|
</descrip>
|
|
|
|
<p>
|
|
|
|
The command <tt>gpasswd</tt> is used only for adding or removing
|
|
|
|
administrators and members to or from a group. <tt>root</tt> or someone in
|
|
|
|
the list of administrators may add or remove group members.
|
|
|
|
<p>
|
|
|
|
The groups password can be changed using the <tt>passwd</tt> command by
|
|
|
|
<em>root</em> or anyone listed as an administrator for the group.
|
|
|
|
<p>
|
|
|
|
Despite the fact that there is not currently a manual page for
|
|
|
|
<tt>gpasswd</tt>, typing <tt>gpasswd</tt> without any parameters gives a
|
|
|
|
listing of options. It's fairly easy to grasp how it all works once you
|
|
|
|
understand the file formats and the concepts.
|
|
|
|
|
|
|
|
|
|
|
|
<sect1><heading>Consistency checking programs
|
|
|
|
<p>
|
|
|
|
|
|
|
|
<sect2><heading>pwck
|
|
|
|
<p>
|
|
|
|
The program <tt>pwck</tt> is provided to provide a consistency check on the
|
|
|
|
<tt>/etc/passwd</tt> and <tt>/etc/shadow</tt> files. It will check each
|
|
|
|
username and verify that it has the following:
|
|
|
|
<itemize>
|
|
|
|
<item>the correct number of fields
|
|
|
|
<item>unique user name
|
|
|
|
<item>valid user and group identifier
|
|
|
|
<item>valid primary group
|
|
|
|
<item>valid home directory
|
|
|
|
<item>valid login shell
|
|
|
|
</itemize>
|
|
|
|
<p>It will also warn of any account that has no password.
|
|
|
|
<p>
|
|
|
|
It's a good idea to run <tt>pwck</tt> after installing the <em>Shadow
|
|
|
|
Suite</em>. It's also a good idea to run it periodically, perhaps weekly or
|
|
|
|
monthly. If you use the <tt>-r</tt> option, you can use <tt>cron</tt> to run
|
|
|
|
it on a regular basis and have the report mailed to you.
|
|
|
|
|
|
|
|
<sect2><heading>grpck
|
|
|
|
<p>
|
|
|
|
<tt>grpck</tt> is the consistency checking program for the
|
|
|
|
<tt>/etc/group</tt> and <tt>/etc/gshadow</tt> files. It performs the
|
|
|
|
following checks:
|
|
|
|
<itemize>
|
|
|
|
<item>the correct number of fields
|
|
|
|
<item>unique group name
|
|
|
|
<item>valid list of members and administrators
|
|
|
|
</itemize>
|
|
|
|
<p>
|
|
|
|
It also has the <tt>-r</tt> option for automated reports.
|
|
|
|
|
|
|
|
<sect1><heading>Dial-up passwords.
|
|
|
|
<p>
|
|
|
|
Dial-up passwords are another optional line of defense for systems that allow
|
|
|
|
dial-in access. If you have a system that allows many people to connect
|
|
|
|
locally or via a network, but you want to limit who can dial in and connect,
|
|
|
|
then dial-up passwords are for you. To enable dial-up passwords, you must
|
|
|
|
edit the file <tt>/etc/login.defs</tt> and ensure that
|
|
|
|
<tt>DIALUPS_CHECK_ENAB</tt> is set to <tt>yes</tt>.
|
|
|
|
<p>
|
|
|
|
Two files contain the dial-up information, <tt>/etc/dialups</tt> which
|
|
|
|
contains the ttys (one per line, with the leading "/dev/" removed). If a
|
|
|
|
tty is listed then dial-up checks are performed.
|
|
|
|
<p>
|
|
|
|
The second file is the <tt>/etc/d_passwd</tt> file. This file contains the
|
|
|
|
fully qualified path name of a shell, followed by an optional password.
|
|
|
|
<p>
|
|
|
|
If a user logs into a line that is listed in <tt>/etc/dialups</tt>, and his
|
|
|
|
shell is listed in the file <tt>/etc/d_passwd</tt> he will be allowed access
|
|
|
|
only by suppling the correct password.
|
|
|
|
<p>
|
|
|
|
Another useful purpose for using dial-up passwords might be to setup a line
|
|
|
|
that only allows a certain type of connect (perhaps a PPP or UUCP connection).
|
|
|
|
If a user tries to get another type of connection (i.e. a list of shells),
|
|
|
|
he must know a password to use the line.
|
|
|
|
<p>
|
|
|
|
Before you can use the dial-up feature, you must create the files.
|
|
|
|
<p>
|
|
|
|
The command <tt>dpasswd</tt> is provided to assign passwords to the shells
|
|
|
|
in the <tt>/etc/d_passwd</tt> file. See the manual page for more
|
|
|
|
information.
|
|
|
|
|
|
|
|
|
|
|
|
<sect><heading>Adding shadow support to a C program<label id="sec-adding">
|
|
|
|
<p>
|
|
|
|
Adding shadow support to a program is actually fairly straightforward. The
|
|
|
|
only problem is that the program must be run by root (or SUID root) in order
|
2016-10-24 11:40:00 +00:00
|
|
|
for the program to be able to access the <tt>/etc/shadow</tt> file.
|
2000-04-26 18:26:31 +00:00
|
|
|
<p>
|
|
|
|
This presents one big problem: very careful programming practices must be
|
|
|
|
followed when creating SUID programs. For instance, if a program has a shell
|
|
|
|
escape, this must not occur as root if the program is SUID root.
|
|
|
|
<p>
|
|
|
|
For adding shadow support to a program so that it can check passwords, but
|
|
|
|
otherwise does need to run as root, it's a lot safer to run the program SUID
|
|
|
|
shadow instead. The <tt>xlock</tt> program is an example of this.
|
|
|
|
<p>
|
|
|
|
In the example given below, <tt>pppd-1.2.1d</tt> already runs SUID as root,
|
|
|
|
so adding shadow support should not make the program any more vulnerable.
|
|
|
|
|
|
|
|
<sect1><heading>Header files
|
|
|
|
<p>
|
|
|
|
The header files should reside in <tt>/usr/include/shadow</tt>. There
|
|
|
|
should also be a <tt>/usr/include/shadow.h</tt>, but it will be a symbolic
|
|
|
|
link to <tt>/usr/include/shadow/shadow.h</tt>.
|
|
|
|
<p>
|
|
|
|
To add shadow support to a program, you need to include the header files:
|
|
|
|
<verb>
|
|
|
|
#include <shadow/shadow.h>
|
|
|
|
#include <shadow/pwauth.h>
|
|
|
|
</verb>
|
|
|
|
<p>
|
|
|
|
It might be a good idea to use compiler directives to conditionally compile
|
|
|
|
the shadow code (I do in the example below).
|
|
|
|
|
|
|
|
<sect1><heading>libshadow.a library
|
|
|
|
<p>
|
|
|
|
When you installed the <em>Shadow Suite</em> the <tt>libshadow.a</tt> file
|
|
|
|
was created and installed in <tt>/usr/lib</tt>.
|
|
|
|
<p>
|
|
|
|
When compiling shadow support into a program, the linker needs to be told to
|
|
|
|
include the <tt>libshadow.a</tt> library into the link.
|
|
|
|
<p>
|
|
|
|
This is done by:
|
|
|
|
<tscreen><verb>gcc program.c -o program -lshadow</verb></tscreen>
|
|
|
|
<p>
|
|
|
|
However, as we will see in the example below, most large programs use a
|
|
|
|
<tt>Makefile</tt>, and usually have a variable called <tt>LIBS=...</tt> that
|
|
|
|
we will modify.
|
|
|
|
|
|
|
|
<sect1><heading>Shadow Structure
|
|
|
|
<p>
|
|
|
|
The <tt>libshadow.a</tt> library uses a structure called <tt>spwd</tt>
|
|
|
|
for the information it retrieves from the <tt>/etc/shadow</tt> file. This is
|
|
|
|
the definition of the <tt>spwd</tt> structure from the
|
|
|
|
<tt>/usr/include/shadow/shadow.h</tt> header file:
|
|
|
|
<code>
|
|
|
|
struct spwd
|
|
|
|
{
|
|
|
|
char *sp_namp; /* login name */
|
|
|
|
char *sp_pwdp; /* encrypted password */
|
|
|
|
sptime sp_lstchg; /* date of last change */
|
|
|
|
sptime sp_min; /* minimum number of days between changes */
|
|
|
|
sptime sp_max; /* maximum number of days between changes */
|
|
|
|
sptime sp_warn; /* number of days of warning before password
|
|
|
|
expires */
|
|
|
|
sptime sp_inact; /* number of days after password expires
|
|
|
|
until the account becomes unusable. */
|
|
|
|
sptime sp_expire; /* days since 1/1/70 until account expires
|
|
|
|
*/
|
|
|
|
unsigned long sp_flag; /* reserved for future use */
|
|
|
|
};
|
|
|
|
</code>
|
|
|
|
<p>
|
|
|
|
The <em>Shadow Suite</em> can put things into the <tt>sp_pwdp</tt> field
|
|
|
|
besides just the encoded passwd. The password field could contain:
|
|
|
|
<tscreen><verb>username:Npge08pfz4wuk;@/sbin/extra:9479:0:10000::::</verb></tscreen>
|
|
|
|
<p>
|
|
|
|
This means that in addition to the password, the program
|
|
|
|
<tt>/sbin/extra</tt> should be called for further authentication. The
|
|
|
|
program called will get passed the username and a switch that indicates
|
|
|
|
why it's being called. See the file <tt>/usr/include/shadow/pwauth.h</tt>
|
|
|
|
and the source code for <tt>pwauth.c</tt> for more information.
|
|
|
|
<p>
|
|
|
|
What this means is that we should use the function <tt>pwauth</tt> to
|
|
|
|
perform the actual authentication, as it will take care of the secondary
|
|
|
|
authentication as well. The example below does this.
|
|
|
|
<p>
|
|
|
|
The author of the <em>Shadow Suite</em> indicates that since most
|
|
|
|
programs in existence don't do this, and that it may be removed or changed
|
|
|
|
in future versions of the <em>Shadow Suite</em>.
|
|
|
|
|
|
|
|
<sect1><heading>Shadow Functions
|
|
|
|
<p>
|
|
|
|
The <tt>shadow.h</tt> file also contains the function prototypes for the
|
|
|
|
functions contained in the <tt>libshadow.a</tt> library:
|
|
|
|
<code>
|
|
|
|
extern void setspent __P ((void));
|
|
|
|
extern void endspent __P ((void));
|
|
|
|
extern struct spwd *sgetspent __P ((__const char *__string));
|
|
|
|
extern struct spwd *fgetspent __P ((FILE *__fp));
|
|
|
|
extern struct spwd *getspent __P ((void));
|
|
|
|
extern struct spwd *getspnam __P ((__const char *__name));
|
|
|
|
extern int putspent __P ((__const struct spwd *__sp, FILE *__fp));
|
|
|
|
</code>
|
|
|
|
<p>
|
|
|
|
The function that we are going to use in the example is: <tt>getspnam</tt>
|
|
|
|
which will retrieve for us a <tt>spwd</tt> structure for the supplied name.
|
|
|
|
|
|
|
|
|
|
|
|
<sect1><heading>Example
|
|
|
|
<p>
|
|
|
|
This is an example of adding shadow support to a program that needs it, but
|
|
|
|
does not have it by default.
|
|
|
|
<p>
|
|
|
|
This example uses the <em>Point-to-Point Protocol Server</em> (pppd-1.2.1d),
|
|
|
|
which has a mode in which it performs <em>PAP</em> authentication using
|
|
|
|
user names and passwords from the <tt>/etc/passwd</tt> file instead of the
|
|
|
|
<em>PAP</em> or <em>CHAP</em> files. You would not need to add this code
|
|
|
|
to <tt>pppd-2.2.0</tt> because it's already there.
|
|
|
|
<p>
|
|
|
|
This feature of pppd probably isn't used very much, but if you installed the
|
|
|
|
<em>Shadow Suite</em>, it won't work anymore because the passwords are no
|
|
|
|
longer stored in <tt>/etc/passwd</tt>.
|
|
|
|
<p>
|
|
|
|
The code for authenticating users under <tt>pppd-1.2.1d</tt> is located in
|
|
|
|
the <tt>/usr/src/pppd-1.2.1d/pppd/auth.c</tt> file.
|
|
|
|
<p>
|
|
|
|
The following code needs to be added to the top of the file where all the
|
|
|
|
other <tt>#include</tt> directives are. We have surrounded the
|
|
|
|
<tt>#includes</tt> with conditional directives (i.e. only include if we
|
|
|
|
are compiling for shadow support).
|
|
|
|
<p>
|
|
|
|
<code>
|
|
|
|
#ifdef HAS_SHADOW
|
|
|
|
#include <shadow.h>
|
|
|
|
#include <shadow/pwauth.h>
|
|
|
|
#endif
|
|
|
|
</code>
|
|
|
|
<p>
|
|
|
|
The next thing to do is to modify the actual code. We are still making
|
|
|
|
changes to the <tt>auth.c</tt> file.
|
|
|
|
<p>
|
|
|
|
Function <tt>auth.c</tt> before modifications:
|
|
|
|
<code>
|
|
|
|
/*
|
|
|
|
* login - Check the user name and password against the system
|
|
|
|
* password database, and login the user if OK.
|
|
|
|
*
|
|
|
|
* returns:
|
|
|
|
* UPAP_AUTHNAK: Login failed.
|
|
|
|
* UPAP_AUTHACK: Login succeeded.
|
|
|
|
* In either case, msg points to an appropriate message.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
login(user, passwd, msg, msglen)
|
|
|
|
char *user;
|
|
|
|
char *passwd;
|
|
|
|
char **msg;
|
|
|
|
int *msglen;
|
|
|
|
{
|
|
|
|
struct passwd *pw;
|
|
|
|
char *epasswd;
|
|
|
|
char *tty;
|
|
|
|
|
|
|
|
if ((pw = getpwnam(user)) == NULL) {
|
|
|
|
return (UPAP_AUTHNAK);
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* XXX If no passwd, let them login without one.
|
|
|
|
*/
|
|
|
|
if (pw->pw_passwd == '\0') {
|
|
|
|
return (UPAP_AUTHACK);
|
|
|
|
}
|
|
|
|
|
|
|
|
epasswd = crypt(passwd, pw->pw_passwd);
|
|
|
|
if (strcmp(epasswd, pw->pw_passwd)) {
|
|
|
|
return (UPAP_AUTHNAK);
|
|
|
|
}
|
|
|
|
|
|
|
|
syslog(LOG_INFO, "user %s logged in", user);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Write a wtmp entry for this user.
|
|
|
|
*/
|
|
|
|
tty = strrchr(devname, '/');
|
|
|
|
if (tty == NULL)
|
|
|
|
tty = devname;
|
|
|
|
else
|
|
|
|
tty++;
|
|
|
|
logwtmp(tty, user, ""); /* Add wtmp login entry */
|
|
|
|
logged_in = TRUE;
|
|
|
|
|
|
|
|
return (UPAP_AUTHACK);
|
|
|
|
}
|
|
|
|
</code>
|
|
|
|
<p>
|
|
|
|
The user's password is placed into <tt>pw->pw_passwd</tt>, so all we really
|
|
|
|
need to do is add the function <tt>getspnam</tt>. This will put the
|
|
|
|
password into <tt>spwd->sp_pwdp</tt>.
|
|
|
|
<p>
|
|
|
|
We will add the function <tt>pwauth</tt> to perform the actual authentication.
|
|
|
|
This will automatically perform secondary authentication if the shadow file
|
|
|
|
is setup for it.
|
|
|
|
<p>
|
|
|
|
Function <tt>auth.c</tt> after modifications to support shadow:
|
|
|
|
|
|
|
|
<code>
|
|
|
|
/*
|
|
|
|
* login - Check the user name and password against the system
|
|
|
|
* password database, and login the user if OK.
|
|
|
|
*
|
|
|
|
* This function has been modified to support the Linux Shadow Password
|
|
|
|
* Suite if USE_SHADOW is defined.
|
|
|
|
*
|
|
|
|
* returns:
|
|
|
|
* UPAP_AUTHNAK: Login failed.
|
|
|
|
* UPAP_AUTHACK: Login succeeded.
|
|
|
|
* In either case, msg points to an appropriate message.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
login(user, passwd, msg, msglen)
|
|
|
|
char *user;
|
|
|
|
char *passwd;
|
|
|
|
char **msg;
|
|
|
|
int *msglen;
|
|
|
|
{
|
|
|
|
struct passwd *pw;
|
|
|
|
char *epasswd;
|
|
|
|
char *tty;
|
|
|
|
|
|
|
|
#ifdef USE_SHADOW
|
|
|
|
struct spwd *spwd;
|
|
|
|
struct spwd *getspnam();
|
|
|
|
#endif
|
|
|
|
|
|
|
|
if ((pw = getpwnam(user)) == NULL) {
|
|
|
|
return (UPAP_AUTHNAK);
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef USE_SHADOW
|
|
|
|
spwd = getspnam(user);
|
|
|
|
if (spwd)
|
|
|
|
pw->pw_passwd = spwd->sp-pwdp;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* XXX If no passwd, let NOT them login without one.
|
|
|
|
*/
|
|
|
|
if (pw->pw_passwd == '\0') {
|
|
|
|
return (UPAP_AUTHNAK);
|
|
|
|
}
|
|
|
|
#ifdef HAS_SHADOW
|
|
|
|
if ((pw->pw_passwd && pw->pw_passwd[0] == '@'
|
|
|
|
&& pw_auth (pw->pw_passwd+1, pw->pw_name, PW_LOGIN, NULL))
|
|
|
|
|| !valid (passwd, pw)) {
|
|
|
|
return (UPAP_AUTHNAK);
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
epasswd = crypt(passwd, pw->pw_passwd);
|
|
|
|
if (strcmp(epasswd, pw->pw_passwd)) {
|
|
|
|
return (UPAP_AUTHNAK);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
syslog(LOG_INFO, "user %s logged in", user);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Write a wtmp entry for this user.
|
|
|
|
*/
|
|
|
|
tty = strrchr(devname, '/');
|
|
|
|
if (tty == NULL)
|
|
|
|
tty = devname;
|
|
|
|
else
|
|
|
|
tty++;
|
|
|
|
logwtmp(tty, user, ""); /* Add wtmp login entry */
|
|
|
|
logged_in = TRUE;
|
|
|
|
|
|
|
|
return (UPAP_AUTHACK);
|
|
|
|
}
|
|
|
|
</code>
|
|
|
|
<p>
|
|
|
|
Careful examination will reveal that we made another change as well. The
|
|
|
|
original version allowed access (returned <tt>UPAP_AUTHACK</tt> if there
|
|
|
|
was NO password in the <tt>/etc/passwd</tt> file. This is <em>not</em>
|
|
|
|
good, because a common use of this login feature is to use one account
|
|
|
|
to allow access to the PPP process and then check the username and password
|
|
|
|
supplied by PAP with the username in the <tt>/etc/passwd</tt> file and
|
|
|
|
the password in the <tt>/etc/shadow</tt> file.
|
|
|
|
<p>
|
|
|
|
So if we had set the original version up to run as the shell for a user i.e.
|
|
|
|
<tt>ppp</tt>, then anyone could get a ppp connection by setting their PAP to user
|
|
|
|
<tt>ppp</tt> and a password of null.
|
|
|
|
<p>
|
|
|
|
We fixed this also by returning <tt>UPAP_AUTHNAK</tt> instead of
|
|
|
|
<tt>UPAP_AUTHACK</tt> if the password field was empty.
|
|
|
|
<p>
|
|
|
|
Interestingly enough, <tt>pppd-2.2.0</tt> has the same problem.
|
|
|
|
<p>
|
|
|
|
Next we need to modify the Makefile so that two things occur:
|
|
|
|
<tt>USE_SHADOW</tt> must be defined, and <tt>libshadow.a</tt> needs to be
|
|
|
|
added to the linking process.
|
|
|
|
<p>
|
|
|
|
Edit the Makefile, and add:
|
|
|
|
<tscreen><verb>LIBS = -lshadow
|
|
|
|
</verb></tscreen>
|
|
|
|
<p>
|
|
|
|
Then we find the line:
|
|
|
|
<tscreen><verb>COMPILE_FLAGS = -I.. -D_linux_=1 -DGIDSET_TYPE=gid_t
|
|
|
|
</verb></tscreen>
|
|
|
|
<p>
|
|
|
|
And change it to:
|
|
|
|
<tscreen><verb>COMPILE_FLAGS = -I.. -D_linux_=1 -DGIDSET_TYPE=gid_t -DUSE_SHADOW
|
|
|
|
</verb></tscreen>
|
|
|
|
<p>
|
|
|
|
Now make and install.
|
|
|
|
|
|
|
|
<sect><heading>Frequently Asked Questions.
|
|
|
|
<p>
|
|
|
|
<em>Q:</em> I used to control which tty's <em>root</em> could log into using
|
|
|
|
the file <tt>/etc/securettys</tt>, but it doesn't seem to work anymore,
|
|
|
|
what's going on?
|
|
|
|
<p>
|
|
|
|
<em>A:</em> The file <tt>/etc/securettys</tt> does absolutely nothing now
|
|
|
|
that the <em>Shadow Suite</em> is installed. The tty's that <em>root</em>
|
|
|
|
can use are now located in the login configuration file
|
|
|
|
<tt>/etc/login.defs</tt>. The entry in this file may point to another file.
|
|
|
|
<p>
|
|
|
|
|
|
|
|
<em>Q:</em> I installed the <em>Shadow Suite</em>, but now I can't login,
|
|
|
|
what did I miss?
|
|
|
|
<p>
|
|
|
|
<em>A:</em> You probably installed the Shadow programs, but didn't run
|
|
|
|
<tt>pwconv</tt> or you forgot to copy <tt>/etc/npasswd</tt> to
|
|
|
|
<tt>/etc/passwd</tt> and <tt>/etc/nshadow</tt> to <tt>/etc/shadow</tt>.
|
|
|
|
Also, you may need to copy <tt>login.defs</tt> to <tt>/etc</tt>.
|
|
|
|
<p>
|
|
|
|
|
|
|
|
<em>Q:</em> In the section on xlock, it said to change the group ownership
|
|
|
|
of the <tt>/etc/shadow</tt> file to <tt>shadow</tt>. I don't have a
|
|
|
|
<tt>shadow</tt> group, what do I do?
|
|
|
|
<p>
|
|
|
|
<em>A:</em> You can add one. Simply edit the <tt>/etc/group</tt> file, and
|
|
|
|
insert a line for the shadow group. You need to ensure that the group
|
|
|
|
number is not used by another group, and you need to insert it before the
|
|
|
|
<tt>nogroup</tt> entry. Or you can simply suid <tt>xlock</tt> to root.
|
|
|
|
|
|
|
|
<p>
|
|
|
|
<em>Q:</em> Is there a mailing list for the Linux Shadow Password Suite?
|
|
|
|
<p>
|
|
|
|
<em>A:</em> Yes, but it's for the development and beta testing of the
|
|
|
|
next Shadow Suite for Linux. You can get added to the list by mailing to:
|
|
|
|
<tt>shadow-list-request@neptune.cin.net</tt> with a subject of:
|
|
|
|
<tt>subscribe</tt>. The list is actually for discussions of the Linux
|
|
|
|
<tt>shadow-YYMMSS</tt> series of releases. You should join if you want to
|
|
|
|
get involved in further development or if you install the Suite on your
|
|
|
|
system and want to get information on newer releases.
|
|
|
|
|
|
|
|
<p>
|
|
|
|
<em>Q:</em> I installed the <em>Shadow Suite</em>, but when I use the
|
|
|
|
<tt>userdel</tt> command, I get "userdel: cannot open shadow group file",
|
|
|
|
what did I do wrong?
|
|
|
|
<p>
|
|
|
|
<em>A:</em> You compiled the <em>Shadow Suite</em> with the
|
|
|
|
<tt>SHADOWGRP</tt> option enabled, but you don't have an
|
|
|
|
<tt>/etc/gshadow</tt> file. You need to either edit the <tt>config.h</tt>
|
|
|
|
file and recompile, or create an <tt>/etc/group</tt> file. See the section
|
|
|
|
on shadow groups.
|
|
|
|
|
|
|
|
<p>
|
|
|
|
<em>Q:</em> I installed the <em>Shadow Suite</em> but now I'm getting
|
|
|
|
encoded passwords back in my <tt>/etc/passwd</tt> file, what's wrong?
|
|
|
|
<p>
|
|
|
|
<em>A:</em> You either enabled the <tt>AUTOSHADOW</tt> option in the Shadow
|
|
|
|
<tt>config.h</tt> file, or your <tt>libc</tt> was compiled with the
|
|
|
|
<tt>SAHDOW_COMPAT</tt> option. You need to determine which is the problem,
|
|
|
|
and recompile.
|
|
|
|
|
|
|
|
<sect><heading>Copyright Message.
|
|
|
|
<p>
|
|
|
|
The Linux Shadow Password HOWTO is Copyright (c) 1996 Michael H. Jackson.
|
|
|
|
<p>
|
|
|
|
Permission is granted to make and distribute verbatim copies of
|
|
|
|
this document provided the copyright notice and this permission notice
|
|
|
|
are preserved on all copies.
|
|
|
|
<p>
|
|
|
|
Permission is granted to copy and distribute modified versions of this
|
|
|
|
document under the conditions for verbatim copies above, provided a notice
|
|
|
|
clearly stating that the document is a modified version is also included in
|
|
|
|
the modified document.
|
|
|
|
<p>
|
|
|
|
Permission is granted to copy and distribute translations of this document
|
|
|
|
into another language, under the conditions specified above for modified
|
|
|
|
versions.
|
|
|
|
<p>
|
|
|
|
Permission is granted to convert this document into another media under
|
|
|
|
the conditions specified above for modified versions provided the requirement
|
|
|
|
to acknowledge the source document is fulfilled by inclusion of an obvious
|
|
|
|
reference to the source document in the new media. Where there is any
|
|
|
|
doubt as to what defines 'obvious' the copyright owner reserves the right
|
|
|
|
to decide.
|
|
|
|
|
|
|
|
<sect><heading>Miscellaneous and Acknowledgments.
|
|
|
|
<p>
|
|
|
|
The code examples for <tt>auth.c</tt> are taken from pppd-1.2.1d and
|
|
|
|
ppp-2.1.0e, Copyright (c) 1993 and The Australian National University and
|
|
|
|
Copyright (c) 1989 Carnegie Mellon University.
|
|
|
|
<p>
|
|
|
|
Thanks to Marek Michalkiewicz <marekm@i17linuxb.ists.pwr.wroc.pl> for
|
|
|
|
writing and maintaining the <em>Shadow Suite</em> for Linux, and for his
|
|
|
|
review and comments on this document.
|
|
|
|
<p>
|
|
|
|
Thanks to Ron Tidd <rtidd@tscnet.com> for his helpful review and testing.
|
|
|
|
<p>
|
|
|
|
Thanks to everyone who has sent me feedback to help improve this document.
|
|
|
|
<p>
|
|
|
|
Please, if you have any comments or suggestions then mail them to me.
|
|
|
|
|
|
|
|
regards
|
|
|
|
<p>
|
|
|
|
<htmlurl url="mailto:mhjack@tscnet.com"
|
|
|
|
name="Michael H. Jackson <mhjack@tscnet.com>">
|
|
|
|
|
|
|
|
</article>
|