PACL’s: An Access Control List Approach
`to Anti-Viral Security*
`David R. Wichers'’ Douglas M. Cook Ronald A. Olsson
`John Crossley Paul Kerchen Karl N. Levitt Raymond Lo
`
`Division of Computer Science
`Departmentof Electrical Engineering and Computer Science
`University of Califomia, Davis
`Davis, CA 95616
`
`(916) 752-7004
`
`Abstract—Almostall attempts at anti-viral software have been a reaction to specific viruses that have in-
`fected the user community. These solutions attemptto protect against a specific strain or strains of viruses
`rather than provide general protection against a wide variety of viruses. This paper describes a new, con-
`ceptually simple approach that provides a more general solution to the virus problem. Our approach asso-
`ciates with eachfile in a system an access controllist (ACL) that explicitly specifies which programs can
`modify the file. Thus, a virus cannot modify arbitrary files and its possible effects are greatly reduced.
`Our approach is unique in the way it uses ACL’s to specify which programs can access a file; other
`schemes use ACL’s to specify which users can accessa file and how. We use the acronym PACL’s,for
`Program ACL’s, to refer to these ACL’s and to our scheme. To see how our ideas can be incorporated
`into an existing operating system, we have designed an extension to the UNIX'TT kernel. We also con-
`structed a simulator that has allowed us to gain operational experience with our ideas in a typical user en-
`vironment. The results indicate that our scheme is a promising approach for preventing the spread of
`viruses without being too intrusive on users.
`
`* This research supported by Lawrence Livermore National Laboratory, the State of Califomia MICRO program, and
`Deloitte, Haskins, and Sells, Inc.
`tt David Wichers’ present address is: Arca Systems,Inc., 2841 Junction Ave, Suite 201 San Jose, CA 95134 (408) 434-
`
`6633
`
`ttt UNIX is a registered trademark of AT&T.
`
`340
`
`CS-1023
`Cisco Systems, Inc. v. Finjan, Inc.
`
`CS-1023
`Cisco Systems, Inc. v. Finjan, Inc.
`
`

`

`1. Introduction
`
`A computer virus is a program that can ‘infect’ other programs by modifying them to include a possibly
`evolved copy ofitself [6]. One attribute of viruses that allows them to spread so casily is that a virus
`inherits all of a user’s privileges when the user runs an infected program. Typical operating system pro-
`tection schemes provide no help in such a case—they protect a user’s files from other users, but not from
`him/herself. Thus, a virus can quickly infect all of a user’s files. Even worse, if the user has special sys-
`tem privileges (e.g., ‘superuser’), the virus can infect all files on a given system.
`A typical virus propagates itself by searching for an uninfected program and copying the viral part
`of its code into that program so that when the newly infected program is run, the viral code will be exe-
`cuted. To prevent propagation, viruses must be prevented from inserting themselves into other programs.
`(We assume that the operating system prevents programs, including viruses, from writing dircetly to
`disk.)
`
`Two simple observations form the basis of our approach. First, the typical virus carricr is unrelated
`to the programsthat it infects. Second, programs exccuting on behalf of a user have more privileges than
`are necessary to complete their assigned task. For example, an infected game program might have the
`privilege to aecess all of a user’s files. Yet it should only have access to those related to the game, ¢.g., a
`seore file. Our approach, then, is to restrict a program’s privileges to the minimum needcd to complete its
`assigned task. Then,if a program is infeeted, it will not be able to infect unrelated programs (files).
`To imposethis least privilege restriction, we associate an access control list (ACL) [7, 9] with each
`file in the system.
`In our scheme,a file’s ACL contains the namesof all the programs that may modify
`the file. We use the acronym PACL’s, for Program ACL’s, to refer to these ACL’s and to our scheme.
`Thus, to modify (write, append, delete, etc.) the file, a program must be on thefile’s PACL. Our use of
`PACL’s differs from that found in standard ACL schemes: westore names ofprograms, as opposedto the
`names of users, that ean aecess eachfile.
`
`The notion ofleast privilege fits well with common system usage. Users create files using a number
`of different programs. These files are usually modified only by the programs that create them. For exam-
`ple, consider the typical steps involved in creating, compiling, and linking a C program. To create the
`program, the user uses his/her favorite editor to create source files. During the entire life of those files,
`they are only modified by the same editor that created them. Whenthese files are compiled, the compiler
`generates object files. Each time the program is recompiled, these object files are written over by the
`same compiler, and not by any other program. Similarly, the linker ereates the executable and writes over
`the executable file cach time the program is relinked. This usage suggests that normal files are modified
`by a small number of programs, usually only one. Of coursc, more complicated usages exist, but they are
`less common.
`
`Since the number of programs that need to modify a single file is usually very small, we can keep
`track of these programs in order to prevent other programs from deliberately or accidentally modifying
`files. This method is similar to existing computer protection mechanisms based on access controllists.
`The standard ACL schemeis designed to control how each uscr’s files can be aecessed by otherusers.
`Thatis, a file’s ACL indicates what users mayaccessthe files, and in what ways.
`If the ACL does not
`explicitly state that a user is allowed to perform the function requested,then it is not allowed. The differ-
`enee between this security problem and the virus problem is that a virus security system needsto protect a
`user from him/herself, not from other users. The virus problem is inherently a problem ofintegrity, not
`security. Our PACL-Integrity scheme is therefore simpler, associating with cachfile a list of all programs
`that ean modify the file.
`
`To see how our ideas can be incorporated into an existing operating system, we have designed an
`extension to the UNIX kernel that incorporates our PACL seheme. We have also constructed a simulator
`to allow us to gain experience with the PACL-Integrity model without requiring actual changes to the
`kernel. The experience wehave gained showsthat the scheme seemsreasonable to implementandis not
`too intrusive on the user.
`
`

`

`The remainderof this paper is organized as follows. Section 2 discusses our PACL-Integrity model
`in more depth. Section 3 describes how the model can be realized in the UNIX kemel. Section 4 presents
`the simulator and section 5 describes our experience using it. Section 6 discusses the tradeoffs involved
`in our approach and outlines future work. Section 7 summarizes related work. Finally, section 8 contains
`some concluding remarks.
`
`2. The PACL-Integrity Model
`The PACL-Integrity model associates a PACL with each file on the system. The PACL fora given file
`names all programsthat have the privilege to modify the file. Whenafile is created, its PACL is set to
`contain the name of the program that created the file. During the life of the file, the file’s PACL can be
`changed only by a trusted utility program. This utility allows a userto tailor the protection mechanism to
`meet his/her needs,
`
`The success of a protection scheme depends on how intrusive users find it. A scheme that is too
`intrusive will effectively render a system unusable. For example, requiring an explicit acknowledgement
`from a user each time anyfile is to be accessed might be a secure scheme,butit is not usable. Moreover,
`if a schemethat is too intrusive provides a means by whichthe user can disable it, then users will simply
`run with security checks disabled, effectively rendering a system insecure.
`To make our approach secure yet usable, we include a number of ‘user-friendly’ features. These
`features simplify common usages of the PACL-Integrity mechanism. Thefirst feature is an inheritance
`mechanism that allows a user to define a default PACL for a directory. Anyfile (or subdirectory) created
`in this directory inherits the directory’s default PACL, as well as the name ofthe program that created the
`file. This feature allows the userto tailor a directory to the type of work being donein it. An entire sys-
`tem (or account) can be tailored in this manner by creating a default at the root (or home) directory and
`then building directories belowit.
`The second feature allows a user to specify a global inheritance policy. The user can define a
`default PACL for any file based on its extension (suffix). For example, a UNIX objectfile is typically
`created by an assembler or compiler and given the extension ‘.o’. Later, the linker reads in a numberof
`object files, links them together, and generates executable code. Whenit has successfully generated an
`executable, it sometimes will remove the objectfiles as they are no longer needed. Since the objectfiles
`were created by the compiler, their PACL’s will contain the nameof the compiler, but notthat of ‘Id’ (the
`linker). With the extension-based default mechanism, the user can define a default for ‘.o’ files that con-
`tains ‘ld’, thereby allowing the linker to remove unwanted objectfiles after it has created the executable.
`The third feature allows the user to enable/disable the PACL mechanism for a particularfile. This
`feature is provided by associating a flag with eachfile. If this flag is enabled, the normal PACL security
`rules will be applied to that file.
`If the flag is disabled, then all PACL security rules for the file are
`ignored and only the ‘normal’ security rules will be used whenthefile is accessed; i.e., any program with
`appropriate access rights can modify the file.
`The final feature allows a user to temporarily disable the PACL mechanism forall of his/herfiles. It
`also allows the system administrator to temporarily disable the PACL mechanism for the entire system.
`This feature is needed to facilitate programs that need to modify many orall of a user’s or system’s files.
`For example, a utility program thatrestores files from backup tapes will typically modify manyfiles dur-
`ing its execution.
`These features are provided to allow the system to be tailored to meet each individual user’s needs.
`Once defaults have been set up correctly, each user should be able to use the system while being protected
`from viruses, without being unduly inconvenienced by the PACL mechanism,
`The PACL-Integrity mechanism makesseveral basic assumptions about the underlying hardware
`and operating system. The devices on which programsare stored (e.g., disk) must be protected so that
`they can only be accessed by kemel code. Without such protection, a virus could wnite directly to a dev-
`ice, bypassing all protection mechanisms. This requirement rules out the possibility that this type of
`
`342
`
`

`

`system would be viable in some personal computer environments where direct disk access is not pro-
`tected, forexample. The operating system itself must checkall file accesses to make sure the PACL secu-
`rity rules are enforced.
`It must also protect the PACL’s themselves from illegal modification. The
`hardware and operating system must also protect against standard attacks, such as modifying system
`buffers or kernel code.
`
`3. A PACL-Integrity Model for UNIX
`
`3.1. Overview
`
`Our PACL-Integrity model can be implemented for UNIX by extending the keel. The PACL scheme
`must be included in the kernel to ensure thatall file accesses are checked. The current UNIX protection
`mechanisms, based on user names,are still enforced. If an attempt to write satisfies the existing security
`rules, the PACL mechanism then further verifies the validity of the access.
`Whena file is created, its PACL is created as well. A file’s PACL is stored as part of the header
`information (i.e., inode) of the file, just like the mode bits, owner, size, date, and time fields. Since the
`PACL is part ofa file’s inode, the PACL information forafile is removed whenthe file is deleted, which
`simplifies the task of PACL maintenance.
`The kerel builds the PACL for a new file from three items. Thefirst item put in the PACL is the
`name of program that creates the file.
`In UNIX, a program’s nameis its complete pathname. For exam-
`ple, the editor program ‘vi’ in the directory ‘/usr/ucb’ has the name ‘/usr/ucb/vi’. The second item put in
`the PACL is the default PACL of the directory in which the file is created. The final item put in the
`PACL is the default, if any, for the new file’s extension. (Note that the defaults put in the PACL are those
`in effect when the file is created; if the defaults are later changed, the PACL’s of existing files are not
`modified automatically.)
`The specific kinds of access for which the kernel must check include openinga file for writing and
`unlinking a file, The former gives the program the privilege to modify the file in any manner while the
`latter deletes the file. We consider deletion a form of modification.
`
`
`
`3.2, New System Calls
`Nine new system calls give programsthe ability to interact with the PACL mechanism. Thefirst system
`call, setppriv(), is a privileged call that sets the state of the current process into a modethatallowsit to
`call the other new system calls.
`(This method is analogous to a processsetting its user-id to root in regu-
`lar UNIX.) Without executing this initial call, a process is not allowed to use any of the other system
`calls that interact with the PACL’s, with one exception described below; in such a case, they simply
`return an error to the calling process. The only programs that are allowed to use setppriv() are the pro-
`grams listed in the file ‘/etc/paclprivs’. One example of an entry in this file is the utility program
`describedlater.
`
`The second call, paclenable(), is used to enable or disable (based on its argument) the entire PACL
`mechanism for the given process and its children. Ifthe initial system process (init) disables the PACL
`mechanism, then the effect is that the PACL mechanism is disabled for the entire system since all
`processes are children of init.
`It allows the process to
`The third call, clrppriv(), removes a process from PACL privileged mode.
`relinquish its privilege when no longer needed. The twocalls setppriv() and clrppriv() allow programs to
`create critical regions in their code where they have privilege to access PACL’s. Outside of these regions,
`PACL privileges are not necessary and hence should not be enabled.
`The fourth call, getppriv(), is the only call that will not retum an errorif setppriv() has not been pre-
`viously called.
`It tells the currently running process whetheror not it is currently in PACL privileged
`mode,i.e., the process successfully called setppriv() without calling a corresponding clrppriv().
`
`343
`
`

`

`The next two new system calls allow a program to manipulate PACL’s. Only the ownerofa file
`can change its PACL. Thefirst, addpacl(), adds a program nameto a given file’s PACL. The second,
`delpaci(), deletes a program name from a given file’s PACL. These system calls also allow a file’s owner
`to enable/disable the PACL mechanism fora particularfile.
`The remaining three system calls allow a program to query a file’s PACL in various ways. These
`calls can only be executed by the file’s owner. Thefirst, getpaci(), retums a list of all the program names
`ina file’s PACL. The second, verpaclm(), determines if a specified program hasthe privilege to modify a
`given file.
`It compares the program name with those in the file’s PACL, handling links if the filename
`provided is a link to anotherfile. The third, verpacir(), determines if the specified program has the
`privilege to remove a given file.
`It is similar to verpaclm() except it does not traverse links because any
`remove reference to a link would be removing the link, and not the file to which the link points.
`
`3.3. The ch Utility
`The above eight system calls provide the means for a system program to manage PACL’s. The utility
`program, ch, described below uses these calls and is an example of a type of user interface that can be
`provided for userinteraction with this mechanism. chis listed in ‘/etc/paclprivs’ so that it is authorized to
`use these PACL system Calls on the user’s behalf.
`To use the ch utility, the user must first enter his/her password. We make the assumption that a
`virus Can assume a user’s login name butit does not know the user’s password. Otherwise, we cannot
`distinguish a virus from a legitimate user.
`ch allowsthe userto:
`
`e add/remove program names from PACL’s;
`
`e display the contents of PACL’s;
`
`e set/clear the enable flag in PACL’s;
`
`® modify the default PACL’s for directories and file extensions; and
`
`® temporarily turn off the entire PACL mechanism (e.g., for that user during a single login session).
`These features correspond to those described in section 2. Several additional features make the utility
`more usable. One feature allows the userto traverse the directory structure; a user can, therefore, move to
`different directories without exiting the utility. A second feature is that ch provides all the remove
`privileges that exist in a normal shell. The ‘rm’ (remove) program may not have privilege to remove
`most files; i.¢., it may not be in the PACL for every file. The utility, therefore, provides an ‘rm’ com-
`mand with functionality equivalent to that of the ‘rm’ program. Without such a command, the user would
`need to add the ‘rm’ program to a file’s PACL,exit the utility, and then use the ‘nm’ program to remove
`the program. For the samereason, the utility also provides an ‘rmdir’ (remove directory) command,
`Basically, ch provides a subset of the normal shell commands along with the features described above
`that allow the userto tailor the PACL security system. If the user executes a program from within ch, a
`new processis created to execute that program. This process is subject to the rules that apply to the new
`program, not those that apply to the ch program. Otherutility programs can easily be generated by the
`system administrator by writing programs using these system calls and then adding the program namesto
`‘/etc/paclprivs’.
`
`3.4. The Role of the Superuser
`In existing UNIX systems, the superuser—e.g., the ‘root’ account—may bypass the normal protection
`mechanisms. Having root privilege is not sufficient to override the PACL protection mechanism in our
`system. In particular, a user (or would-be virus) executing as root can only disable the PACL mechanism
`using the ch utility, for which it must give the root password. A program running as root must, therefore,
`be listed in a file’s PACL in order for that program to havethe privilege to modify that particularfile.
`
`344
`
`

`

`This approach limits the damage potential of a virus that somehow acquires root privilege.
`This restriction, however, requires us to change the current method by which the superuser changes
`the root password. Currently, the superuser uses the ‘passwd’ program to change the root password. The
`password program prompts for the new password without asking for the old one. Thus, any user (or pro-
`gram) that acquires root privilege can change the root password without knowing the previous password.
`Such a user could then use ch to break system security. Therefore, we now require passwd to ask the
`superuser for the old root password before changing it. This additional requirementprevents a virus from
`changing the root password without knowing the previous password. The one exception is that the
`superuser can change the root password without entering the old password whenthe system is brought up
`in console (single user) mode. This exception exists to allow access to a system in case its password file
`gets corrupted.
`Since the success of our anti-viral scheme depends heavily upon password security, viruses must be
`prevented from obtaining passwords.
`In our scheme, the password file itself is protected so the only pro-
`grams allowed to modify it are ‘passwd’ and those that modify information aboutusers (e.g., user names,
`phone numbers, etc.). A new user can be added according to one of two methods. The first method is to
`add an editor, say ‘vi’, to the password file’s PACL, then edit the file to include the new user, and then
`remove ‘vi’ from the PACL. This method is not a major inconvenience to the system administrator if
`new users are added infrequently. On the other hand, the above method is cumbersome for a system
`where new users are added frequently. A better method, then, is to write a new utility program that is
`specifically designed to add users to the password file and to place the name of this new utility in the
`password file's PACL, Execution of this utility program should be restricted to only the system adminis-
`trator,
`
`4, A PACL-Integrity Model Simulator
`We constructed a UNIX-based simulator to allow us to experiment with our ideas. Building a simulator
`required less effort than making kemel modifications would have. Doing so also had no impact on other
`users of the system as making kemel modifications would have.
`The simulator consists of modifications to the standard C library. 1t is not a program itself. The
`simulator library contains modified versions of the normal system calls that deal with files (e.g., open)
`and code for the new system calls dealing specifically with PACL’s. The normal system calls take the
`same arguments as usual. Thus, the simulation environmentis transparent to most programs, they just
`need to be linked with the new library. The codein the library routine that handles a normal system call
`is an interface to the original routine that handles the system call.
`It first does whatever PACL checking
`is needed and then calls the onginal routine, which has been renamed.
`The simulator maintains a virtual root, The virtual root allows any directory to act as the root direc-
`tory during simulation experiments. The simulator mapsany reference to root (i.e., a pathnamethatstarts
`with ‘/") to the virtual root. For example,
`if ‘“cook/test/pacl’ is the virtual root, the simulator maps
`‘/oin/cp’,
`the copy program,
`to ‘“cook/test/pacl/bin/cp’. Using a virtual root
`lets us test the PACL
`mechanism by defining a subdirectory that contains an entire UNIX environment, i.c., all the standard
`system programs. The programs in such a subdirectory are linked with the simulation library. Using a
`virtual root also allows a user to experiment on a system without requiring root privileges. Further, it
`allows several users to run experiments at the same time as each one can define their own virtual root.
`(The idea of a virtual root is similar to the UNIX ‘chroot’ command except it works on a per-process
`basis and does not require root permission.)
`
`
`
`Section 3 described howafile’s PACL informationis stored as part of its inode. Thatis not possi-
`ble without kemel modifications. The simulator, therefore, stores the PACL information for file x in
`another
`file, x.paci. Similarly,
`the default directory PACL for a directory is stored in the file
`‘default.pacl’. These files are not visible to the user when running under the simulator. They can only be
`created by the simulatorfor its purposes.
`
`345
`
`

`

`The default PACL information forfile extensions is stored in an environment variable. The simula-
`tor uses this information along with the default directory PACL information and the executing program’s
`name (see below) when creating the PACLfor a newfile.
`The simulator needs the name of the currently executing program for creating PACL’s and compar-
`ing access rights. The simulator maintains that name in an environmentvariable. The variable is set in
`the simulator library’s execve() system call, which is invoked whenevera processis created. It is exam-
`ined whenever a process executes a system call that needs PACL privilege. This method is insecure
`because a process can modify its environment variables—e.g., a process can change the simulator’s idea
`of its name to gain illegal access to a file. However, the method is adequate for our simulation purposes.
`In a keel implementation, the nameof the currently executing process would be stored so that only the
`kernel could modify it.
`
`5. Experience
`The additions to the C library to form the simulator library required about 1000 lines of code. The addi-
`tional code intercepted system calls, translated pathnamesto virtual root-based pathnames, and checked
`PACL permissions.
`Wehave used the simulator in a numberofsituations and have gained someideaas to the effective-
`ness and intrusiveness of our PACL scheme. Our tests fall into two categories: general interactive use
`and installation of software systems.
`In the first kind of tests, users performedthe activities they normally
`would on a system—i.e., developing programs, wriling papers, etc.—and would also occasionally attempt
`to defeat the PACL mechanism.
`In these tests, the PACL mechanism worked as it was intended: It was
`successful in preventing simulated viral attacks without being too intrusive. One observed drawback,
`however, was that users needed to be aware of the PACL mechanism. One common problem, for exam-
`ple, was that users had problems removingfiles since the remove program ‘rm’ was not on the PACL of
`thefile being removed. The utility program proved useful, but it requires the user to learn a newtool.
`The second kind of simulator test—software installation—was also generally successful. We
`attempted to install two large software systems, GNU Emacs [11] and the SR concurrent programming
`language [1], in the simulated environment. Although the installations uncovered several problems with
`our simulator, they did demonstrate the validity of the overall design of our PACL scheme.
`
`6. Discussion
`
`Our PACL-Integrity model is an integrity model only. As such, it protects files from illegal modification
`but not from exposure. One advantage of it being just an integrity model is that the system is greatly
`simplified. PACL checks occur when the file is opened for writing and the checks themselves are very
`fast. A PACL check consists of looking up the program name to see if it exists in the file’s PACL. Since
`a file’s PACL will typically be very short, that check will be very fast and the space overhead involved
`per file will be minimal.
`(For simplicity, we have restricted in ourinitial designs a fixed sized space to
`store the PACL for eachfile.)
`
`Our PACL schemeis obviously not perfect. It can be defeated by exploiting existing operating sys-
`tem security loopholes or trojan horses.
`It also requires that the PACL’s for the system are set up
`correctly, which requires user and system administrator cooperation.
`One potential vulnerability of our PACL schemeis that a virus could invoke other, more trusted
`programs to doits dirty work. For example, a virus could send commandsto infectfiles to ‘vi’. One pos-
`sible solution to this problem would be for programs to imposerestrictions on how they operate; e.g., ‘vi’
`might accept only interactive input rather than accepting input from another program. A more general
`solution, however, will require further study. Even with this vulnerability, our PACL scheme substan-
`tially reduces the vulnerability of the overall system.
`One issue that we have not fully resolved is exactly what constitutes the name of a program. As
`described carlier, the name of the file is its complete pathname. However,a single file on disk can have
`
`346
`
`

`

`many different names(i.e., paths to it) through Aard or symbolic links. A hard link establishes another
`name fora file by having another directory entry point to thefile’s inode. A symbolic link is a file whose
`contents is a file name; when the symbolic link is opened, the kemel instead opens the contents of the
`link. Given such possibilities of multiple names for a given file, which name or namesshould be used in
`the PACL checks needsfurther study.
`Another issue related to naming is what to do when the name of a program changes. Since the
`PACL’s store full pathnamesof a file, they must be changed. One possible solution is to extend the ch
`utility to provide a rename option. However, that is expensive as it needs to search all PACL’s for all
`files in the system. Moreover, it requires user intervention. Another possible solution is to store in the
`PACL the program’s inode numberinstead of its name. A sequence number would also need to be main-
`tained for each inode to distinguish between different uses of an inode, e.g., to ensure that when a free
`inode is reused,it does not accidentally allow access to the wrong files. Renaming is important because it
`occurs fairly frequently, although more often for user programs than for system programs. Another
`related issue is what to do when a new version of a program is installed.
`If program names are stored,
`then the PACL scheme worksfine. If inode numbers are stored, then they would need to be updated,
`which is expensive as described above. One final related issue is how to handle deletion of programs.
`Whena program is deleted, it should be removed from all PACL’s in which it appears. Otherwise, a
`virus might install a new program in that place. On the other hand,if a program is deleted just before a
`new version ofit is installed, then the cost of cleaning up all PACL’s should be avoided. These issues are
`important and related to one another. Further work and experience is needed before the ‘nght’ solution
`can be determined.
`
`One possible objection to the entire PACL approachis that it requires future knowledgeto be totally
`effective: it must know for all time what programs will need to access what files. That is clearly impossi-
`ble, especially since new programs can be added to a system. For example, suppose an existing file sys-
`tem has its PACLlists set up so that the C compiler, say located in ‘/bin/cc’, is allowed to create ‘.o’ files.
`If an alternate C compiler such as GNU’s, say located in ‘/usr/local/gcc’, is added to the system, then the
`PACL’s for all ‘.o’ files should be updated to also allow the new compiler to modify those files. Requir-
`ing users to perform such modifications of PACL’s is not attractive; a tool to automate such modifications
`should be straightforward to develop.
`The use of the extension-based defaults and the directory inheritance in our PACL scheme provides
`a flexible enough environmentfor a user to perform mosttasks without considering the PACL’s. A more
`complicated task, especially one involving files with nonstandard extensions, may require the user to
`modify PACL defaults. However, once that is done, the task can be completed with little difficulty. User
`intervention is typically only required to sct up defaults for a new task; repetitions of that task do not
`require further intervention.
`In particular, the system
`The initial setup of a system that uses PACL’sis also a nontrivial task.
`administrator must determine PACL’s for each system file, and directory and extension defaults. For-
`tunately, such work needs to be done just once. Of course, this problem will go away if PACL systems
`become the standard; vendors would then ship PACL-equipped systems already set up.
`
`7. Related Work
`
`Recently, Eugene Bacic [2] proposed a similar scheme that was developed independently from that pro-
`posed in this paper. His mechanism also associates an additional ACL-like list with cach data object to
`provide integrity controls by constraining the programs that can manipulate an object. His paper
`addresses the subject from a more theoretical slant than the application specific (UNIX) approach dis-
`cussed here.
`
`Karger [8] and Bocbert and Ferguson [4] have proposed solutions similar to each other that attempt
`to address the Trojan Horse problem. Both solutions interpose a protected subsystem between programs
`and thefilesystem to protect the filesystem. They are related to the mechanism we described in that they
`
`347
`
`
`
`

`

`use some type of knowledge base (in our case the PACL’s) to make access control decisions based on the
`user executing the program, the program being executed and the files being accessed. The methods they
`proposed to generate and use this knowledge base are quite different. The intent of our solution is to gen-
`erate this knowledge base as simply and easily as possible, while making it simple to design, simple to
`build, simple to maintain, powerful to use and simple to understand.
`In a landmark paper, Clark and Wilson [5] introduced a model of integrity that is based on control
`of which actions users can perform onparticular data items. The model is applie