199 lines
13 KiB
Plaintext
199 lines
13 KiB
Plaintext
|
|
***************************************************************
|
|
** **
|
|
** A Paper on "The Security of UNIX" by Dennis M. Ritchie. **
|
|
** Aquired by Weapons, Distriubted by THUGS. **
|
|
** A Solsbury Hill Text File. **
|
|
** **
|
|
***************************************************************
|
|
|
|
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 disclo-
|
|
sure 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 Either
|
|
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 any-
|
|
one 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. Howev-
|
|
er, 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 sys-
|
|
tem. Each file has associated with it eleven bits of protection
|
|
information together with a user identification number and a
|
|
user-group identification number (UID and GID). Nine of the pro-
|
|
tection 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 pro-
|
|
cess generated by or for a user has associated with it an effec-
|
|
tive UID and a real UID, and an effective and real GID. When an
|
|
attempt is made to access the file for reading, writing, or exe-
|
|
cution, 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 as-
|
|
sociated 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 exe-
|
|
cuted 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 oth-
|
|
ers 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 unres-
|
|
tricted 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 exe-
|
|
cuted 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 search the directory for a given file during
|
|
the scanning of a path name; thus if a directory has execute per-
|
|
mission 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
|
|
non-directory. The super-user is also able to change the protec-
|
|
tion mode and the owner UID and GID of any file and to invoke
|
|
privileged system calls. It must be recognized that the mere no-
|
|
tion 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 direc-
|
|
tories 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 ef-
|
|
fect 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 pro-
|
|
grams 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 encrypt-
|
|
ed documents, and the command can be used to pipe such documents
|
|
into the other text-processing programs, the length of time dur-
|
|
ing which cleartext versions need be available is strictly limit-
|
|
ed. 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 pur-
|
|
posely defective so that easily-available hardware is useless for
|
|
attempts at exhaustive key-search. Since both the encryption al-
|
|
gorithm 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) no-
|
|
tion 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 ver-
|
|
sion of the command was set-UID and owned by the super-user.
|
|
This version sent mail to the recipient's own directory. The no-
|
|
tion 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
|
|
super-user, 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 super-user 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 for-
|
|
bid 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 accessi-
|
|
ble special files, and balk at unprivileged invokers.
|
|
|
|
$
|
|
|