df@sei.cmu.edu (Dan Farmer) (01/08/91)
#!/bin/sh
# This is part 06 of cops
# ============= cops/docs/cops ==============
if test ! -d 'cops'; then
echo 'x - creating directory cops'
mkdir 'cops'
fi
if test ! -d 'cops/docs'; then
echo 'x - creating directory cops/docs'
mkdir 'cops/docs'
fi
if test -f 'cops/docs/cops' -a X"$1" != X"-c"; then
echo 'x - skipping cops/docs/cops (File already exists)'
else
echo 'x - extracting cops/docs/cops (Text)'
sed 's/^X//' << 'SHAR_EOF' > 'cops/docs/cops' &&
X.TH COPS 1 "Jan 4, 1991"
X.UC 4
X.SH NAME
Xcops \- Checks security of system for potential danger areas.
X.SH SYNOPSIS
X.B cops
X.SH DESCRIPTION
X.I cops
Xruns a set of programs that each check a different aspect of security
Xon a Unix system. If any potential security holes do exist, the results
Xare either mailed or saved to a report file.
X.PP
XThe following programs are currently executed by
X.I cops
X\-\- see the appropriate man page or other documentation for
Xmore information on each of the following:
X.Ps
Xroot.chk dev.chk group.chk
Xhome.chk rc.chk passwd.chk
Xpass.chk user.chk cron.chk
Xmisc.chk is_able.chk crc.chk
X.Pe
XIn addition, it runs the U-kuang expert system, which runs these
Xadditional programs:
X.Ps
Xinit_kuang kuang addto
Xclearfiles filewriters members
X.Pe
X.PP
X.I cops
Xuses three internal variables that may be changed to determine where
Xwho gets any reports generated, if it is to mailed or saved to a file.
XThe variable $SECURE_USERS is used to determine who gets mailed any
Xresults. $SECURE is the directory that
X.I cops
Xis in. And finally, if the variable $MMAIL is set to be NO, then
X.I cops
Xwill save the report in a subdirectory with the same name as the host
Xit is being run on, in a file called
X.I year_month_date
X, where these stand for the actual values, not that string :-).
XOtherwise,
X.I cops
Xwill mail the report to the whomever is listed in $SECURE_USERS.
X.PP
XIf the variables $ONLY_DIFF and $MMAIL are set to be "YES", then cops
Xwill examine the last report saved to a file, and compare it with the
Xcurrent one. If any differences do exist, then it will be mailed; else,
Xthe report will be discarded.
X.PP
XFor the curious, or those that are gluttons for punishment, you can
Xset the variable $BIT_BUCKET to be a file, or null, for stdout, to see
Xall the error messages and such. Some of the programs in cops print
Xout an error message if a file isn't found (for instance, if you put
Xa file to be checked in the
X.I is_able.lst
Xconfiguration file, and it doesn't exist, it will not complain to the
Xfinal report, only here; by default, this is our friend /dev/null.
X.SH FILES
X.EX 0
Xroot.chk dev.chk group.chk
Xhome.chk rc.chk passwd.chk
Xpass.chk user.chk cron.chk
Xmisc.chk init_kuang kuang
Xaddto clearfiles filewriters
Xmembers crc.chk
X.EE
X.SH "SEE ALSO"
X.EX 0
Xroot.chk(1) dev.chk(1) file.chk(1)
Xgroup.chk(1) home.chk(1) rc.chk(1)
Xpasswd.chk(1) pass.chk(1) user.chk(1)
Xcron.chk(1) misc.chk(1) kuang(1)
XCRC.README KUANG.README
X.EE
SHAR_EOF
chmod 0600 cops/docs/cops ||
echo 'restore of cops/docs/cops failed'
Wc_c="`wc -c < 'cops/docs/cops'`"
test 2568 -eq "$Wc_c" ||
echo 'cops/docs/cops: original size 2568, current size' "$Wc_c"
fi
# ============= cops/docs/dev.chk ==============
if test -f 'cops/docs/dev.chk' -a X"$1" != X"-c"; then
echo 'x - skipping cops/docs/dev.chk (File already exists)'
else
echo 'x - extracting cops/docs/dev.chk (Text)'
sed 's/^X//' << 'SHAR_EOF' > 'cops/docs/dev.chk' &&
X.TH DEV.CHK 1 "December 31, 1989"
X.UC 4
X.SH NAME
Xdev.chk \- Checks writability of devices and special files.
X.SH SYNOPSIS
X.B dev.chk
X[
X\-g
X]
X.SH DESCRIPTION
X.I dev.chk
Xchecks the permissions of /dev/mem, /dev/kmem, and
Xall devs listed in the file /etc/fstab (the
X.I mount
Xcommand would be
Xa preferable way of getting the file system name, but the syntax of the
Xoutput is variable from machine to machine), and flags them if they are
Xreadable by using the
X.I is_readable
Xcommand, unless they are NFS mounted,
Xin which case they are ignored. It also checks for unrestricted NFS
Xmountings in /etc/exports, and finally checks a small number of key files
Xthat should not be world readable.
X.PP
Xoptions are:
X.TP
X.B \-g
XCheck for group writability as well as world.
X.SH FILES
X.EX 0
X/usr/adm/sulog
X/etc/btmp
X/.netrc
X/etc/fstab
X/etc/exports
XL.sys
X.EE
X.SH "SEE ALSO"
Xis_writable(1)
SHAR_EOF
chmod 0600 cops/docs/dev.chk ||
echo 'restore of cops/docs/dev.chk failed'
Wc_c="`wc -c < 'cops/docs/dev.chk'`"
test 875 -eq "$Wc_c" ||
echo 'cops/docs/dev.chk: original size 875, current size' "$Wc_c"
fi
# ============= cops/docs/CRC.README ==============
if test -f 'cops/docs/CRC.README' -a X"$1" != X"-c"; then
echo 'x - skipping cops/docs/CRC.README (File already exists)'
else
echo 'x - extracting cops/docs/CRC.README (Text)'
sed 's/^X//' << 'SHAR_EOF' > 'cops/docs/CRC.README' &&
X
X This README.suid and everything but the C programs has been hacked up be
Xme, so all problems you have are probably due to me, unless you can't compile
Xthe files. Then blame Jon :-)
X
X This checks for unexpected file system corruption or security breaches.
XIt's nice to be able to say that you know all your files are as they should
Xbe. Mark Mendel wrote most of crc.c and Jon Zeef wrote crc_check.c. Seems
Xto work fine on BSD or SYS V.
X
XTo use it:
X
X1) You first create a crc list with the script "crc.chk", which takes one
Xargument, the seed for the crc generator. It reads the file "crc_list"
Xfor a list of files to check; what I have are some of the more interesting
Xbinaries, but you can add or delete from this list to your hearts content.
XWildcards or specific file names are fine. The first time you run it,
Xit will create a file called "crc.files", which contains all the crc
Xvalues you generated. Optionally, you can do a:
X
Xfind / -mount -print | sort | xargs ./crc -v > crc.tmp
X
X However, "xargs" is a security problem, when combined with find. Use
Xthis judiciously, if at all, unless your vendor puts some "safe" options
Xto find in.
X
X2) You can now use "crc.chk" to compare this "crc.files" file to a crc list
Xcreated each time you run the shell program. If everything is ok, nothing
Xis outputted, otherwise, the results are either mailed to the user INFORM,
Xon line xxx, or saved to a file "crc.results". You *MUST* use the same
Xseed each time you run the program, or the numbers generated will be
Xdifferent each time you run the program, which kind of makes it useless.
X
XIMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT
XIMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT
XIMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT
X
X Have I got your attention? Good. There are some fundamental problems
Xwith using a crc program like this. *If* you use a seed that is hardcoded
Xin the program, or no seed at all, this is *bad*. That means to really
Xuse this program usefully, you can't run it in crontab, like the rest
Xof COPS. Even worse, you should really store the results offline, since
Xanyone who breaks into your machine can modify a binary file, run the
Xcrc checker again, then put the new values in your file. That's the
Xright way. But I know that most of you won't do this, so by default,
X"crc.chk" just stores everything like everything else, in the COPS secure
Xdirectory. It can still help you, if the attacker doesn't know where
Xyou keep stuff, or doesn't know enough to trash your database of old
Xcrc values. If nothing else, be sure that you keep your older values
Xon tape or secondary medium, so when your system gets kicked around a
Xbit, you can grab the crc program off the tape (the intruder could modify
Xthat, too, you know), run it on your binaries, and finally compare it
Xto your old values. Believe me, this is a lot easier, though still not
Xperfect, than reloading everything on your system from tape, then still
Xnot knowing. I've put it in the "cops" shell script, but left it commented
Xout, on line 123, so if you want to use it this way, just uncomment this
Xline.
X One thing you can do, if you keep the numbers online, is do a crc on the
Xfile of values you keep; write it down, or memorize it, then if it is ever
Xtampered with, you can detect it.
X
X Jon goes on about the initial crc value, and other stuff:
X
X=========================================================================
X ... don't tell anyone what this is, you can
X make it nearly impossible for anyone to modify a file in such a way
X that it has the same crc value as the old one (primarily because they
X don't know what the old one was). If anyone does discover a way to
X make files of the same size that produce the same unknown crc value
X for any unknown -i value, let me know.
X
X To really do it right, you need to
X
X 1) Run find_crc in single user mode (unless you modify the crc source).
X 2) Store all crc results offline.
X 3) Don't let anyone see your -i value or the crc results.
X
X Please send me any modifications you make.
X
X Jon Zeeff
X zeeff@b-tech.ann-arbor.mi.us
X=========================================================================
X
X Send 'em to me, too!
X
X -- dan
SHAR_EOF
chmod 0600 cops/docs/CRC.README ||
echo 'restore of cops/docs/CRC.README failed'
Wc_c="`wc -c < 'cops/docs/CRC.README'`"
test 4278 -eq "$Wc_c" ||
echo 'cops/docs/CRC.README: original size 4278, current size' "$Wc_c"
fi
# ============= cops/docs/home.chk ==============
if test -f 'cops/docs/home.chk' -a X"$1" != X"-c"; then
echo 'x - skipping cops/docs/home.chk (File already exists)'
else
echo 'x - extracting cops/docs/home.chk (Text)'
sed 's/^X//' << 'SHAR_EOF' > 'cops/docs/home.chk' &&
X.TH HOME.CHK 1 "December 31, 1989"
X.UC 4
X.SH NAME
Xhome.chk \- Checks user home directories for world writability.
X.SH SYNOPSIS
X.B home.chk
X.SH DESCRIPTION
XThis checks all of the user home directories (it calls getpwent() to
Xget user directories) for world writability.
SHAR_EOF
chmod 0600 cops/docs/home.chk ||
echo 'restore of cops/docs/home.chk failed'
Wc_c="`wc -c < 'cops/docs/home.chk'`"
test 270 -eq "$Wc_c" ||
echo 'cops/docs/home.chk: original size 270, current size' "$Wc_c"
fi
# ============= cops/docs/pass.chk ==============
if test -f 'cops/docs/pass.chk' -a X"$1" != X"-c"; then
echo 'x - skipping cops/docs/pass.chk (File already exists)'
else
echo 'x - extracting cops/docs/pass.chk (Text)'
sed 's/^X//' << 'SHAR_EOF' > 'cops/docs/pass.chk' &&
X.TH PASS.CHK 1 "Jan 4, 1991"
X.UC 4
X.SH NAME
Xpass.chk \- Checks for poor passwords in a password file.
X.SH SYNOPSIS
X.B pass.chk
X[
Xoptions
X]
X.SH DESCRIPTION
XBy default
X.I pass.chk
Xonly checks for accounts with passwords the same
Xas the login name. The following options add more extensive checking. (The
Xtradeoff is cpu time -- with all options enabled it can run into the 100's
Xof MINUTES.) Any argument that does not begin with a "-" is assumed to be
Xa file name. (A single '-' means stdin.) If no file name is given, /etc/passwd
Xis used.
X.PP
XOptions are:
X.TP
X.B \-v
Xverbose -- list all guesses on stdout
X.TP
X.B \-u
Xoutput the username on the line of the password file
Xcurrently being checked. If the program stops
Xabruptly you will then know how far it got.
X.TP
X.B \-w file
Xuse the list of words contained in "file" as likely
Xpasswords. Words in the file are one to a line.
XA variable, "ARB_CONST", on line 6 of the source file, "pass.c",
Xdetermines how many words can be in the dictionary file. Default is 32000.
X.TP
X.B \-b
Xcheck all guesses backwards too
X.TP
X.B \-g
Xuse the Full Name portion of the gecos field, the user's .plan, .forward,
Xand .signature files to generate more guesses
X.TP
X.B \-s
Xcheck the single letters a-z, A-Z, 0-9 as passwords
X.TP
X.B \-c
Xwith each guess, check for all lower case and
Xall upper case versions too.
X.TP
X.B \-n
Xcomplain about null passwords (default is to keep quiet)
X.TP
X.B \-p
Xprint the password when guessed
X.B \-P file
Xuse an alternate password file
X.SH FILES
X.Ps
X/etc/passwd
X.Pe
SHAR_EOF
chmod 0600 cops/docs/pass.chk ||
echo 'restore of cops/docs/pass.chk failed'
Wc_c="`wc -c < 'cops/docs/pass.chk'`"
test 1524 -eq "$Wc_c" ||
echo 'cops/docs/pass.chk: original size 1524, current size' "$Wc_c"
fi
# ============= cops/docs/is_able ==============
if test -f 'cops/docs/is_able' -a X"$1" != X"-c"; then
echo 'x - skipping cops/docs/is_able (File already exists)'
else
echo 'x - extracting cops/docs/is_able (Text)'
sed 's/^X//' << 'SHAR_EOF' > 'cops/docs/is_able' &&
X.TH IS_ABLE 1 "Jan 4, 1991"
X.UC 4
X.SH NAME
Xis_able \- Check for write/read\-ability of a file.
X.SH SYNOPSIS
X.B is_able
Xfile {w|g|S|s} {r|w|s|B|b}
X.SH DESCRIPTION
X.I is_able
Xcan check a file to see if a file is either write/read-able by group or by
Xall, or if it is setuid/setgid, or a combination of these. A first argument
Xof "w" or "g" determines whether it is to be world or group writable,
Xrespectively, a "s" or "S" allows checking of SUID or SGID files, respectively.
XA second argument of "r", "w", or "s", stands for readability, writeability,
Xor set[ug]id-ness, respectively; a "B" and a "b" stand for read and write,
Xand set[ug]id and write, respectively.
X.I is_able
Xwith a write option Also checks the parent directories, if a complete path is
Xgiven, for writeability.
X.SH BUGS
XThe Andrew File System, or Mach, or the combination of the two, apparently
Xplays games with stat(), the way I get the file info, so it can report things
Xas writable, when they aren't. Sigh.
SHAR_EOF
chmod 0600 cops/docs/is_able ||
echo 'restore of cops/docs/is_able failed'
Wc_c="`wc -c < 'cops/docs/is_able'`"
test 980 -eq "$Wc_c" ||
echo 'cops/docs/is_able: original size 980, current size' "$Wc_c"
fi
# ============= cops/docs/kuang.1 ==============
if test -f 'cops/docs/kuang.1' -a X"$1" != X"-c"; then
echo 'x - skipping cops/docs/kuang.1 (File already exists)'
else
echo 'x - extracting cops/docs/kuang.1 (Text)'
sed 's/^X//' << 'SHAR_EOF' > 'cops/docs/kuang.1' &&
XNAME
X kuang - rule based system to find inconsistencies in the security
X configuration of a BSD 4.2 Unix.
X
XSYSNOPSIS
X edit init_kuang to reflect attackers initial goals
X sh kuang > tracelog
X
XDESCRIPTION
X Kuang is a rule based system that searches for a path from an
Xinitial set of privileges to a desired set. Given a goal, kuang uses
Xrules to determine a set of subgoals which are sufficient to achieve the
Xinitial goal. The rules are then applied to the subgoals to determine a
Xset of sub-subgoals, etc. This process repeats until there are no new
Xgoals to examine. If a subgoal can be directly achieved using the
Xattacker's initial privileges, then a line is added to the file
X'Success' that describes how the attacker can achieve the top level goal.
X The rules for Unix can be divided into three categories
Xdepending on whether they deal with files, users, or groups. Kuang
Xembodies these rules in three shell scripts, dofiles, douids, and
Xdogids. Goals that have been examined are recorded in the files
Xfiles.p, uids.p, and gids.p. The files files.n, uids.n, and gids.n
Xrecord the goals that will be examined next. The shell script, kuang,
Xapplies the goals in each .n file to the corresponding rule file.
X The initial privileges and ultimate goal are set up in the shell
Xscript, init_kuang. If the program finds a sequence of rules that
Xconnects the initial privileges to the ultimate goal, that sequence will
Xbe recorded in the file Success. Each step in the sequence is recorded
Xas a pair of words. For example, the line "gids users, write
X/usr/bob/.login, trojan baldwin, grant staff, write /etc, replace
X/etc/passwd" means that the password file can be replaced because the
Xgroup staff has write access to the directory /etc, and you can get
Xaccess to the staff group because the .login file for the user bob can
Xbe written by members of the group users, which is one of your initial
Xprivileges.
X
XFILES
X *.n - goals to process in the next round.
X *.x - goals currently being processed.
X *.p - goals that have been examined.
X uids.* - goals related to user IDs.
X gids.* - goals related to group IDs.
X files.* - goals related to files.
X Success - log of holes that are found.
X tracelog - step by step trace of search.
X
XAUTHOR
X Bob Baldwin, MIT Lab for Computer Science, Programming and
XSystems Group.
XE-Mail Address :
X
Xbaldwin@xx.lcs.mit.edu
X...!mit-eddie!baldwin
X
XKuang was inspired by William Gibson's book, Neuromancer, which won the
X1984 Hugo award. In honor of Gibon's book, systems that use rule based
Xsearching to find security holes should be called a kuang-type systems.
X
XBUGS
X Needs to be smarter about command files (e.g., it should look
Xfor writeable files executed via crontab).
X Doesn't include rules for all the programs that run with
Xtheir user id set to root.
SHAR_EOF
chmod 0600 cops/docs/kuang.1 ||
echo 'restore of cops/docs/kuang.1 failed'
Wc_c="`wc -c < 'cops/docs/kuang.1'`"
test 2809 -eq "$Wc_c" ||
echo 'cops/docs/kuang.1: original size 2809, current size' "$Wc_c"
fi
# ============= cops/docs/kuang.man ==============
if test -f 'cops/docs/kuang.man' -a X"$1" != X"-c"; then
echo 'x - skipping cops/docs/kuang.man (File already exists)'
else
echo 'x - extracting cops/docs/kuang.man (Text)'
sed 's/^X//' << 'SHAR_EOF' > 'cops/docs/kuang.man' &&
X.ps 12
X.vs 12
X.PH ````
X.nr W 80
X.in 0
X.ce 3
X\fBKuang: Rule-Based Security Checking\fP
XRobert W. Baldwin
XMIT, Lab for Computer Science Programming Systems Research Group
X
X.PP
XThe security of data in a particular computer depends both on the
Xintegrity of the computer's protection mechanism and on the consistent
Xuses of those mechanisms by the users of that computer. Software
Xverification and specification technology addresses the integrity
Xproblem, but very little has been done to insure that the protection
Xmechanisms are being used consistently. This paper describes a
Xrule-based system that finds inconsistencies in the set of protection
Xdecisions made by the users of an information system.
X
X.PP
X\fBIntroduction\fP
X.PP
XThe trend in commercial computer systems has been to increase the the
Xnumber of mechanisms that allow users to execute commands and to
Xincrease the number of mechanisms that allow users to share
Xinformation. All of these mechanisms must be considered to be part of
Xthe protection system. For example, if users can specify a set of
Xcommands that will be executed automatically every night, then the
Xdatabase that contains these commands, and the program that processes
Xthe database must be considered part of the protection system. Even
Xif the program has been certified to work correctly, the access list
Xfor the command database and the set of privileges available to the
Xprocessing program must be considered to be part of the protection
Xconfiguration \**
X.FS
XThe protection configuration is a subset of the
Xaccess matrix. The access matrix specifies how each user can access
Xeach object. I use the term
X.ul
Xprotection configuration
Xto refer to the portion of the access matrix concerning the objects
Xused by any piece of the protection system.
X.FE
Xof that computer. The problem
Xconsidered in this paper is ensuring that the protection configuration
Xis consistent with the user's security goals.
X.PP
XThe goal of flexible information processing and sharing makes
Xcomputers more useful, but that goal also makes protection systems
Xlarger and more complex. The large number of interactions between the
Xpieces of the protection system makes it hard for the users to make
Xprotection decisions correctly. This is particularly true when parts
Xof an information system are managed by novices (e.g., personal work
Xstations). Users need automated tools for analyzing the interactions
Xbetween the pieces of a large protection system.
X.PP
XThis paper describes a class of systems, called Kuang-type \**
X.FS
XThis
Xproject was inspired by William Gibson's book
X.ul
XNeuromancer
X, which won the 1984 Nebula award for best science fiction novel.
XGibson's book describes innovative ways to visualize the structure of
Xinformation systems. In particular, it describes a program called a
XKuang Grade Mark 11 Ice Breaker (
X.ul
Xice
Xrefers to the mechanisms used
Xto protect access to information). The program described in this memo
Xis a greatly simplified version of that ice breaker program.
X.FE
Xsystems, for analyzing large protection configurations.
XThis class of systems is illustrated by a Simple Unix Kuang program
X(SU-Kuang) that answers a question about a Unix protection
Xconfiguration. The question is "what if an attacker had access to a
Xgiven set of privileges (groups), could that attacker become
Xsuper-user?". SU-Kuang allows a system manager to perform a simple
Xwhat-if analysis of a protection configuration, and in this mode it
Xhelps the manager make protection decisions. A typical use of SU-Kuang
Xis to run it periodically to see if access to the group, World, (i.e.,
Xminimum privileges) is sufficient to become super-user. In this mode
XKuang functions as an automatic security checker. SU-Kuang is just one
Xpossible tool for helping users cope with the complexity of a large
Xprotection system. Some other desirable tools are mentioned at the
Xend of this paper.
X.PP
XThe heart of the SU-Kuang program is a set of rules that describe the
XUnix (BSD4.2) protection system from the point of view of an
Xattacker. For example, one rule says that if an attacker can write
Xthe file /etc/passwd (the authentication database), then that attacker
Xcan become super-user. To decide whether to use this rule, an
Xattacker would examine the protection configuration of the target
Xmachine to see what privileges are required to write the file
X/etc/passwd. Using similar rules, SU-Kuang can answers the what-if
Xquestion by performing a backward chaining search of the protection
Xconfiguration (see figure
X.ul
Xgoal-tree
X). Given a goal, like become
Xsuper-user, SU-Kuang examines all the rules to produce a list of
Xsubgoals that would be sufficient to meet its goal. Recursively, each
Xof the subgoals can be processed to produce a list of sub-subgoals.
XThe process continues until there are no new goals. At each step, if
Xa goal can be achieved using the initial privileges of the attacker,
XSU-Kuang prints out a message that describes the sequence of steps
Xthat leads from the initial goals to the target goal.
X.sp
X.sp
X.nf
X Become Super-User
X / \\
X / \\
X Replace /etc/passwd Write /.rhosts
X / \\ .
X / \\ . .
X Become Staff Write /etc
X . .
X . . . .
X . . . .
X
X
X.fi
X(Example of a goal-tree used by SU-Kuang. The nodes of the tree
Xare goals desired by an attacker.
XThe children of each node are the subgoals that are sufficient to
Xachieve the parent goal. The goal-tree used by SU-Kuang is a pure
XOR-tree. Any one of the subgoals is sufficient to grant the parent goal.)
X
X.PP
XNotice that SU-Kuang does not find holes in the Unix operating system.
XIt finds mistakes in the protection configuration. For example,
XSU-Kuang found a security hole on an MIT machine that resulted from
Xtwo incorrect decisions about who should have write access to start-up
Xcommand files. SU-Kuang points out holes by describing the sequence
Xof steps used to exploit the hole. The sequence SU-Kuang printed was:
X"member MIT, write ~tom/.cshrc, member A_STAFF, write ~dick/.login,
Xmember STAFF, write /etc, replace /etc/passwd, become ROOT". This
Xmeans that the attacker had access to the group MIT, which all users
Xare in. The MIT group had write access to one of the start-up command
Xfiles executed automatically when the user Tom (not his real
Xname) logged in. Anyone in the MIT group could add commands to Tom's
Xstart-up command file, and have these commands executed with Tom's
Xprivileges next time Tom logged into the machine. Tom is a member of
Xthe Athena Staff group, which is not particularly privileged. However,
Xthe A_STAFF group does have write access to one of Dick's start-up
Xcommand files, and Dick is a member of the Staff group, which is one
Xof the most privileged groups. In fact, members of the staff group
Xcan write the directory that contains the password database. Write
Xaccess to the directory allows staff members to delete and recreate
Xthe password database. By creating a password database that has a
Xknown password for the super-user account, members of the staff group
Xcan acquire super-user privileges.
X.PP
XMy experience running SU-Kuang is that these mistakes are created
Xperiodically because the users do not understand the interactions
Xbetween the numerous pieces of the Unix protection system. However,
Xit is not complicated to write a program that can explore all the
Xpossible interactions. SU-Kuang itself is a simple program, and
Xgenerating the rules that describe the pieces of the protection system
Xis also easy (see section
X.ul
Xrules
X). The simplifying idea is to
Xdescribe the protection system in terms of how an attacker can
Xmanipulate it. Using this framework, performing the analysis is easy.
X.PP
XI consider any system that uses attacker-oriented rules to be a
XKuang-type system. The remainder of this paper describes the Unix
XKuang system I built to determine whether a given set of privileges is
Xsufficient to become super-user. The nature of the rules and the
Xprocess used to deduce them is illustrated in section
X.ul
Xrules
X, which lists the set of rules used to model Unix. The model used by
XSU-Kuang was incomplete in several ways, so section
X.ul
Xextensions
Xdescribes some of the features of Unix that were not
Xmodeled. The incomplete model turned out to be very effective at
Xfinding security holes, so section
X.ul
Xexperience
Xpresents the
Xlessons learned from running SU-Kuang on the computers at MIT. The last
Xsection discusses other kinds of Kuang systems and their benefits.
X.PP
X\fBRules to model Unix\fP
X.PP
XThe first step in generating attacker-oriented rules is to determine
Xthe types of goals that are relevant to an attacker of the target
Xsystem. These goal types can be deduced from the basic protection
Xmodel of the operating system, so before presenting the rules, the
XUnix protection model is summarized. The second step is to make a
Xlist of the pieces of the protection system and to examine each one in
Xterms of the goals an attacker could achieve using each piece.
XThe pieces of the Unix protection system that were included in the
Xprototype's model are listed below along with the rules used to
Xdescribe each piece.
X.PP
X\fBSummary of the Unix protection model\fP
X.PP
XThe Unix protection model concerns processes and files. Associated
Xwith each process is one user identifier UID, and one or more group
Xidentifiers (GIDs). The UID and GIDs are generally inherited when one
Xprocess forks another. One exception is that the super-user (UID =
X0) can change the UID and GIDs of his current process. The other
Xexception is that a user can associate a UID and GID with a program
Xstored in the file system. When anyone runs such a program, the
Xprocess executing that program will run with the stored user and/or
Xgroup IDs.
X.PP
XAssociated with each file is one UID, one GID, and nine permission
Xbits. The nine permission bits are divided into three groups to
Xspecify the read, write, and execute rights for the file's owner
X(specified by the UID), for the members of the file's group (specified
Xby the GID), and for all others (the World group). Directories are a
Xspecial case of files. For a directory, read permission allows a
Xprocess to list a directory, write permission allows a process to
Xcreate or delete files in that directory, and execute permission
Xallows a process to resolve names in that directory even if the
Xdirectory is unreadable.
X.PP
XWhen a process accesses a file or directory it is given either owner,
Xgroup, or world access permissions, but only one of those three.
XOwner access is granted if the process and file UIDs match; Group
Xaccess is granted if the process and file UIDs are different but the
Xfile's GID is in the list of GIDs for the process; otherwise, World
Xaccess is granted. The super-user has full access to all files and
Xdirectories. Only the owner or the super-user can change the access
Xpermissions of a file.
X.PP
X\fBThree types of attacker goals\fP
X.PP
XThe Unix protection model deals with users, groups, and files, so
Xthose are the three types of goals that will concern an attacker. The
Xcanonical user goal is "execute one of the attacker's programs with a
Xparticular UID". For example, the top level goal is "execute a
Xprogram chosen by the attacker under UID zero (i.e., as
Xsuper-user)". It is important that the attacker be able to specify
Xthe program to be executed with super-user privileges. The login
Xprogram runs as super-user, and anyone can run it. The attacker wants
Xto specify the computation performed with super-user privileges. One
Xscheme for getting access to super-user privileges is to write the
Xcommand file that is executed automatically when the super-user logs
Xin.
X.PP
XGroup ID goals are similar. The canonical form of a GID goal is
X"execute an arbitrary program with a particular group ID". One
Xpossible way to achieve this goal is to add the attacker's UID to the
Xlist of users allowed to access the desired group. This authorization
Xdatabase is stored in the file /etc/group.
X.PP
XThe canonical file goal is "obtain read/write/replace access to a particular
Xfile". Achieving a file goal usually involves getting access to a
Xparticular group or user ID. However, if the attacker wants to replace
Xa file, one way to do that is to delete the old file and create a new
Xone. That can be done if the attacker has write or replace access to
Xthe directory that contains the target file.
X.PP
XIn summary, SU-Kuang considers three types of goals for an attacker of
XUnix: user, group, and file. Each type of goal can lead to subgoals
Xof the same or different type.
X.PP
X\fBSome pieces of the Unix protection system\fP
X.PP
XThis section presents the rules that describe many of the pieces of the
XUnix protection system. Section
X.ul
Xextensions
Xdescribes the
Xsignificant pieces that were left out of the prototype's model. The
Xpieces of the Unix protection system include all programs, like
X.ul
Xlogin,
Xthat have the set user/group ID property. It also includes programs
Xlike
X.ul
Xcron
X(cron executes commands in the future) that
Xare forked off by processes that run with special user or group IDs.
XFinally, programs like
X.ul
Xsh
X(a command interpreter) must be included
Xin the protection system because when they are started they execute
Xcommands from a file using the privileges of the user invoking them.
X.PP
XEach rule describes how a piece of the protection system can be
Xused by an attacker to achieve a desired goal in terms of the ability
Xto achieve a subgoal. The method used to achieveat goal given the
Xsubgoal may require that some condition be true. For that reason the
Xrules include a condition that can be tested to decide if the subgoal
Xshould be pursued. The conditions are general predicates on the state
Xof the protection configuration. For example, the rule that says that
Xan attacker can become the super-user by writing the password file,
Xhas the condition that the password file is writable by someone other
Xthan the super-user.
X.PP
XIn the rules listed below, the notation \*Q/d/f\*U means a
Xpathname for the file \*Qf\*U in the directory with pathname \*Q/d\*U.
XThe goal, \*Qbecome U\*U, means to execute an arbitrary command under the
Xuser ID \*QU\*U. The goal, \*Qmember G\*U, means the same thing for
Xgroup \*QG\*U. The goal, \*Qwrite /d/f\*U, means being able to write the
Xfile \*Q/d/f\*U. Finally, \*Qreplace /d/f\*U, means being able to write
X\*Q/d/f\*U or being able to delete \*Q/d/f\*U and recreate it.
X.PP
X\fBThe file system\fP
X.PP
XMost programs in the protection system use the file hierarchy to
Xlocate their databases. If the file hierarchy can be modified, then
Xthe protection system can be tricked into using the wrong database
Xfiles. The file hierarchy itself must be treated as one of the
Xmain databases in the protection configuration.
X.PP
XThe notation \*QOwner(/d/f)\*U refers to the UID associated with the
Xfile \*Q/d/f\*U. Similarly \*QGroup(/d/f)\*U refers to the file's GID.
XThe expression \*QGroupWrite(/d/f)\*U is true if the file \*Q/d/f\*U can
Xbe written by the members of \*QGroup(/d/f)\*U. The expression
X\*QWorldWrite(/d/f)\*U is true if the file can be written by members of
Xthe World group (i.e., all users).
X.sp
XRules{
X.sp
X.ul
X<Goal/Condition/Subgoal/Note>
X.PP
XReplace /d/f Write /d/f
X.PP
XReplace /d/f Replace /d\**
X.FS
XThe condition stops the
Xrecursion at the root directory of the file system.
X.FE
X.PP
XWrite /d/f Become Owner(/d/f)\**
X.FS
XThe owner of a file can
Xalways change the access permissions to allow owner write access.
X.FE
X.PP
XWrite /d/f GroupWrite(/d/f) Member Group(/d/f)
X.PP
XWrite /d/f WorldWrite(/d/f) Member World\**
X.FS
XThis subgoal is
Xis achievable by all users provided they can get to the file. The
Xnotable exceptions are users logged in via anonymous ftp or uucp
Xconnections. These users have restricted access to the file
Xhierarchy.
X.FE
X.sp
X}
X.PP
X\fBlogin\fP
X.PP
XThe login program uses two database to set the UID and GIDs of the
Xuser's command interpreter. The contents of
Xthese databases and the protection of the databases themselves
Xmust be considered part of the protection configuration.
X.PP
XThe user name \*Qroot\*U refers to the super-user. The label, \*QU\*U, stands
Xfor an arbitrary UID including \*Qroot\*U. The label, \*QG\*U, stands for
Xan arbitrary GID. The expression \*QUIDS(G)\*U expands to all the
XUIDs authorized to use the group \*QG\*U according to the files
X/etc/group or /etc/passwd.
X
X.sp
XRules{
X.sp
X.ul
X<Goal/Condition/Subgoal/Note>
X
XBecome U Replace /etc/passwd\**
X.FS
XThis rule matches the goal \*QBecome root\*U.
X.FE
X
XMember G Replace /etc/group
X
XMember G Become UIDS(G)\**
X.FS
XThe subgoal means to try to become any member of the group \*QG\*U.
X.FE
X.sp
X}
X.PP
X\fBrsh, rlogin, rcp\fP
X.PP
XBerkeley Unix includes several remote execution commands that greatly
Ximprove the usability of multiple Unix hosts connected by a network.
XThe underlying authentication protocol does not resist an attacker
Xthat can transmit arbitrary messages on the network, but even if that
Xproblem was fixed, the databases used by these programs would have to
Xbe considered as part of the protection system.
X.PP
XThe file /etc/hosts.equiv lists the names of the hosts that are
Xtrusted by the target machine's administrators. If a user has an
Xaccount on the target machine, and on one of the trusted hosts, then
Xthat user can log into the target machine from the trusted machine
Xwithout supplying a password. Users can list additional hosts (or
Xother users) that they trust in a file (.rhosts) in their home
Xdirectory.
X.PP
XThe expression \*QNotEmpty(/d/f)\*U is true if the file /d/f exists and
Xit is not empty. The label, \*Q~U\*U, refers to the home directory of user
X\*QU\*U.
X.sp
XRules{
X.sp
X.ul
X<Goal/Condition/Subgoal/Note>
X.PP
XBecome U (~U/.rhosts) /etc/hosts\**
X.FS
XIf there is
Xa host listed in the user's remote access database and the host name
Xtable is replaceable, then an attacker can make his host appear to be
Xthe host listed in the user's database. This assumes that the
Xattacker has super-user privileges on some host that can talk to the
Xtarget host, because the attacker will need to create an account with
Xthe target's user name. This attack will become obsolete when hosts
Xstart using a distributed name server rather than a fix hostname
Xdatabase. However, the name server will open other avenues of attack.
X.FE
X.PP
XBecome U Write ~U/.rhosts\**
X.FS
XThe remote execution routines insist that the target user be the owner
Xof the database file, so replace access is not sufficient to use this
Xattack.
X.FE
X.PP
XBecome U root Replace /etc/hosts.equiv\**
X.FS
XRemote execution with super-user privileges is only accepted from
Xthe hosts listed in ~root/.rhosts, so replacing the hosts.equiv file
Xcannot be used to directly gain access to super-user privileges.
X.FE
X.sp
X}
X.PP
X\fBshells\fP
X.PP
XSeveral command interpreters, called shells, have been written for
XUnix. Different users can use different shells, but all shell have
Xsome mechanism for executing a list of commands when a user logs in.
XThe files that specify these initialization commands are a part of the
Xprotection configuration that each user can change.
X.PP
XThe expression \*QExists(/d/f)\*U is true if the file /d/f exists.
X.sp
XRules{
X.sp
X.ul
X<Goal/Condition/Subgoal/Note>
X.PP
XBecome U Exists(~U/.login) Replace ~U/.login\**
X.FS
XThis file contains the commands read when a user logs in.
XThe conditional should really test to see if the user is actually using
Xthe /bin/csh command interpreter. If csh is being used, then
Xthis rule will work even if the file .login doesn't exist, so
Xthe conditional is overly strict.
X.FE
X.PP
XBecome U Exists(~U/.cshrc) Replace ~U/.cshrc\**
X.FS
XThis file is read each time a /bin/csh is executed such as at login
Xand when a command file is executed. The conditional is also overly
Xstrict.
X.FE
X.PP
XBecome U Exists(~U/.profile) Write ~U/.profile\**
X.FS
XSame trick for the /bin/sh command interpreter.
X.FE
X.sp
X}
X.PP
X\fBcron\fP
X.PP
XCron is a program that is forked off when a Unix system is booted.
XThis means that it runs with super-user privileges. Cron reads a
Xdatabase (/usr/lib/crontab) that describes the commands that should be
Xexecuted periodically. By default these commands are executed with
X\*Qroot\*U privileges.
X.sp
XRules{
X.sp
X.ul
X<Goal/Condition/Subgoal/Note>
X
XBecome root none Replace /usr/lib/crontab
X.sp
X}
X.PP
X\fBsendmail\fP
X.PP
XThe Unix mail system has many features that allow flexible forms of
Xinformation sharing. The most interesting feature (to system builders
Xand to attackers) is that receiving mail can trigger the invocation of
Xa program which is passed the mail message as its input. The file
X/usr/lib/aliases specifies the human readable form of a binary
Xdatabase that describes mailing lists, mail forwarding, and programs
Xto invoke when mail is received by certain mailboxes. Being able to
Xmodify this database allows an attacker to get access to other
Xpeople's user and group IDs because the mail sending program runs with
Xthe privileges of the user who invokes it. If the destination of the
Xmessage is on the same host as the source, then the receiving program
X(also sendmail) will run with the invoker's privileges. If the source
Xof the message is on another computer, then sendmail will run under
Xthe UID \*Qdaemon\*U.
X.sp
XRules{
X.sp
X.ul
X<Goal/Condition/Subgoal/Note>
X.PP
XBecome daemon none Replace /usr/lib/aliases\**
X.FS
XThis assumes
Xthat the command to build the binary database can be executed by
Xeveryone, or that it is executed automatically when the mailer detects
Xthat the binary database is out of date. There should also be rules
Xto see if the binary database can be written directly.
X.FE
X.PP
XBecome root none Replace /usr/lib/aliases\**
X.FS
XAssumes that
X\*Qroot\*U sends mail to some user on this machine. Such users can be
Xfound by scanning the mail logs, which are usually World readable. If
Xsuch a user exists, the aliases database can be set up to tell sendmail to
Xdeliver mail to the recipient and invoke the attacker's program. Next
Xtime root sends mail to that user, the attacker's program will be
Xinvoked with root privileges. The program would test to see if it was
Xrunning with \*Qroot\*U privileges, and if so plant a trap door such as
Xmaking /.rhosts publicly writable.
X.FE
X.sp
X}
X.PP
X\fBboot\fP
X.PP
XWhen a Unix reboots, it executes the commands in the file /etc/rc.
XThis file usually executes the commands in the file /etc/rc.local.
X.sp
XRules{
X.sp
X.ul
X<Goal/Condition/Subgoal/Note>
X
XBecome root Exists(/etc/rc) Replace /etc/rc
X
XBecome root Exists(/etc/rc.local) Replace /etc/rc.local
X}
X.PP
X\fBExtensions to the Unix model\fP
X(extensions)
X.PP
XThis section lists some of the important pieces of the Unix protection
Xsystem that were left out of the SU-Kuang's model. Most of these
Xpieces could be added easily.
X.PP
XThe major deficiency of the model is that it does not include all of the
Xprograms that run with super-user privileges. Each of these
Xprograms must be modeled if there is some way that an attacker could
Xuse the programs' databases to get access to root privileges.
X.PP
XLocating all the programs that run with super-user privileges is not
Xeasy. Many ordinary programs are executed inside of command files
Xthat are run with root privileges. This points out another
Xshortcoming of SU-Kuang. It does not look inside of command files.
XFor example, on system restart, Unix executes the commands in the file
X/etc/rc with super-user privileges. That file executes additional
Xcommands in the file /rc.local, so those commands also runs as root.
XThe prototype has an explicit rule that covers this case, whereas it
Xshould deduce this and other cases by parsing the commands in /etc/rc.
X.PP
XThe prototype does not understand search paths. On Unix, as with most
Xsystems, users do not specify the full pathname of the programs they
Xwant to execute. Instead, users specify a sequence of directories
Xthat should be searched to find the program. Often users tell their
Xcommand interpreter to first look in a private directory of commands,
Xand quite often that directory is writable by any member of the user's
Xprimary group. If an attacker can write a user's private command
Xdirectory, then the attacker can plant a trojan horse on that user.
XFor example, the user may want to execute /usr/local/gnuemacs, but the
Xuser may end up executing the attacker's program in
X/usr/smith/@_bin/gnuemacs. To model this attack, SU-Kuang would need to
Xbe able to read each user's startup command file to determine each
Xuser's search path.
X.PP
XThe file goals considered by the model only include write and replace
Xaccess to a file. Read access is not considered. To include read
Xaccess, each piece of the protection system must be re-examined to see
Xif it could provide read access to an arbitrary file. For example,
Xthe Unix finger program, which displays information about users, runs
Xwith super-user privileges so it can read an information file (.plan)
Xin the specified user's home directory. Unfortunately, some
Ximplementations of the finger program allow the .plan file to be a
Xsymbolic link to another file, and thus the finger program allows read
Xaccess to any file on the system.
X.PP
XThe rules that model the file system do not include the fact that the
Xdisks can be accessed via the raw device files. Reading and writing
Xthe device files can be used to read and write arbitrary blocks on the
Xdisks. These files should only be accessible to the super-user, but
Xoften anyone can read them. If so, an attacker can read any file on
Xthe disk.
X.PP
XA different kind of deficiency in the model is that it does not allow
Xthe attacker to guess at passwords. On a system that allows users to
Xpick their own passwords, an attacker can usually guess a few of the
Xpasswords. Assuming that an attacker can read the password file,
X\**
X.FS
XProtecting the password file from users logged in on a guest
Xaccount or using anonymous file transfer is a good idea. However,
Xprotecting it from ordinary users is hard. Many programs need read
Xaccess to the non-password information kept in that file, and making
Xall those programs run with special privileges may create more
Xproblems than it solves.
X.FE
Xthe attacker can test passwords at the rate of about ten per second.\**
X.FS
XThere are lots of tricks that speed up the execution of
Xthe Unix salted DES function on a 32 bit machine.
X.FE
XA 2000 word dictionary of common passwords can be processed at the
Xrate of a few minutes per account.
X.PP
XAs in any kind of modeling, the better the model, the better the
Xresults. Fortunately, in the case of Unix, making the model more
Xdetailed does not require using a more complicated framework. The
Xrule-based framework of SU-Kuang is flexible enough to model all the
Xfeatures described in this section.
X.PP
X\fBPrototype Implementation\fP
X(implementation)
X.PP
XThe SU-Kuang program described in this paper is easy to
Ximplement. The primary inputs to the program are a list of groups
X(privileges) accessible to the attacker (including the special group
X\*QWorld\*U), and the target goal (usually \*Qbecome root\*U). The
Xprogram examines the protection configuration of the machine it is
Xrunning on, so this can be considered a secondary input. The
Xprimary output is a list of the ways that an attacker can achieve the
Xtarget goal from the initial privileges. Internally, the program
Xbuilds a goal-tree based on a set of rules that are compiled into the
Xprogram. When a node of the goal-tree can be directly achieved using
Xthe initial privileges, the program prints out the sequence of steps
Xthat describe the path from the given node of the goal-tree to the
Xroot of the goal-tree.
X.PP
XIn classic Unix style, the prototype was initially implemented by a
Xset of shell scripts (command files). Later, to improve performance,
Xsome of the shell scripts were re-written in C. The top level
Xshell script keeps track of the goal-tree, and invokes other shell
Xscripts to generate successive levels of the goal-tree. For each of the
Xthree kinds of goals (user, group, and file), there is a shell script
Xthat reads a list of goals of that kind and produces a list of
Xsubgoals.
X.PP
XAssociated with each node of the goal-tree is a human readable comment
Xthat describes the path from each node to the root of the goal-tree.
XThis comment is appended to a list of 'successes' if the
Xassociated goal can be directly achieved using the initial privileges
Xof the attacker. Since each comment specifies the sequence of steps
Xan attacker could use to achieve the target goal given the current
Xgoal, it is easy to derive the comments for subgoals from the comments
Xof parent goals. The subgoal comments is the parent goal's comment
Xplus an indication of which rule was used to derive the subgoal.
X.PP
XThe basic data abstraction used by SU-Kuang is a goal-table. There
Xare three goal-tables, one for each type of goal. The operations on a
Xgoal table are:
X.ul
Xnew,
X.ul
Xaddto, and
X.ul
Xnext. The
X.ul
Xnew
Xoperation creates an empty goal table. It takes a set of initial
Xgoals that are directly achievable by the attacker. The
X.ul
Xaddto
Xoperation adds a goal and a comment to the table. If the goal is
Xalready in the table, the table is not changed. If the goal is in the
Xset of directly achievable goals, then
X.ul
Xaddto also appends the
Xcomment to the file that contains a list of successes. The operation,
X.ul
Xnext, examines a goal-table and returns any goal-comment pair that
Xit has not already returned. The
X.ul
Xaddto
Xoperation is effectively
Xthe inner loop of a rule interpreter.
X.PP
XThe goal-table abstraction is implemented by four files. One file
Xkeeps track of all of the goals in the table and it is used to avoid
Xduplicate goals. Another file holds the list of goals initially
Xavailable to the attacker. Two files are used to support the next
Xoperation. One file records all the goal-comment pairs that have been
Xreturned by the next operations, the other file lists the goal-comment
Xpairs that have been added to the table but not yet selected by the
Xnext operation.
X.PP
XUsing the goal-table abstraction it is easy to express rules as lines
Xof a shell script. Figure
X.ul
Xshell
Xrule shows a rule and its shell
Xscript implementation. The conditional part of the rules are
Xexpressed by shell script conditionals (e.g., \*Q-z\*U means that a file
Xexists and has a length of zero, \*Q!\*U and \*Q&&\*U mean logical
Xnegation and conjunction).
X.sp
XRules{
X.sp
X.ul
X<Goal/Condition/Subgoal>
X
XBecome root NotEmpty(/.rhosts) Replace /etc/hosts
X.sp
X}
X
X.nf
X# $User and $OldComment are set by the goal-table next operation.
X# $FileGoals refers to the goal-table object for file type goals.
Xif (($User == "root") && (! -z /.rhosts)) then
X set NewComment="Fake HostAddress, $OldComment"
X set SubGoal="Replace /etc/hosts"
X addto $FileGoals $SubGoal $NewComment
Xendif
X.fi
XSample rule and corresponding shell script line.
X
X.PP
XThe implementation of SU-Kuang is straight forward. The only reason
Xfor describing it in this paper is to demonstrate how easy it is to
Xprocess the attacker-oriented rules that describe a protection system.
X.PP
X\fBExperience\fP
X(experience)
X.PP
XThe SU-Kuang system has been run on a large number of
Xsites managed by personnel with a wide range of skills and interests
Xin security. It has almost always found a hole. A Kuang that
Xincorporates the extensions described in section
X.ul
Xextensions
Xwould find more holes.
X.PP
XI believe that holes are created because users do not understand how
Xthe various pieces of the protection system interact. The main
Xevidence for this is that fact that most holes are found in the
Xprotection databases that are maintained by ordinary users (e.g.,
X.login and .rhosts). Also, users who have recently been given special
Xprivileges tend to create holes that allow anyone to achieve
Xsuper-user privileges. When I tell users about the problems SU-Kuang
Xfinds, they often do not understand what was wrong with the decision
Xthey made.
X.PP
XUsers create security holes periodically. When I ran SU-Kuang
Xperiodically on one computer that had a large complicated protection
Xconfiguration (e.g., the authorization databases included 300 users
Xand 25 groups), SU-Kuang found new holes every week or two. Often
Xthese new holes were created when someone modified a security
Xdatabase. One common procedure for modifying a database is to first
Xrename the original, then copy of the original into a file with the
Xproper name, and finally edit the copy. The motivation for the first
Xrename step is to preserve the timestamp that indicates when the
Xdatabase was last written. Unfortunately, the file copy step does not
Xcopy the protection information from the original database. The
Xprotection for the copy is determined by the defaults for the
Xcurrently running process. It is not determined by the original. The
Xfile UID is set to the UID of the process that performs the copy,
Xand the GID is set to the GID of the directory that contains
Xthe file. The permission bits are set to a default value specified in
Xthe copier's login command file.
X.PP
XThe holes found by SU-Kuang point out that it is hard to set up multiple
Xseparate security groups under BSD4.2 Unix. For example, a group
Xthat allows its members to install programs in the /etc directory,
Xalso allows its members to replace the authentication database in
X/etc/passwd. The fact that users run with their full privileges (i.e.,
Xthey can access multiple groups in the same process), makes Berkeley
XUnix easier to use than other versions of Unix that force users to
Xaccess one group at a time. However, that same feature makes it
Xeasier for an attacker to plant a trojan horse on a user that is a
Xmember of a lower privilege group (e.g., the implementors of some
Xproject) and a member of a high privilege group (e.g., staff).
X.PP
XThe impression I have gotten from running SU-Kuang is that most of the
Xfeatures that make Unix easy to use also make Unix hard to secure.
XHowever, SU-Kuang does make it easier to build a secure protection
Xconfiguration for Unix.
X
X.PP
X\fBDiscussion\fP
X(conclusions)
X.PP
XTo increase the usefulness of computers, systems designers have
Xprovided an increasing number of mechanisms that allow users to
Xexecute commands and share information. Since these new mechanisms
Xmust be considered part of the protection system, this trend has made
Xprotection systems larger and progressively harder to understand. As
Xa protection system becomes more complex, it becomes unlikely that
Xall the protection decisions are made correctly, and these mistakes
Xcan ruin the overall security of the information and resources
Xcontrolled by computers. The commercial environment presents a
Xspecial problem because usability is the primary goal of commercial
Xinformation systems, but security cannot be neglected. There needs to
Xbe some way to manage the complexity of the protection systems that arise
Xon information systems that stress usability.
X.PP
XThis paper presents one approach for achieving both usability and
Xsecurity. The idea is to use rule-based systems to analyze the
Xinteractions between all the decisions that make up a computer's
Xprotection configuration. If analyzing a protection configuration is
Xeasy, then the manager of a system can ensure that the system meets
Xthe security objectives of its users. A program that performs a
Xsimple analysis of a Unix protection configuration was presented to
Xillustrate that this sort of rule-based system is easy to build if
Xthe protection system is described from the attacker's viewpoint.
XThis simple Unix analysis system, called SU-Kuang, answered the
Xquestion "given access to a particular set of privileges,
Xcan an attacker achieve super-user privileges?". Using SU-Kuang,
Xa security manager could ensure that a system did not allow ordinary
Xuser to achieve super-user privileges.
X.PP
XSU-Kuang is just one of many helpful Kuang-type systems. For example,
Xmany security objectives are expressed in terms of limiting the set of
Xpeople who have access to particular privileges. A Kuang-type system
Xthat computed the set of privileges accessible to each user would help
Xa security manager determine whether the security objectives are being
Xmet. Even better, if the bulk of the security objectives can be
Xexpressed in computer understandable form, then the bulk of the work
Xof checking computer security could be automated.
X
SHAR_EOF
chmod 0600 cops/docs/kuang.man ||
echo 'restore of cops/docs/kuang.man failed'
Wc_c="`wc -c < 'cops/docs/kuang.man'`"
test 36594 -eq "$Wc_c" ||
echo 'cops/docs/kuang.man: original size 36594, current size' "$Wc_c"
fi
true || echo 'restore of cops/docs/rc.chk failed'
echo End of part 6, continue with part 7
exit 0