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
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
However, creation of 20 or so CPU or disk-bound jobs
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
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
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