395 lines
14 KiB
Plaintext
395 lines
14 KiB
Plaintext
Following is all the
|
||
information that you need to understand the workings of the UNIX operating
|
||
system (Berkley 4.2).
|
||
|
||
Patched together by The War
|
||
|
||
|
||
On the security side of UNIX:
|
||
-----------------------------
|
||
On the Security of UNIX Dennis M. Ritchie Recently there has been much interest
|
||
in the security aspects of operating systems and software. At issue is the
|
||
ability to prevent undesired disclosure of information, destruction of
|
||
information, and harm to the functioning of the system. This paper discusses
|
||
the degree of security which can be provided under the system and offers a
|
||
number of hints on how to improve security. The first fact to face is that was
|
||
not developed with security, in any realistic sense, in mind; this fact alone
|
||
guarantees a vast number of holes. (Actually the same statement can be made
|
||
with respect to most systems.) The area of security in which is theoretically
|
||
weakest is in protecting against crashing or at least crippling the operation
|
||
of the system.
|
||
The problem here is not mainly in uncritical acceptance of bad parameters
|
||
to system calls there may be bugs in this area, but none are known- but rather
|
||
in lack of checks for excessive consumption of resources. Most notably, there
|
||
is no limit on the amount of disk storage used, either in total space allocated
|
||
or in the number of files or directories. Here is a particularly ghastly shell
|
||
sequence guaranteed to stop the system:
|
||
|
||
while :; do
|
||
mkdir x
|
||
cd x
|
||
done
|
||
|
||
Ether a panic will occur because all
|
||
the i-nodes on the device are used up,
|
||
or all the disk blocks will be
|
||
consumed, thus preventing anyone from
|
||
writing files on the device. In this
|
||
version of the system, users are
|
||
prevented from creating more than a set
|
||
number of processes simultaneously, so
|
||
unless users are in collusion it is
|
||
unlikely that any one can stop the
|
||
system altogether. However, creation
|
||
of 20 or so CPU or disk-bound jobs
|
||
leaves few resources available for
|
||
others. Also, if many large jobs are
|
||
run simultaneously, swap space may run
|
||
out, causing a panic. It should be
|
||
evident that excessive consumption of
|
||
disk space, files, swap space, and
|
||
processes can easily occur
|
||
accidentally in malfunctioning programs
|
||
as well as at command level. In fact
|
||
is essentially defenseless against
|
||
this kind of abuse, nor is there any
|
||
easy fix. The best that can be said is
|
||
that it is generally fairly easy to
|
||
detect what has happened when disaster
|
||
strikes, to identify the user
|
||
responsible, and take appropriate
|
||
action. In practice, we have found
|
||
that difficulties in this area are
|
||
rather rare, but we have not been faced
|
||
with malicious users, and enjoy a
|
||
fairly generous supply of resources
|
||
which have served to cushion us against
|
||
accidental overconsumption. The
|
||
picture is considerably brighter in the
|
||
area of protection of information from
|
||
unauthorized perusal and destruction.
|
||
Here the degree of security seems (
|
||
almost) adequate theoretically, and the
|
||
problems lie more in the necessity for
|
||
care in the actual use of the system.
|
||
Each file has associated with it eleven
|
||
bits of protection information together
|
||
with a user identification number and a
|
||
usergroup identification number (UID
|
||
and GID). Nine of the protection bits
|
||
are used to specify independently
|
||
permission to read, to write, and to
|
||
execute the file to the user himself,
|
||
to members of the user's group, and to
|
||
all other users. Each process
|
||
generated by or for a user has
|
||
associated with it an effective UID and
|
||
a real UID, and an effective and real
|
||
GID. When an attempt is made to access
|
||
the file for reading, writing, or
|
||
execution, the user process's effective
|
||
UID is compared against the file's UID;
|
||
if a match is obtained, access is
|
||
granted provided the read, write, or
|
||
execute bit respectively for the user
|
||
himself is present. If the UID for the
|
||
file and for the process fail to
|
||
match, but the GID's do match, the
|
||
group bits are used; if the GID's do
|
||
not match, the bits for other users
|
||
are tested. The last two bits of each
|
||
file's protection information, called
|
||
the set-UID and set-GID bits, are used
|
||
only when the file is executed as a
|
||
program. If, in this case, the set-UID
|
||
bit is on for the file, the effective
|
||
UID for the process is changed to the
|
||
UID associated with the file; the
|
||
change persists until the process
|
||
terminates or until the UID changed
|
||
again by another execution of a set-UID
|
||
file. Similarly the effective group
|
||
ID of a process is changed to the GID
|
||
associated with a file when that file
|
||
is executed and has the set-GID bit
|
||
set. The real UID and GID of a process
|
||
do not change when any file is
|
||
executed, but only as the result of a
|
||
privileged system call. The basic
|
||
notion of the set-UID and set-GID bits
|
||
is that one may write a program which
|
||
is executable by others and which
|
||
maintains files accessible to others
|
||
only by that program. The classical
|
||
example is the game-playing program
|
||
which maintains records of the scores
|
||
of its players. The program itself has
|
||
to read and write the score file, but
|
||
no one but the game's sponsor can be
|
||
allowed unrestricted access to the file
|
||
lest they manipulate the game to their
|
||
own advantage. The solution is to turn
|
||
on the set-UID bit of the game program.
|
||
When, and only when, it is invoked by
|
||
players of the game, it may update the
|
||
score file but ordinary programs
|
||
executed by others cannot access the
|
||
score. There are a number of special
|
||
cases involved in determining access
|
||
permissions. Since executing a
|
||
directory as a program is a meaningless
|
||
operation, the execute-permission bit,
|
||
for directories, is taken instead to
|
||
mean permission to earch he directory
|
||
for a given file during the scanning of
|
||
a path name; thus if a directory has
|
||
execute permission but no read
|
||
permission for a given user, he may
|
||
access files with known names in the
|
||
directory, but may not read (list) the
|
||
entire contents of the directory. Write
|
||
permission on a directory is
|
||
interpreted to mean that the user may
|
||
create and delete files in that
|
||
directory; it is impossible for any
|
||
user to write directly into any
|
||
directory. Another, and from the point
|
||
of view of security, much more serious
|
||
special case is that there is a ``super
|
||
user'' who is able to read any file
|
||
and write any nondirectory. The super-
|
||
user is also able to change the
|
||
protection mode and the owner UID and
|
||
GID of any file and to invoke
|
||
privileged system calls. It must be
|
||
recognized that the mere notion of a
|
||
super-user is a theoretical, and
|
||
usually practical, blemish on any
|
||
protection scheme. The first necessity
|
||
for a secure system is of course
|
||
arranging that all files and
|
||
directories have the proper protection
|
||
modes. Traditionally, software has been
|
||
exceedingly permissive in this regard;
|
||
essentially all commands create files
|
||
readable and writable by everyone. In
|
||
the current version, this policy may be
|
||
easily adjusted to suit the needs of
|
||
the installation or the individual
|
||
user. Associated with each process and
|
||
its descendants is a mask, which is in
|
||
effect with the mode of every file and
|
||
directory created by that process. In
|
||
this way, users can arrange that, by
|
||
default, all their files are no more
|
||
accessible than they wish. The
|
||
standard mask, set by allows all
|
||
permissions to the user himself and to
|
||
his group, but disallows writing by
|
||
others. To maintain both data privacy
|
||
and data integrity, it is necessary,
|
||
and largely sufficient, to make one's
|
||
files inaccessible to others. The lack
|
||
of sufficiency could follow from the
|
||
existence of set-UID programs created
|
||
by the user and the possibility of
|
||
total breach of system security in one
|
||
of the ways discussed below (or one of
|
||
the ways not discussed below). For
|
||
greater protection, an encryption
|
||
scheme is available. Since the editor
|
||
is able to create encrypted documents,
|
||
and the command can be used to pipe
|
||
such documents into the other text-
|
||
processing programs, the length of time
|
||
during which cleartext versions need
|
||
be available is strictly limited. The
|
||
encryption scheme used is not one of
|
||
the strongest known, but it is judged
|
||
adequate, in the sense that
|
||
cryptanalysis is likely to require
|
||
considerably more effort than more
|
||
direct methods of reading the encrypted
|
||
files. For example, a user who stores
|
||
data that he regards as truly secret
|
||
should be aware that he is implicitly
|
||
trusting the system administrator not
|
||
to install a version of the crypt
|
||
command that stores every typed
|
||
password in a file. Needless to say,
|
||
the system administrators must be at
|
||
least as careful as their most
|
||
demanding user to place the correct
|
||
protection mode on the files under
|
||
their control. In particular, it is
|
||
necessary that special files be
|
||
protected from writing, and probably
|
||
reading, by ordinary users when they
|
||
store sensitive files belonging to
|
||
other users. It is easy to write
|
||
programs that examine and change files
|
||
by accessing the device on which the
|
||
files live. On the issue of password
|
||
security, is probably better than most
|
||
systems. Passwords are stored in an
|
||
encrypted form which, in the absence of
|
||
serious attention from specialists in
|
||
the field, appears reasonably secure,
|
||
provided its limitations are
|
||
understood. In the current version, it
|
||
is based on a slightly defective
|
||
version of the Federal DES; it is
|
||
purposely defective so that easily-
|
||
available hardware is useless for
|
||
attempts at exhaustive key-search.
|
||
Since both the encryption algorithm and
|
||
the encrypted passwords are available,
|
||
exhaustive enumeration of potential
|
||
passwords is still feasible up to a
|
||
point. We have observed that users
|
||
choose passwords that are easy to
|
||
guess: they are short, or from a
|
||
limited alphabet, or in a dictionary.
|
||
Passwords should be at least six
|
||
characters long and randomly chosen
|
||
from an alphabet which includes digits
|
||
and special characters. Of course
|
||
there also exist feasible non-
|
||
cryptanalytic ways of finding out
|
||
passwords. For example: write a
|
||
program which types out ``login:'' on
|
||
the typewriter and copies whatever is
|
||
typed to a file of your own. Then
|
||
invoke the command and go away until
|
||
the victim arrives. The set-UID (
|
||
set-GID) notion must be used carefully
|
||
if any security is to be maintained.
|
||
The first thing to keep in mind is that
|
||
a writable set-UID file can have
|
||
another program copied onto it. For
|
||
example, if the super-user command is
|
||
writable, anyone can copy the shell
|
||
onto it and get a password-free version
|
||
of A more subtle problem can come from
|
||
set-UID programs which are not
|
||
sufficiently careful of what is fed
|
||
into them. To take an obsolete
|
||
example, the previous version of the
|
||
command was set-UID and owned by the
|
||
super-user. This version sent mail to
|
||
the recipient's own directory. The
|
||
notion was that one should be able to
|
||
send mail to anyone even if they want
|
||
to protect their directories from
|
||
writing. The trouble was that was
|
||
rather dumb: anyone could mail someone
|
||
else's private file to himself. Much
|
||
more serious is the following scenario:
|
||
make a file with a line like one in
|
||
the password file which allows one to
|
||
log in as the super-user. Then make a
|
||
link named ``.mail'' to the password
|
||
file in some writable directory on the
|
||
same device as the password file (say
|
||
/tmp). Finally mail the bogus login
|
||
line to /tmp/.mail; You can then login
|
||
as the superuser, clean up the
|
||
incriminating evidence, and have your
|
||
will. The fact that users can mount
|
||
their own disks and tapes as file
|
||
systems can be another way of gaining
|
||
superuser status. Once a disk pack is
|
||
mounted, the system believes what is on
|
||
it. Thus one can take a blank disk
|
||
pack, put on it anything desired, and
|
||
mount it. There are obvious and
|
||
unfortunate consequences. For
|
||
example: a mounted disk with garbage on
|
||
it will crash the system; one of the
|
||
files on the mounted disk can easily
|
||
be a password-free version of other
|
||
files can be unprotected entries for
|
||
special files. The only easy fix for
|
||
this problem is to forbid the use of to
|
||
unprivileged users. A partial
|
||
solution, not so restrictive, would be
|
||
to have the command examine the
|
||
special file for bad data, set-UID
|
||
programs owned by others, and
|
||
accessible special files, and balk at
|
||
unprivileged invokers.
|
||
|
||
|
||
-
|
||
Info about the /etc/passwd file:
|
||
---
|
||
|
||
NME
|
||
passwd - password file
|
||
|
||
DSCRIPTION
|
||
Passwd contains for each user the
|
||
following information:
|
||
|
||
name (login name, contains no
|
||
upper case)
|
||
encrypted password
|
||
numerical user ID
|
||
numerical group ID
|
||
user's real name, office,
|
||
extension, home phone.
|
||
initial working directory
|
||
program to use as Shell
|
||
|
||
The name may contain `&', meaning
|
||
insert the login name.
|
||
This information is set by the
|
||
chfn(1) command and used by
|
||
the finger(1) command.
|
||
|
||
This is an ASCII file. Each field
|
||
within each user's entry
|
||
is separated from the next by a
|
||
colon. Each user is
|
||
separated from the next by a new-
|
||
line. If the password
|
||
field is null, no password is
|
||
demanded; if the Shell field
|
||
is null, then /bin/sh is used.
|
||
|
||
This file resides in directory /
|
||
etc. Because of the
|
||
encrypted passwords, it can and
|
||
does have general read per-
|
||
mission and can be used, for
|
||
example, to map numerical user
|
||
ID's to names.
|
||
|
||
Appropriate precautions must be
|
||
taken to lock the file
|
||
against changes if it is to be
|
||
edited with a text editor;
|
||
vipw(8) does the necessary
|
||
locking.
|
||
|
||
FLES
|
||
/etc/passwd
|
||
|
||
SE ALSO
|
||
getpwent(3), login(1), crypt(3),
|
||
passwd(1), group(5),
|
||
chfn(1), finger(1), vipw(8),
|
||
adduser(8)
|
||
|
||
BGS
|
||
A binary indexed file format should be available for fast access.
|
||
|
||
User information (name, office, etc.) should be stored elsewhere.
|
||
---
|
||
|
||
Now if you have had the patience to read all of this and you have digested
|
||
it you know everything that you need to know about the Unix system to hold up
|
||
your end of an intelligent conversation.
|
||
|
||
Have fun!
|
||
|