PACL’s: An Access Control List Approach
`to Anti-Viral Securityi
`
`David R. WienersiT Douglas M. Cook Ronald A. Olsson
`John Crossley Paul Kerchen Karl N. Levitt Raymond Lo
`
`Division of Computer Science
`Department of Electrical Engineering and Computer Science
`University of California, Davis
`Davis, CA 95616
`
`(916) 752-7004
`
`Abstract—Almost all attempts at anti-viral software have been a reaction to specific viruses that have in-
`fected the user comm unity. These solutions attempt to 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 each file in a system an access control list (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 access a 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 UNIXhuf 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.
`
`f This research supported by Lawrence Livermore National Laboratory. the State of California MICRO program. and
`Deloitte, Haskins, and Sells, Inc.
`
`H David Wichers' present address is: Area Systems, Inc... 2841 Junction Ave, Suite 201 San Jose, CA 95134 (408) 434-
`
`6633
`
`"t UNIX is a registered trademark of AT&T.
`
`3 4 0
`
`08-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 of itself [6]. One attribute of viruses that allows them to spread so easily 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
`himlherself. 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 vims 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. vimses must be prevented from inserting themselves into other programs.
`(We assume that the operating system prevents programs, including viruses, from writing directly to
`disk.)
`
`Two simple observations form the basis of our approach. First, the typical vims carrier is unrelated
`to the programs that it infects. Second, programs executing 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 access all of a user's files. Yet it should only have access to those related to the game, e.g., a
`score file. Our approach, then. is to restrict a program’s privileges to the minimum needed to complete its
`assigned task. Then. if a program is infected. it will not be able to infect unrelated programs (files).
`
`To impose this 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 names of 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 the file‘s PACL. Our use of
`PACL's differs from that found in standard ACL schemes: we store names of program, as opposed to the
`names of users, that can access each file.
`
`The notion of least 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. When these 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 creates the executable and writes over
`the executable file each time the program is relinked. This usage suggests that normal files are modified
`by a small number of programs, usually only one. Of course, 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 control lists.
`The standard ACL scheme is designed to control how each user‘s files can be accessed by other users.
`That is, a file's ACL indicates what users may access the 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-
`ence between this security problem and the virus problem is that a virus security system needs to protect a
`user from him/herself, not from other users. The vinrs problem is inherently a problem of integrity, not
`security. Our PACL-lnrcgrr’ry scheme is therefore simpler. associating with each file a list of all programs
`that can 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 scheme. We have also constructed a simulator
`to allow us to gain experienCe with the PACL—lntegrity model without requiring actual changes to the
`kernel. The experience we have gained shows that the scheme seems reasonable to implement and is not
`too intmsive on the user.
`
`341
`
`

`

`The remainder of 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 kernel. 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 for a given file
`names all programs that have the privilege to modify the file. When a file 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 user to tailor the protection mechanism to
`meet hisfner 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 eachtime any file is to be accessed might be a secure scheme, but it is not usable. Moreover.
`if a scheme that is too intrusive provides a means by which the 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. The first feature is an inheritance
`mechanism that allows a user to define a default PACL for a directory. Any file (or subdirectory) created
`in this directory inherits the directory’s default PACL, as well as the name of the program that created the
`file. This feature allows the user to tailor a directory to the type of work being done in 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 below it.
`
`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 object file is typically
`created by an assembler or compiler and given the extension ‘.o’. Later, the linker reads in a number of
`object files. links them together. and generates executable code. When it has successfully generated an
`executable, it sometimes will remove the object files as they are no longer needed. Since the object files
`were created by the compiler, their PACL's will contain the name of the compiler, but not that of ‘ld’ (the
`linker). With the extension-based default mechanism, the user can define a default for '.0' files that con-
`tains ‘ld’, thereby allowing the linker to remove unwanted object files after it has created the executable.
`
`The third feature allows the user to enable/disable the PACL mechaniSm for a particular file. This
`feature is provided by associating a flag with each file. If this flag is enabled, the normal PACL security
`nrles will be applied to that file.
`If the flag is disabled, then all PACL security rules for the file are
`ignored and only the ‘norrnal' security rules will be used when the file 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 for all of his/her files. It
`also allows the system administrator to temperarily disable the PACL mechanism for the entire system.
`This feature is needed to facilitate programs that need to modify many or all of a user’s or system's files.
`For example. a utility program that restores files from backup tapes will typically modify many files 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 conectly, each user should be able to use the system while being protected
`from viruses, without being unduly inconvenienced by the PACL mechanism.
`
`The PACL-lntegrity mechanism makes several basic assumptions about the underlying hardware
`and operating system. The devices on which programs are stored (e.g., disk) must be protected so that
`they can only be accessed by kernel code. Without such protection, a virus c0uld write directly to a dev—
`ice, bypassing all protection mechanisms. This requirement rulcs 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. for example. The operating system itself must check all 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 kemel. The PACL scheme
`must be included in the kernel to ensure that all 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.
`
`When a 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 of a file's inode. the PACL information for a file is removed when the file is deleted. which
`simplifies the task of PACL maintenance.
`
`The kernel builds the PACL for a new file from three items. The first item put in the PACL is the
`name of program that creates the file.
`In UNIX. a program‘s name is its complete pathname. For exam-
`ple. the editor program ‘vi' in the directory 'lusr/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 opening a 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 programs the ability to interact with the PACL mechanism. The first System
`call. serpprivU. is a privileged call that sets the state of the cunent process into a mode that allows it to
`call the other new System calls.
`(This method is analogous to a process setting 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
`retum an error to the calling process. The only programs that are allowed to use semprM) are the pro-
`grams listed in the file 'letc/paclprivs'. One example of an entry in this file is the utility program
`described later.
`
`The second call. paclenableo. is used to enable or disable (based on its argument) the entire PACL
`mechanism for the given process and its children.
`If. the 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 fair.
`
`It allows the process to
`The third call. clrpprr'v(). removes a process from PACL privileged mode.
`relinquish its privilege when no longer needed. The two calls serpprivO and clrpprivo 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 return an error if serppriv() has not been pre-
`viously called.
`It tells the currently running process whether or not it is currently in PACL privileged
`mode, i.e.. the process successfully called setpprivfl without calling a corresponding clrpprivU.
`
`343
`
`
`
`

`

`The next two new system calls allow a program to manipulate PACL's. Only the owner of a file
`can change its PACL. The first. addpacm, adds a program name to a given file's PACL. The second.
`deipaclU. 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 for a particular file.
`
`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. The first. gerpacm. returns a list of all the program names
`in a file’s PACL. The second. verpaclmo. determines if a specified program has the 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 another file. The third. verpaclro. determines if the specified program has the
`privilege to remove a given file.
`It is similar to verpaclmO 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 user interaction with this mechanism. ch is listed in ‘letc/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 but it does not know the user's password. Otherwise. we cannot
`distinguish a virus from a legitimate user.
`ch allows the user to:
`
`o add/remove program names from PACL's;
`
`0 display the contents of PACL‘s:
`
`I setfclear the enable flag in PACL’s;
`
`I modify the default PACL‘s for directories and file extensions: and
`
`o 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 user to 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.e.. it may not be in the PACL for every file. The utility. therefore, provides an ‘rrn' 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 ‘rm' program to remove
`the program. For the same reason, the utility also provides an ‘rrndir' (remove directory) command.
`Basically. ch provides a subset of the normal shell commands along with the features described ab0ve
`that allow the user to tailor the PACL security system. If the user executes a program from within ch, a
`new process is 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. Other utility programs can easily be generated by the
`system administrator by writing programs using these system calls and then adding the program names to
`‘letcfpaclpn'vs’.
`
`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 have the privilege to modify that particular file.
`
`344
`
`

`

`
`
`This approach limits the damage potential of a virus that somehow acquires root privilege.
`
`This restriction. however. requires us to change the eunent method by which the superuser changes
`the root password. Cunently. the supemser 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 preview 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 requirement prevents 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 when the 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 about users (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 ether 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 titan making kernel modifications would have. Doing so also had no impact on other
`users of the system as making kernel modifications would have.
`
`11 is not a program itself. The
`The simulator consists of modifications to the standard C library.
`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 environment is transparent to most programs; they just
`need to be linked with the new library. The code in 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 original 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 maps any reference to root (i.e.. a pathname that starts
`with ‘1‘)
`to the virtual root. For example.
`if “cookftcsl/pacl'
`is the virtual root. the simulator maps
`'Ibinlcp‘.
`the copy program.
`to "oook/test/pacl/binlcp‘. Using a virtual root
`lets us test the PACL
`mechanism by defining a subdireCtory that contains an entire UNIX environment. i.e.. 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 roor 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 excopt it works on a per-process
`basis and does not require root permission.)
`
`Section 3 described how a file's PACL information is stored as part of its inode. That is not possi-
`ble without kernel modifications. The simulator. therefore. stores the PACL information for file 1 in
`
`the default directory PACL for a directory is stored in the file
`file. x.pacl. Similarly.
`another
`‘dcfault.pacl'. These files are not visible to the user when running under the simulator. They can only be
`created by the simulator for its purposes.
`
`345
`
`

`

`The default PACL information for file 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 PACL for a new file.
`
`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 environment variable. The variable is set in
`the simulator library's cxecveU system call. which is invoked whenever a process is 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—cg. 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 kemel implementation. the name of the cun'ently executing process would be stored so that only the
`kemel 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 pathnames to virtual root-based pathnames. and checked
`PACL permissions.
`
`We have used the simulator in a number of situations and have gained some idea as to the effective-
`ness and intntsiveness 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 performed the activities they normally
`would on a system—Le. developing programs. writing 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 removing files since the remove program 'm’ was not on the PACL of
`the file being removed. The utility program proved useful. but it requires the user to team a new tool.
`
`The second kind of simulator test—software installation—was also generally successful. We
`attempted to install two large software systems. GNU Emacs [ll] 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 oflooking up the program name to see ifit 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 our initial designs a fixed sized space to
`store the PACL for each file.)
`
`Our PACL scheme is obvi0usly 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 scheme is that a vints could invoke other. more trusted
`programs to do its diny work. For example, a virus could send commands to infect files to 'vi'. One pos-
`sible solution to this problem would be for programs to impose restrictions 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 earlier, 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 hard or symbolic links. A hard link establishes another
`name for a file by having another directory entry point to the file '5 inode. A symbolic link is a file whose
`contents is a file name; when the symbolic link is opened, the kernel instead opens the contents of the
`link. Given such possibilities of multiple names for a given file. which name or names should be used in
`the PACL checks needs further study.
`
`Another issue related to naming is what to do when the name of a program changes. Since the
`PACL's store full pathnames of 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 number instead of its name. A sequence number w0uld 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 works fine.
`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.
`When a 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 of it 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 ‘right' solution
`can be determined.
`
`One possible objection to the entire PACL approach is that it requires future knowledge to 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 PACL lists set up so that the C compiler. say located in 'lbirt/cc', is allowed to create '.0' files.
`If an alternate C compiler such as GNU’s. say located in ‘lusrllocal/gcc', is added to the system. then the
`PACL’s for all ‘.0' 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 environment for a user to perform most tasks 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 set 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's is 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 each 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 titan the application specific (UNIX) approach dis-
`cussed here.
`
`Karger [8] and Boebert 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 the filesystem 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 us