MirOS Manual: 16.security(SMM)

On the Security of UNIX                                  SMM:17-1

                     On the Security of UNIX

                        Dennis M. Ritchie

                     AT&T Bell Laboratories
                  Murray Hill, New Jersey 07974

     Recently there  has  been  much  interest  in  the  security
aspects  of operating systems and software. At issue is the abil-
ity 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.

     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 param-
eters  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

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.

     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
- UNIX is a registered trademark of AT&T  Bell  Labora-
tories in the USA and other countries.

SMM:17-2                                  On the Security of UNIX

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 acciden-
tally 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 disas-
ter strikes, to identify the user responsible, and take appropri-
ate  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  protec-
tion  of  information  from unauthorized perusal and destruction.
Here the degree of security  seems  (almost)  adequate  theoreti-
cally, and the problems lie more in the necessity for care in the
actual use of the system.

     Each UNIX file has associated with it eleven bits of protec-
tion 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 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  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  associ-
ated  with  the  file; the change persists until the process ter-
minates 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 pro-
cess 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 main-
tains files accessible to others only by that program. The  clas-
sical example is the game-playing program which maintains records
of the scores of its players. The program itself has to read  and

On the Security of UNIX                                  SMM:17-3

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  direc-
tories,  is taken instead to mean permission to search the direc-
tory 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  direc-
tory,  but  may not read (list) the entire contents of the direc-
tory. 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 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 arrang-
ing  that  all  files  and directories have the proper protection
modes. Traditionally, UNIX software has been exceedingly  permis-
sive  in this regard; essentially all commands create files read-
able and writable by everyone. In the current version, this  pol-
icy  may be easily adjusted to suit the needs of the installation
or the individual user. Associated with each process and its des-
cendants  is  a  mask, which is in effect and-ed 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  login,
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 inaccessi-
ble to others. The lack of  sufficiency  could  follow  from  the
existence  of set-UID programs created by the user and the possi-
bility of total breach of system security in one of the ways dis-
cussed  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 crypt com-
mand 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

SMM:17-4                                  On the Security of UNIX

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 pro-
tection 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, 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. 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. Pass-
words 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 (su) command is writable, any-
one can copy the shell onto it and get a password-free version of
su.  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 mail 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 mail 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  pass-
word  file  (say  /tmp).  Finally  mail  the  bogus login line to

On the Security of UNIX                                  SMM:17-5

/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  su; other files can be unprotected entries for
special files. The only easy fix for this problem  is  to  forbid
the  use  of mount to unprivileged users. A partial solution, not
so restrictive, would be to have the mount  command  examine  the
special  file for bad data, set-UID programs owned by others, and
accessible special files, and balk at unprivileged invokers.

Generated on 2017-04-03 16:26:17 by $MirOS: src/scripts/roff2htm,v 1.88 2017/01/29 00:51:06 tg Exp $

These manual pages and other documentation are copyrighted by their respective writers; their source is available at our CVSweb, AnonCVS, and other mirrors. The rest is Copyright © 2002–2017 The MirOS Project, Germany.
This product includes material provided by mirabilos.

This manual page’s HTML representation is supposed to be valid XHTML/1.1; if not, please send a bug report — diffs preferred.