1.ps 12 2.vs 12 3.PH ```` 4.nr W 80 5.in 0 6.ce 3 7\fBKuang: Rule-Based Security Checking\fP 8Robert W. Baldwin 9MIT, Lab for Computer Science Programming Systems Research Group 10 11.PP 12The security of data in a particular computer depends both on the 13integrity of the computer's protection mechanism and on the consistent 14uses of those mechanisms by the users of that computer. Software 15verification and specification technology addresses the integrity 16problem, but very little has been done to insure that the protection 17mechanisms are being used consistently. This paper describes a 18rule-based system that finds inconsistencies in the set of protection 19decisions made by the users of an information system. 20 21.PP 22\fBIntroduction\fP 23.PP 24The trend in commercial computer systems has been to increase the the 25number of mechanisms that allow users to execute commands and to 26increase the number of mechanisms that allow users to share 27information. All of these mechanisms must be considered to be part of 28the protection system. For example, if users can specify a set of 29commands that will be executed automatically every night, then the 30database that contains these commands, and the program that processes 31the database must be considered part of the protection system. Even 32if the program has been certified to work correctly, the access list 33for the command database and the set of privileges available to the 34processing program must be considered to be part of the protection 35configuration \** 36.FS 37The protection configuration is a subset of the 38access matrix. The access matrix specifies how each user can access 39each object. I use the term 40.ul 41protection configuration 42to refer to the portion of the access matrix concerning the objects 43used by any piece of the protection system. 44.FE 45of that computer. The problem 46considered in this paper is ensuring that the protection configuration 47is consistent with the user's security goals. 48.PP 49The goal of flexible information processing and sharing makes 50computers more useful, but that goal also makes protection systems 51larger and more complex. The large number of interactions between the 52pieces of the protection system makes it hard for the users to make 53protection decisions correctly. This is particularly true when parts 54of an information system are managed by novices (e.g., personal work 55stations). Users need automated tools for analyzing the interactions 56between the pieces of a large protection system. 57.PP 58This paper describes a class of systems, called Kuang-type \** 59.FS 60This 61project was inspired by William Gibson's book 62.ul 63Neuromancer 64, which won the 1984 Nebula award for best science fiction novel. 65Gibson's book describes innovative ways to visualize the structure of 66information systems. In particular, it describes a program called a 67Kuang Grade Mark 11 Ice Breaker ( 68.ul 69ice 70refers to the mechanisms used 71to protect access to information). The program described in this memo 72is a greatly simplified version of that ice breaker program. 73.FE 74systems, for analyzing large protection configurations. 75This class of systems is illustrated by a Simple Unix Kuang program 76(SU-Kuang) that answers a question about a Unix protection 77configuration. The question is "what if an attacker had access to a 78given set of privileges (groups), could that attacker become 79super-user?". SU-Kuang allows a system manager to perform a simple 80what-if analysis of a protection configuration, and in this mode it 81helps the manager make protection decisions. A typical use of SU-Kuang 82is to run it periodically to see if access to the group, World, (i.e., 83minimum privileges) is sufficient to become super-user. In this mode 84Kuang functions as an automatic security checker. SU-Kuang is just one 85possible tool for helping users cope with the complexity of a large 86protection system. Some other desirable tools are mentioned at the 87end of this paper. 88.PP 89The heart of the SU-Kuang program is a set of rules that describe the 90Unix (BSD4.2) protection system from the point of view of an 91attacker. For example, one rule says that if an attacker can write 92the file /etc/passwd (the authentication database), then that attacker 93can become super-user. To decide whether to use this rule, an 94attacker would examine the protection configuration of the target 95machine to see what privileges are required to write the file 96/etc/passwd. Using similar rules, SU-Kuang can answers the what-if 97question by performing a backward chaining search of the protection 98configuration (see figure 99.ul 100goal-tree 101). Given a goal, like become 102super-user, SU-Kuang examines all the rules to produce a list of 103subgoals that would be sufficient to meet its goal. Recursively, each 104of the subgoals can be processed to produce a list of sub-subgoals. 105The process continues until there are no new goals. At each step, if 106a goal can be achieved using the initial privileges of the attacker, 107SU-Kuang prints out a message that describes the sequence of steps 108that leads from the initial goals to the target goal. 109.sp 110.sp 111.nf 112 Become Super-User 113 / \\ 114 / \\ 115 Replace /etc/passwd Write /.rhosts 116 / \\ . 117 / \\ . . 118 Become Staff Write /etc 119 . . 120 . . . . 121 . . . . 122 123 124.fi 125(Example of a goal-tree used by SU-Kuang. The nodes of the tree 126are goals desired by an attacker. 127The children of each node are the subgoals that are sufficient to 128achieve the parent goal. The goal-tree used by SU-Kuang is a pure 129OR-tree. Any one of the subgoals is sufficient to grant the parent goal.) 130 131.PP 132Notice that SU-Kuang does not find holes in the Unix operating system. 133It finds mistakes in the protection configuration. For example, 134SU-Kuang found a security hole on an MIT machine that resulted from 135two incorrect decisions about who should have write access to start-up 136command files. SU-Kuang points out holes by describing the sequence 137of steps used to exploit the hole. The sequence SU-Kuang printed was: 138"member MIT, write ~tom/.cshrc, member A_STAFF, write ~dick/.login, 139member STAFF, write /etc, replace /etc/passwd, become ROOT". This 140means that the attacker had access to the group MIT, which all users 141are in. The MIT group had write access to one of the start-up command 142files executed automatically when the user Tom (not his real 143name) logged in. Anyone in the MIT group could add commands to Tom's 144start-up command file, and have these commands executed with Tom's 145privileges next time Tom logged into the machine. Tom is a member of 146the Athena Staff group, which is not particularly privileged. However, 147the A_STAFF group does have write access to one of Dick's start-up 148command files, and Dick is a member of the Staff group, which is one 149of the most privileged groups. In fact, members of the staff group 150can write the directory that contains the password database. Write 151access to the directory allows staff members to delete and recreate 152the password database. By creating a password database that has a 153known password for the super-user account, members of the staff group 154can acquire super-user privileges. 155.PP 156My experience running SU-Kuang is that these mistakes are created 157periodically because the users do not understand the interactions 158between the numerous pieces of the Unix protection system. However, 159it is not complicated to write a program that can explore all the 160possible interactions. SU-Kuang itself is a simple program, and 161generating the rules that describe the pieces of the protection system 162is also easy (see section 163.ul 164rules 165). The simplifying idea is to 166describe the protection system in terms of how an attacker can 167manipulate it. Using this framework, performing the analysis is easy. 168.PP 169I consider any system that uses attacker-oriented rules to be a 170Kuang-type system. The remainder of this paper describes the Unix 171Kuang system I built to determine whether a given set of privileges is 172sufficient to become super-user. The nature of the rules and the 173process used to deduce them is illustrated in section 174.ul 175rules 176, which lists the set of rules used to model Unix. The model used by 177SU-Kuang was incomplete in several ways, so section 178.ul 179extensions 180describes some of the features of Unix that were not 181modeled. The incomplete model turned out to be very effective at 182finding security holes, so section 183.ul 184experience 185presents the 186lessons learned from running SU-Kuang on the computers at MIT. The last 187section discusses other kinds of Kuang systems and their benefits. 188.PP 189\fBRules to model Unix\fP 190.PP 191The first step in generating attacker-oriented rules is to determine 192the types of goals that are relevant to an attacker of the target 193system. These goal types can be deduced from the basic protection 194model of the operating system, so before presenting the rules, the 195Unix protection model is summarized. The second step is to make a 196list of the pieces of the protection system and to examine each one in 197terms of the goals an attacker could achieve using each piece. 198The pieces of the Unix protection system that were included in the 199prototype's model are listed below along with the rules used to 200describe each piece. 201.PP 202\fBSummary of the Unix protection model\fP 203.PP 204The Unix protection model concerns processes and files. Associated 205with each process is one user identifier UID, and one or more group 206identifiers (GIDs). The UID and GIDs are generally inherited when one 207process forks another. One exception is that the super-user (UID = 2080) can change the UID and GIDs of his current process. The other 209exception is that a user can associate a UID and GID with a program 210stored in the file system. When anyone runs such a program, the 211process executing that program will run with the stored user and/or 212group IDs. 213.PP 214Associated with each file is one UID, one GID, and nine permission 215bits. The nine permission bits are divided into three groups to 216specify the read, write, and execute rights for the file's owner 217(specified by the UID), for the members of the file's group (specified 218by the GID), and for all others (the World group). Directories are a 219special case of files. For a directory, read permission allows a 220process to list a directory, write permission allows a process to 221create or delete files in that directory, and execute permission 222allows a process to resolve names in that directory even if the 223directory is unreadable. 224.PP 225When a process accesses a file or directory it is given either owner, 226group, or world access permissions, but only one of those three. 227Owner access is granted if the process and file UIDs match; Group 228access is granted if the process and file UIDs are different but the 229file's GID is in the list of GIDs for the process; otherwise, World 230access is granted. The super-user has full access to all files and 231directories. Only the owner or the super-user can change the access 232permissions of a file. 233.PP 234\fBThree types of attacker goals\fP 235.PP 236The Unix protection model deals with users, groups, and files, so 237those are the three types of goals that will concern an attacker. The 238canonical user goal is "execute one of the attacker's programs with a 239particular UID". For example, the top level goal is "execute a 240program chosen by the attacker under UID zero (i.e., as 241super-user)". It is important that the attacker be able to specify 242the program to be executed with super-user privileges. The login 243program runs as super-user, and anyone can run it. The attacker wants 244to specify the computation performed with super-user privileges. One 245scheme for getting access to super-user privileges is to write the 246command file that is executed automatically when the super-user logs 247in. 248.PP 249Group ID goals are similar. The canonical form of a GID goal is 250"execute an arbitrary program with a particular group ID". One 251possible way to achieve this goal is to add the attacker's UID to the 252list of users allowed to access the desired group. This authorization 253database is stored in the file /etc/group. 254.PP 255The canonical file goal is "obtain read/write/replace access to a particular 256file". Achieving a file goal usually involves getting access to a 257particular group or user ID. However, if the attacker wants to replace 258a file, one way to do that is to delete the old file and create a new 259one. That can be done if the attacker has write or replace access to 260the directory that contains the target file. 261.PP 262In summary, SU-Kuang considers three types of goals for an attacker of 263Unix: user, group, and file. Each type of goal can lead to subgoals 264of the same or different type. 265.PP 266\fBSome pieces of the Unix protection system\fP 267.PP 268This section presents the rules that describe many of the pieces of the 269Unix protection system. Section 270.ul 271extensions 272describes the 273significant pieces that were left out of the prototype's model. The 274pieces of the Unix protection system include all programs, like 275.ul 276login, 277that have the set user/group ID property. It also includes programs 278like 279.ul 280cron 281(cron executes commands in the future) that 282are forked off by processes that run with special user or group IDs. 283Finally, programs like 284.ul 285sh 286(a command interpreter) must be included 287in the protection system because when they are started they execute 288commands from a file using the privileges of the user invoking them. 289.PP 290Each rule describes how a piece of the protection system can be 291used by an attacker to achieve a desired goal in terms of the ability 292to achieve a subgoal. The method used to achieve a goal given the 293subgoal may require that some condition be true. For that reason the 294rules include a condition that can be tested to decide if the subgoal 295should be pursued. The conditions are general predicates on the state 296of the protection configuration. For example, the rule that says that 297an attacker can become the super-user by writing the password file, 298has the condition that the password file is writable by someone other 299than the super-user. 300.PP 301In the rules listed below, the notation \*Q/d/f\*U means a 302pathname for the file \*Qf\*U in the directory with pathname \*Q/d\*U. 303The goal, \*Qbecome U\*U, means to execute an arbitrary command under the 304user ID \*QU\*U. The goal, \*Qmember G\*U, means the same thing for 305group \*QG\*U. The goal, \*Qwrite /d/f\*U, means being able to write the 306file \*Q/d/f\*U. Finally, \*Qreplace /d/f\*U, means being able to write 307\*Q/d/f\*U or being able to delete \*Q/d/f\*U and recreate it. 308.PP 309\fBThe file system\fP 310.PP 311Most programs in the protection system use the file hierarchy to 312locate their databases. If the file hierarchy can be modified, then 313the protection system can be tricked into using the wrong database 314files. The file hierarchy itself must be treated as one of the 315main databases in the protection configuration. 316.PP 317The notation \*QOwner(/d/f)\*U refers to the UID associated with the 318file \*Q/d/f\*U. Similarly \*QGroup(/d/f)\*U refers to the file's GID. 319The expression \*QGroupWrite(/d/f)\*U is true if the file \*Q/d/f\*U can 320be written by the members of \*QGroup(/d/f)\*U. The expression 321\*QWorldWrite(/d/f)\*U is true if the file can be written by members of 322the World group (i.e., all users). 323.sp 324Rules{ 325.sp 326.ul 327<Goal/Condition/Subgoal/Note> 328.PP 329Replace /d/f Write /d/f 330.PP 331Replace /d/f Replace /d\** 332.FS 333The condition stops the 334recursion at the root directory of the file system. 335.FE 336.PP 337Write /d/f Become Owner(/d/f)\** 338.FS 339The owner of a file can 340always change the access permissions to allow owner write access. 341.FE 342.PP 343Write /d/f GroupWrite(/d/f) Member Group(/d/f) 344.PP 345Write /d/f WorldWrite(/d/f) Member World\** 346.FS 347This subgoal is 348is achievable by all users provided they can get to the file. The 349notable exceptions are users logged in via anonymous ftp or uucp 350connections. These users have restricted access to the file 351hierarchy. 352.FE 353.sp 354} 355.PP 356\fBlogin\fP 357.PP 358The login program uses two database to set the UID and GIDs of the 359user's command interpreter. The contents of 360these databases and the protection of the databases themselves 361must be considered part of the protection configuration. 362.PP 363The user name \*Qroot\*U refers to the super-user. The label, \*QU\*U, stands 364for an arbitrary UID including \*Qroot\*U. The label, \*QG\*U, stands for 365an arbitrary GID. The expression \*QUIDS(G)\*U expands to all the 366UIDs authorized to use the group \*QG\*U according to the files 367/etc/group or /etc/passwd. 368 369.sp 370Rules{ 371.sp 372.ul 373<Goal/Condition/Subgoal/Note> 374 375Become U Replace /etc/passwd\** 376.FS 377This rule matches the goal \*QBecome root\*U. 378.FE 379 380Member G Replace /etc/group 381 382Member G Become UIDS(G)\** 383.FS 384The subgoal means to try to become any member of the group \*QG\*U. 385.FE 386.sp 387} 388.PP 389\fBrsh, rlogin, rcp\fP 390.PP 391Berkeley Unix includes several remote execution commands that greatly 392improve the usability of multiple Unix hosts connected by a network. 393The underlying authentication protocol does not resist an attacker 394that can transmit arbitrary messages on the network, but even if that 395problem was fixed, the databases used by these programs would have to 396be considered as part of the protection system. 397.PP 398The file /etc/hosts.equiv lists the names of the hosts that are 399trusted by the target machine's administrators. If a user has an 400account on the target machine, and on one of the trusted hosts, then 401that user can log into the target machine from the trusted machine 402without supplying a password. Users can list additional hosts (or 403other users) that they trust in a file (.rhosts) in their home 404directory. 405.PP 406The expression \*QNotEmpty(/d/f)\*U is true if the file /d/f exists and 407it is not empty. The label, \*Q~U\*U, refers to the home directory of user 408\*QU\*U. 409.sp 410Rules{ 411.sp 412.ul 413<Goal/Condition/Subgoal/Note> 414.PP 415Become U (~U/.rhosts) /etc/hosts\** 416.FS 417If there is 418a host listed in the user's remote access database and the host name 419table is replaceable, then an attacker can make his host appear to be 420the host listed in the user's database. This assumes that the 421attacker has super-user privileges on some host that can talk to the 422target host, because the attacker will need to create an account with 423the target's user name. This attack will become obsolete when hosts 424start using a distributed name server rather than a fix hostname 425database. However, the name server will open other avenues of attack. 426.FE 427.PP 428Become U Write ~U/.rhosts\** 429.FS 430The remote execution routines insist that the target user be the owner 431of the database file, so replace access is not sufficient to use this 432attack. 433.FE 434.PP 435Become U root Replace /etc/hosts.equiv\** 436.FS 437Remote execution with super-user privileges is only accepted from 438the hosts listed in ~root/.rhosts, so replacing the hosts.equiv file 439cannot be used to directly gain access to super-user privileges. 440.FE 441.sp 442} 443.PP 444\fBshells\fP 445.PP 446Several command interpreters, called shells, have been written for 447Unix. Different users can use different shells, but all shell have 448some mechanism for executing a list of commands when a user logs in. 449The files that specify these initialization commands are a part of the 450protection configuration that each user can change. 451.PP 452The expression \*QExists(/d/f)\*U is true if the file /d/f exists. 453.sp 454Rules{ 455.sp 456.ul 457<Goal/Condition/Subgoal/Note> 458.PP 459Become U Exists(~U/.login) Replace ~U/.login\** 460.FS 461This file contains the commands read when a user logs in. 462The conditional should really test to see if the user is actually using 463the /bin/csh command interpreter. If csh is being used, then 464this rule will work even if the file .login doesn't exist, so 465the conditional is overly strict. 466.FE 467.PP 468Become U Exists(~U/.cshrc) Replace ~U/.cshrc\** 469.FS 470This file is read each time a /bin/csh is executed such as at login 471and when a command file is executed. The conditional is also overly 472strict. 473.FE 474.PP 475Become U Exists(~U/.profile) Write ~U/.profile\** 476.FS 477Same trick for the /bin/sh command interpreter. 478.FE 479.sp 480} 481.PP 482\fBcron\fP 483.PP 484Cron is a program that is forked off when a Unix system is booted. 485This means that it runs with super-user privileges. Cron reads a 486database (/usr/lib/crontab) that describes the commands that should be 487executed periodically. By default these commands are executed with 488\*Qroot\*U privileges. 489.sp 490Rules{ 491.sp 492.ul 493<Goal/Condition/Subgoal/Note> 494 495Become root none Replace /usr/lib/crontab 496.sp 497} 498.PP 499\fBsendmail\fP 500.PP 501The Unix mail system has many features that allow flexible forms of 502information sharing. The most interesting feature (to system builders 503and to attackers) is that receiving mail can trigger the invocation of 504a program which is passed the mail message as its input. The file 505/usr/lib/aliases specifies the human readable form of a binary 506database that describes mailing lists, mail forwarding, and programs 507to invoke when mail is received by certain mailboxes. Being able to 508modify this database allows an attacker to get access to other 509people's user and group IDs because the mail sending program runs with 510the privileges of the user who invokes it. If the destination of the 511message is on the same host as the source, then the receiving program 512(also sendmail) will run with the invoker's privileges. If the source 513of the message is on another computer, then sendmail will run under 514the UID \*Qdaemon\*U. 515.sp 516Rules{ 517.sp 518.ul 519<Goal/Condition/Subgoal/Note> 520.PP 521Become daemon none Replace /usr/lib/aliases\** 522.FS 523This assumes 524that the command to build the binary database can be executed by 525everyone, or that it is executed automatically when the mailer detects 526that the binary database is out of date. There should also be rules 527to see if the binary database can be written directly. 528.FE 529.PP 530Become root none Replace /usr/lib/aliases\** 531.FS 532Assumes that 533\*Qroot\*U sends mail to some user on this machine. Such users can be 534found by scanning the mail logs, which are usually World readable. If 535such a user exists, the aliases database can be set up to tell sendmail to 536deliver mail to the recipient and invoke the attacker's program. Next 537time root sends mail to that user, the attacker's program will be 538invoked with root privileges. The program would test to see if it was 539running with \*Qroot\*U privileges, and if so plant a trap door such as 540making /.rhosts publicly writable. 541.FE 542.sp 543} 544.PP 545\fBboot\fP 546.PP 547When a Unix reboots, it executes the commands in the file /etc/rc. 548This file usually executes the commands in the file /etc/rc.local. 549.sp 550Rules{ 551.sp 552.ul 553<Goal/Condition/Subgoal/Note> 554 555Become root Exists(/etc/rc) Replace /etc/rc 556 557Become root Exists(/etc/rc.local) Replace /etc/rc.local 558} 559.PP 560\fBExtensions to the Unix model\fP 561(extensions) 562.PP 563This section lists some of the important pieces of the Unix protection 564system that were left out of the SU-Kuang's model. Most of these 565pieces could be added easily. 566.PP 567The major deficiency of the model is that it does not include all of the 568programs that run with super-user privileges. Each of these 569programs must be modeled if there is some way that an attacker could 570use the programs' databases to get access to root privileges. 571.PP 572Locating all the programs that run with super-user privileges is not 573easy. Many ordinary programs are executed inside of command files 574that are run with root privileges. This points out another 575shortcoming of SU-Kuang. It does not look inside of command files. 576For example, on system restart, Unix executes the commands in the file 577/etc/rc with super-user privileges. That file executes additional 578commands in the file /rc.local, so those commands also runs as root. 579The prototype has an explicit rule that covers this case, whereas it 580should deduce this and other cases by parsing the commands in /etc/rc. 581.PP 582The prototype does not understand search paths. On Unix, as with most 583systems, users do not specify the full pathname of the programs they 584want to execute. Instead, users specify a sequence of directories 585that should be searched to find the program. Often users tell their 586command interpreter to first look in a private directory of commands, 587and quite often that directory is writable by any member of the user's 588primary group. If an attacker can write a user's private command 589directory, then the attacker can plant a trojan horse on that user. 590For example, the user may want to execute /usr/local/gnuemacs, but the 591user may end up executing the attacker's program in 592/usr/smith/@_bin/gnuemacs. To model this attack, SU-Kuang would need to 593be able to read each user's startup command file to determine each 594user's search path. 595.PP 596The file goals considered by the model only include write and replace 597access to a file. Read access is not considered. To include read 598access, each piece of the protection system must be re-examined to see 599if it could provide read access to an arbitrary file. For example, 600the Unix finger program, which displays information about users, runs 601with super-user privileges so it can read an information file (.plan) 602in the specified user's home directory. Unfortunately, some 603implementations of the finger program allow the .plan file to be a 604symbolic link to another file, and thus the finger program allows read 605access to any file on the system. 606.PP 607The rules that model the file system do not include the fact that the 608disks can be accessed via the raw device files. Reading and writing 609the device files can be used to read and write arbitrary blocks on the 610disks. These files should only be accessible to the super-user, but 611often anyone can read them. If so, an attacker can read any file on 612the disk. 613.PP 614A different kind of deficiency in the model is that it does not allow 615the attacker to guess at passwords. On a system that allows users to 616pick their own passwords, an attacker can usually guess a few of the 617passwords. Assuming that an attacker can read the password file, 618\** 619.FS 620Protecting the password file from users logged in on a guest 621account or using anonymous file transfer is a good idea. However, 622protecting it from ordinary users is hard. Many programs need read 623access to the non-password information kept in that file, and making 624all those programs run with special privileges may create more 625problems than it solves. 626.FE 627the attacker can test passwords at the rate of about ten per second.\** 628.FS 629There are lots of tricks that speed up the execution of 630the Unix salted DES function on a 32 bit machine. 631.FE 632A 2000 word dictionary of common passwords can be processed at the 633rate of a few minutes per account. 634.PP 635As in any kind of modeling, the better the model, the better the 636results. Fortunately, in the case of Unix, making the model more 637detailed does not require using a more complicated framework. The 638rule-based framework of SU-Kuang is flexible enough to model all the 639features described in this section. 640.PP 641\fBPrototype Implementation\fP 642(implementation) 643.PP 644The SU-Kuang program described in this paper is easy to 645implement. The primary inputs to the program are a list of groups 646(privileges) accessible to the attacker (including the special group 647\*QWorld\*U), and the target goal (usually \*Qbecome root\*U). The 648program examines the protection configuration of the machine it is 649running on, so this can be considered a secondary input. The 650primary output is a list of the ways that an attacker can achieve the 651target goal from the initial privileges. Internally, the program 652builds a goal-tree based on a set of rules that are compiled into the 653program. When a node of the goal-tree can be directly achieved using 654the initial privileges, the program prints out the sequence of steps 655that describe the path from the given node of the goal-tree to the 656root of the goal-tree. 657.PP 658In classic Unix style, the prototype was initially implemented by a 659set of shell scripts (command files). Later, to improve performance, 660some of the shell scripts were re-written in C. The top level 661shell script keeps track of the goal-tree, and invokes other shell 662scripts to generate successive levels of the goal-tree. For each of the 663three kinds of goals (user, group, and file), there is a shell script 664that reads a list of goals of that kind and produces a list of 665subgoals. 666.PP 667Associated with each node of the goal-tree is a human readable comment 668that describes the path from each node to the root of the goal-tree. 669This comment is appended to a list of 'successes' if the 670associated goal can be directly achieved using the initial privileges 671of the attacker. Since each comment specifies the sequence of steps 672an attacker could use to achieve the target goal given the current 673goal, it is easy to derive the comments for subgoals from the comments 674of parent goals. The subgoal comments is the parent goal's comment 675plus an indication of which rule was used to derive the subgoal. 676.PP 677The basic data abstraction used by SU-Kuang is a goal-table. There 678are three goal-tables, one for each type of goal. The operations on a 679goal table are: 680.ul 681new, 682.ul 683addto, and 684.ul 685next. The 686.ul 687new 688operation creates an empty goal table. It takes a set of initial 689goals that are directly achievable by the attacker. The 690.ul 691addto 692operation adds a goal and a comment to the table. If the goal is 693already in the table, the table is not changed. If the goal is in the 694set of directly achievable goals, then 695.ul 696addto also appends the 697comment to the file that contains a list of successes. The operation, 698.ul 699next, examines a goal-table and returns any goal-comment pair that 700it has not already returned. The 701.ul 702addto 703operation is effectively 704the inner loop of a rule interpreter. 705.PP 706The goal-table abstraction is implemented by four files. One file 707keeps track of all of the goals in the table and it is used to avoid 708duplicate goals. Another file holds the list of goals initially 709available to the attacker. Two files are used to support the next 710operation. One file records all the goal-comment pairs that have been 711returned by the next operations, the other file lists the goal-comment 712pairs that have been added to the table but not yet selected by the 713next operation. 714.PP 715Using the goal-table abstraction it is easy to express rules as lines 716of a shell script. Figure 717.ul 718shell 719rule shows a rule and its shell 720script implementation. The conditional part of the rules are 721expressed by shell script conditionals (e.g., \*Q-z\*U means that a file 722exists and has a length of zero, \*Q!\*U and \*Q&&\*U mean logical 723negation and conjunction). 724.sp 725Rules{ 726.sp 727.ul 728<Goal/Condition/Subgoal> 729 730Become root NotEmpty(/.rhosts) Replace /etc/hosts 731.sp 732} 733 734.nf 735# $User and $OldComment are set by the goal-table next operation. 736# $FileGoals refers to the goal-table object for file type goals. 737if (($User == "root") && (! -z /.rhosts)) then 738 set NewComment="Fake HostAddress, $OldComment" 739 set SubGoal="Replace /etc/hosts" 740 addto $FileGoals $SubGoal $NewComment 741endif 742.fi 743Sample rule and corresponding shell script line. 744 745.PP 746The implementation of SU-Kuang is straight forward. The only reason 747for describing it in this paper is to demonstrate how easy it is to 748process the attacker-oriented rules that describe a protection system. 749.PP 750\fBExperience\fP 751(experience) 752.PP 753The SU-Kuang system has been run on a large number of 754sites managed by personnel with a wide range of skills and interests 755in security. It has almost always found a hole. A Kuang that 756incorporates the extensions described in section 757.ul 758extensions 759would find more holes. 760.PP 761I believe that holes are created because users do not understand how 762the various pieces of the protection system interact. The main 763evidence for this is that fact that most holes are found in the 764protection databases that are maintained by ordinary users (e.g., 765.login and .rhosts). Also, users who have recently been given special 766privileges tend to create holes that allow anyone to achieve 767super-user privileges. When I tell users about the problems SU-Kuang 768finds, they often do not understand what was wrong with the decision 769they made. 770.PP 771Users create security holes periodically. When I ran SU-Kuang 772periodically on one computer that had a large complicated protection 773configuration (e.g., the authorization databases included 300 users 774and 25 groups), SU-Kuang found new holes every week or two. Often 775these new holes were created when someone modified a security 776database. One common procedure for modifying a database is to first 777rename the original, then copy of the original into a file with the 778proper name, and finally edit the copy. The motivation for the first 779rename step is to preserve the timestamp that indicates when the 780database was last written. Unfortunately, the file copy step does not 781copy the protection information from the original database. The 782protection for the copy is determined by the defaults for the 783currently running process. It is not determined by the original. The 784file UID is set to the UID of the process that performs the copy, 785and the GID is set to the GID of the directory that contains 786the file. The permission bits are set to a default value specified in 787the copier's login command file. 788.PP 789The holes found by SU-Kuang point out that it is hard to set up multiple 790separate security groups under BSD4.2 Unix. For example, a group 791that allows its members to install programs in the /etc directory, 792also allows its members to replace the authentication database in 793/etc/passwd. The fact that users run with their full privileges (i.e., 794they can access multiple groups in the same process), makes Berkeley 795Unix easier to use than other versions of Unix that force users to 796access one group at a time. However, that same feature makes it 797easier for an attacker to plant a trojan horse on a user that is a 798member of a lower privilege group (e.g., the implementors of some 799project) and a member of a high privilege group (e.g., staff). 800.PP 801The impression I have gotten from running SU-Kuang is that most of the 802features that make Unix easy to use also make Unix hard to secure. 803However, SU-Kuang does make it easier to build a secure protection 804configuration for Unix. 805 806.PP 807\fBDiscussion\fP 808(conclusions) 809.PP 810To increase the usefulness of computers, systems designers have 811provided an increasing number of mechanisms that allow users to 812execute commands and share information. Since these new mechanisms 813must be considered part of the protection system, this trend has made 814protection systems larger and progressively harder to understand. As 815a protection system becomes more complex, it becomes unlikely that 816all the protection decisions are made correctly, and these mistakes 817can ruin the overall security of the information and resources 818controlled by computers. The commercial environment presents a 819special problem because usability is the primary goal of commercial 820information systems, but security cannot be neglected. There needs to 821be some way to manage the complexity of the protection systems that arise 822on information systems that stress usability. 823.PP 824This paper presents one approach for achieving both usability and 825security. The idea is to use rule-based systems to analyze the 826interactions between all the decisions that make up a computer's 827protection configuration. If analyzing a protection configuration is 828easy, then the manager of a system can ensure that the system meets 829the security objectives of its users. A program that performs a 830simple analysis of a Unix protection configuration was presented to 831illustrate that this sort of rule-based system is easy to build if 832the protection system is described from the attacker's viewpoint. 833This simple Unix analysis system, called SU-Kuang, answered the 834question "given access to a particular set of privileges, 835can an attacker achieve super-user privileges?". Using SU-Kuang, 836a security manager could ensure that a system did not allow ordinary 837user to achieve super-user privileges. 838.PP 839SU-Kuang is just one of many helpful Kuang-type systems. For example, 840many security objectives are expressed in terms of limiting the set of 841people who have access to particular privileges. A Kuang-type system 842that computed the set of privileges accessible to each user would help 843a security manager determine whether the security objectives are being 844met. Even better, if the bulk of the security objectives can be 845expressed in computer understandable form, then the bulk of the work 846of checking computer security could be automated. 847 848