MiniUnix/usr/doc/secur/secur

.de h
'sp 2
.tl '''UNIX Security - %'
'sp 3
..
.de f
'bp
..
.wh -6 f
.br
.wh 0 h
.de pg
.sp .5
.ti 5n
..
.de bd
.sp
.in 8n
.nf
..
.de ed
.sp
.in 0
.fi
..
.sp 2
.ce
.ft B
.ps 12
On the Security of UNIX
.sp
.ft I
.ce
Dennis M. Ritchie
.sp
.ft R
.ce
Bell Laboratories, Murray Hill, N. J.
.sp 2
.ps 10
.pg
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 UNIX system and offers a number of hints
on how to improve security.
.pg
The first fact to face is that UNIX 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 UNIX
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 the lack of any 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:
.bd
: loop
mkdir x
chdir x
goto loop
.ed
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 anyone from writing files
on the device.
.pg
Processes are another resource on which the only limit
is total exhaustion.
For example, the sequence
.bd
command&
command&
command&
.li
. . .
.ed
if continued long enough will use up all the slots in the
system's process table and prevent
anyone from executing any commands.
Alternatively, if the commands use much core,
swap space may run out, causing a panic.
Incidently, because of the implementation of process termination,
the above sequence is effective in stopping the system
no matter how short a time it takes each command to
terminate.
(The process-table slot is not freed until the terminated
process is waited for;
if no commands without ``&'' are executed,
the Shell never executes a ``wait.'')
.pg
It should be evident that unbounded consumption of disk
space, files, swap space, and processes can easily occur
accidentally in malfunctioning programs
as well as at command level.
In fact UNIX 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.
.pg
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.
.pg
Each UNIX 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 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.
.pg
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
ordinary programs executed by others cannot
access the score.
.pg
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 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.
.pg
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 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.
.pg
The first necessity for a secure system
is of course arranging that all files and directories
have the proper protection modes.
Unfortunately, UNIX software is exceedingly
permissive in this regard;
essentially all commands create files
readable and writable by everyone.
This means that more or less
continuous attention must be
paid to adjusting modes properly.
If one wants to keep one's files completely secret,
it is possible to remove all permissions from the directory in which they live,
which is easy and effective;
but if it is desired
to give general read permission while
preventing writing, things are more complicated.
The main problem is that write permission in a directory
means precisely that; it has nothing to do with
write permission for a file in that directory.
Thus a writeable file in a read-only directory may be changed,
or even truncated,
though not removed.
This fact is perfectly logical, though in this case unfortunate.
A case can be made for requiring write permission for
the directory of a file as well as for the file itself
before allowing writing.
(This possibility is more complicated than it seems
at first;
the system has to allow users to change their
own directories while forbidding
them to change the user-directory directory.)
.pg
A situation converse to the above-discussed
difficulty is also present_ it is possible to
delete a file if one has write permission for its directory
independently of any permissions for the file.
This problem is related more to self-protection
than protection from others.
It is largely mitigated by the fact that
the two major commands which delete named files
(mv and rm)
ask confirmation before deleting unwritable files.
.pg
It follows from this discussion
that to maintain both data privacy and
data integrity,
it is necessary, and largely sufficient,
to make one's directory 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).
.pg
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.
.pg
On the issue of password security,
UNIX 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.
Since both the encryption algorithm and the encrypted passwords
are available,
exhaustive enumeration of potential passwords
is feasible up to a point.
As a practical test of the possibilities in this area,
67 encrypted passwords were collected from 10 UNIX installations.
These were tested against all five-letter combinations,
all combinations of letters and digits of length four or less,
and all words in Webster's Second unabridged dictionary;
60 of the 67 passwords were found.
The whole process took about 12 hours of machine time.
This experience suggests that passwords should be
at least six characters long and randomly chosen from an alphabet
which includes digits and special characters.
.pg
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.
(It is this kind of possibility that makes it evident that
UNIX was not designed to be secure.)
.pg
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
.ul
(su)
command is writable,
anyone can copy the shell
onto it and get a password-free version
of
.ul
su.
A more subtle problem
can come from
set-UID programs which are not sufficiently
careful of what is fed into them.
In some systems, for example,
the
.ul
mail
command is set-UID and owned by the super-user.
The notion is that one should be able to send
mail to anyone even if they want to protect
their directories from writing.
The trouble is that
.ul
mail
is rather dumb:
anyone can 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 writeable
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.
.pg
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
.ul
su;
other files can be unprotected entries for special files.
The only easy fix for this problem is to
forbid the use of
.ul
mount
to unprivileged users.
A partial solution, not so restrictive,
would be to have the
.ul
mount
command examine the special file for bad data,
set-UID programs owned by others, and accessible
special files,
and balk at unprivileged invokers.