`
`
`
`
`
`
`
`IDENTIFYING AND CONTROLLING
`
`UNDESIRABLE PROGRAM BEHAVIORS
`
`Maria. M. King“
`MKing©Dockmaster.ucsc.mil
`
`Abstract
`
`This paper describes a new mechanism for comparing selected program pmperties against a poljicy, or
`set of rules, that states allowable program behaviorftl, 10]. The motivation for this work is the increased
`need to control undesirable behaviors of programs, such as those inherent in Trojan horses and computer
`viruses. This mechanism, called an Automatic Policy Checker (APO), is currently implemented under
`SunOSl. This paper will discuss the design and implementation of the APO and the application of the
`APC to the aims problem. Conclusions concerning anti-viral policy in light of the test results will also
`be presented.
`
`Introduction
`
`The motivation for this work is the increased need for computer security mechanisms to control
`undesirable activity of programs, such as those caused by computer viruses[l], Trojan horses and other
`types of malicious logic.
`The major contribution of this work is an automatic tool, called an Automatic Policy Checker (APC),
`for comparing certain types of program behaviors against a. policy that states allowable program behav-
`iors. An important feature of the APC is that it does not implement any specific policy, clearly separating
`the policy from the mechanism Which enforces the policy[8}. Existing mechanisms either rely on the user
`to specify their own policyfl] or embed an ad hoc policy in the mechanism[5]. The APC allows exper—
`iments with policies intended to prohibit a variety of undesirable program behaviors. The APC does
`not rely on any new architectural support, has minimal e'fl'ect on performance, and does not require
`user knowledge of threat. Furthermore, if the APC is used in conjunction With a filter mechanism as
`described in [2, 6], reliance on some number of humans to act in a trustworthy manner, which is often
`required in many computer security mechanisms, is no longer needed.
`This paper first describes a formal language based on regular expressions that was developed 1501
`stating policia and certain types of program behaviors. A high-level overview of the design of the APC
`is described here while [10] provides a more detailed discussion. The APC has been applied to the
`computer virus problem. A study of anti—viral policies based on the viral property of file modification
`was conducted and is described in the section on policies. Experiments were run and the empirical data
`is discussed and results presented.
`
`High-Level Overview
`
`The idea is to explicitly state a system’s policy regarding allowable program activity. Subsequently,
`the APC is used to compare a selected program property against the policy, prior to installation. The
`APC determines whether a program’s specified actions fall within the perimeter of a particular policy.
`
`Definition 1 A policy is a set of rules that formally states allowable program behavior, in a particular
`system.
`
`'Formerly Maria M. Porno.
`1|31.11105 is a trademark of Sun Microsystems. Incorporated.
`
`233
`
`08-1020
`CS-1020
`Cisco Systems, Inc. v. Finjan, Inc.
`Cisco Systems, Inc. v. Finjan, Inc.
`
`
`
`
`
`
`
`
`
` Does the Program
`
`Figure 1: High-Level Overview
`
`The term specification when applied to programs is usually taken to mean a general statement
`of all of the functional and/or other relevant properties of a program. To distinguish this form
`of specification from the more general use, the term mini-spec is used.
`
`Definition 2 A mini-spec formally states a selected subset of the functional properties of a program’s
`behavior.
`
`This paper discusses the question: “Does the mini-spec conform to the policy?” Of equal
`concern is the correspondence between the mini-spec and the program it specifies. The scheme
`described in [2] proposes the use of a fitter that will analyze a binary program and ensure that
`it conforms to what is stated in the mini-spec (see Figure 1). Traditionally, such an analysis
`has proven to be diflicult. However, the assumption in [2] is that such programs should take full
`advantage of good software engineering techniques and need not contain the types of actions that
`are difficult to analyze, such as dynamic code generation, complicated computations for gener-
`ating object names, and operating system manipulations. The basic premise is that reasonably
`engineered programs will be analyzable[2]. A reasonably engineered program is one that at least
`uses a structured methodology, is modular, and is written in a higher-level language. Current
`research described in [6] has implemented a filter program such as the one proposed in [2]. The
`filter approach appears promising.
`An alternative method for verifying that the program conforms to the mini~spec is source code
`to specification correlation. The code-to-spec correlation process would have to be altered slightly
`since it is a one—to-one mapping between each line of code and each line of the specification. The
`mini-spec only states a subset of the program's behavior and such a mapping does not exist.
`However, verifying the source code against the mini-spec, as opposed to the binary, requires the
`existence of a trusted means for generating the binary from the source code. Without a trusted
`means, it would be possible to change the binary during the compilation stage.
`The scope of this work is the specification of the mini-spec, development of policy, and the
`conformance of the mini-spec to a policy. It is assumed that mechanisms exist for verifying a
`program against its mini—spec, as described above. It is further assumed that once a program is
`verified against its mini-spec, whether by a filter program or some other means, the program and
`
`284
`
`
`
`
`
`
`
`
`
`
`
`the associated mini-spec must be sealed or encapsulated in some way to prevent tampering. These
`issues are well understood and will not be addressed here. The APC accepts a program/mini—spec
`pair that has been verified and properly sealed. The next section discusses the language used for
`stating mini~specs and policies.
`
`A Regular Expression Based Specification Language
`
`This section discusses the formal language that was developed for writing mini-Specs and
`policies. The language is based on regular expression notation. The reasons for choosing regular
`expressions are presented in the next section. The syntax and use of the language is provided in
`Section , and the limitations of the language are discussed in Section .
`
`Why Regular Expressions?
`
`At the level of an applications program, a system resource might correspond to a file, device,
`block of memory, an so on. An applications program requests system services through system
`calls in which a system resource is referenced by a. human-readable name. A name translation
`mechanism converts the human-readable name to the actual page(s) on disk, memory location,
`etc. The name translation mechanism assumes that the supplier of the name being translated has
`appropriate access, leaving all access decisions to the access control mechanism, if one exists. The
`problem is that conventional access control mechanisms are concerned with the access between
`users and resources, no check is made concerning the access between programs and resources.
`The example provided in [5] shores how the Fortran compiler only needs access to xyz.for and
`xyz.obj but can easily gain access to login.corn if allowed by the access control mechanism.
`The APC controls the access between programs and system resources. The policy is a set
`of rules which states allowable program behavior. There is one rule for each type of operation
`under control. Each rule is a. set of human-readable names of system resources accessible to that
`operation. For example, the “modification rule” might be a set of names of directories where
`modification is permitted on the system. A mini-spec is also a set of rules, one for each type
`of operation that must be controlled in the particular system. Thus, a program’s “modification
`rule” would be the set of human—readable names of system resources that the program might
`attempt to modify.
`The notion of regular expressions has long been used in the design of lexical analyzers for
`grouping variable names and other tokens[4]. Other uses for regular expressions include text
`editors, pattern matching programs, and various file-searching programs. Regular expressions
`are well-suited for representing a set of strings such as the set of resource names, attribute
`names, or system call names that can be manipulated by a program.
`For ease of discussion, the remainder of this paper will discuss policies and mini-specs that
`have only one rule, i.e., control a single operation. It is a simple matter to extend these ideas to
`multiple rules.
`
`Discussion
`
`Au alphabet, 2}, is a finite set of symbols. A (formal) language, denoted L, is a set of strings
`of symbols from a particular alphabet. The language 2“ is the set of all strings over a particular
`alphabet 2; thus all languages L over 2 are a subset of E‘. A regular expression, r, is a way of
`describing these languages. The notation L(r) denotes the language described by I".
`Let r,- be the regular expression that denotes the mini-spec for a particular operation of
`program i. The set of strings denoted by r; is a finite-state language over some alphabet E. The
`language specified by r,- is denoted as
`
`LO?)
`
`(1)
`
`Let p be the regular expression that denotes the policy, and L(p) is the language denoted by 1?.
`Determining if the mini-spec for a given program is acceptable according to the policy of a specific
`
`285
`
`
`
`system then becomes a matter of determining if the language represented by the program’s mini-
`spec is a subset of the language denoted by the policy, for each individual rule. More formally,
`if
`
`LI”) 9 5(9)
`
`(2)
`
`for each corresponding rule in the policy, then the mini-spec is acceptable according to the system’s
`policy.
`Theoretically, the answer to equation 2 is straightforward. Ultimately, we want to be able to compare
`the two regular expressions without having to elucidate each element in the languages denoted by the
`expressions. To show that this can be done, consider the following properties of regular expressions.
`
`1. First, the languages denoted by regular expressions are precisely those languages accepted byfi-
`nite automata; so L{r.-) and L(p) are accepted by deterministic finite automata M (rs) and Maw),
`respectively[4, 9}. The class of languages denoted by regular expressions is closed under complemen-
`tation, i.e., the complement of a language denoted by a regular expression is also a language that
`can be denoted by a regular expression. To show this, let M = (Q, E, 6,qo, F)2 be a deterministic
`finite automaton (DFA). Let L be the language over 2 accepted by M; so L g 2". Then, the
`complementary language, 2'
`-- L, is accepted by the DFA M' = (Q, E, 6, 9.), Q — F). In other
`words, M and M" are the same except that the final states are opposite.
`'
`
`2. Second, by definition the languages denoted by regular expressions are closed under union. There—
`fore, given that the class of languages denoted by regular expressions are closed under complemen-
`tation and union, it is simple to show that they are also closed under intersection. Let L1 and L2
`
`be languages over the alphabet 2. Then L1 A L: = I: U E.
`
`Returning to equation 2, to answer the question, consider the following equation:
`
`(3' - £00) A L30) = 0 '
`
`(3)
`
`If the
`Consider the language that is the complement of the language denoted by the policy.
`language denoted by the program’s mini-spec, L(r,-), has anything in common with the comple-
`mentary language of the policy, 2" — L.(p], then clearly, L(r,-) is not a subset of L(p).
`Although it can be shown theoretically that two regular expressions can be directly compared
`to determine if one is a subset of the other, algorithmically the problem is considered PSPACE—
`complete[3]. Solutions to many PSPACE-complete problems exist, and in fact, these algorithms
`work well when certain constraints are applied. The APC currently implements one such algo-
`rithm. The primary constraint is that the regular expressions that denote the mini-spec and the
`policy, must be simple enough to be processed during a reasonable processing cycle. For regular
`expressions that do not meet this constraint, two alternatives are available. A detailed discussion
`of the algorithm, and these alternatives is provided in [10].
`
`Language Syntax and Usage
`
`Table 1 identifies the basic operators of the language. The precedence is listed from highest to
`lowest with the loop operator having the highest precedence. Parenthesis are used to override the
`normal precedence order as the example in Table 1 shows. The first four operators listed, loop,
`concatenation, union, and parenthesis for grouping, are standard regular expression operators.
`Note, however, that the loop operator indicates 0 S 1' where 1' is limited by the maximum string
`length on a particular machine. Thus, the expression 6‘ denotes a finite language, which differs
`from the standard definition.
`
`Nonterminal definitions provide user-friendliness by allowing a user to define commonly used
`expressions. Nonterminal definition names are 1—8 characters in length, all small letters;
`the
`definition itself is written in the operators of the language. Nonterminal definitions can be
`referenced via the angle brackets (< >) operator and can be embedded. The depth of macro
`definitions is machine dependent but it is wise to keep a limit on it. Nonterminal definitions are
`
`2Virtue?! Q is the set of all states in the DFA, I: is the input alphabet, 5 represents the transition function, on is the initial
`state, F is the set offinal states, and 90.}? Q Q44, 9]
`
`286
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Table l: Syntax of Lan__uae
`SYMBOL MEANING
`EXAMPLE
`
`c, a, so, can,
`
`concatenate
`
`union
`grouping
`
`nonterminal
`definition
`
`nonterminsl
`reference (1)
`series (2)
`current working
`directory
`home directory
`define expression
`
`Notes:
`
`a I 5 => a U 5; {a,b}
`(a I
`it)it => {s,b,as,ab,ba,lab,...}
`a | 5* ::r {s,t,bb,bbb,...}
`id ::= [a I b)*
`
`<id>=> (s I b)*
`
`[a I t I c...]
`{cwd}/{a | 6) => {cwdfmcwdfl}
`
`{home}(a | 5) => {home/a,home/b}
`files ::= (id)
`
`
`
`(1) Nonterminals are 1-8 characters, all small letters.
`(2] Series can be used with nonterminal definitions.
`
`stored in files; example nontermiual definition files, called sysdefs and unixdefs, are shown in
`Figure 2. A file of nonterminal definitions can be referenced via the “#include” mechanism of
`Unix. The square brackets operator ([ ]) is used to define a long series such as all the lowercase
`letters or all the digits. This operator is an implementation enhancement; parenthesis or nothing
`canbeusedtorepresentthesamething,i.e.,(a | b | c) E a I b I c E [a | b | c]. An
`improvement to the current language would be to allow [a — z] to indicate all the lowercase
`letters.
`
`The current working directory operator {cwd} and the home directory operator {home} can
`be used in systems that have knowledge about filesystem location, such as Unix or Multics. In a
`Unix system, for example, all directories in the system would include {cwd]/, {home}/, and all
`other directory locations.
`Policies and mini-specs are stored in files. Figure 2 shows the mini-spec for the modification
`operation for the calendar program. The last line of a mini-spec or policy file must begin with
`the “files” operator followed by the defines or goes into (::=) symbol as shown in the example in
`Figure 2. The example shows that the calendar program can create files in the current working
`directory of the form “cal” followed by a string as defined in the unixdefs nonterminal file. The
`grammar for the language just described is provided in [10].
`
`Writ'Eg Policies and Mini-Specs for Real Programs
`
`A mini-spec is written either during program development by a user wishing to submit a
`program for installation or it can be written for programs that already exist. Detailed information
`must be available in order to write a mini—spec for an existing program. This information might
`include source code, detailed design documentation, programmers notes, and test results.
`Writing a policy requires knowledge about the particular threat, the system vulnerabilities,
`and the desired environment. Although some users may have the sophistication for writing a
`policy, in most cases the policy should be written by a security officer or other security personnel.
`Section discusses the application of the APC to the virus problem, the development of anti-viral
`policy, and presents results of using the APC to test for undesirable program behavior (in this
`case viral behavior) in 125 Unix programs.
`
`28'?
`
`
`
`
`
`
`
`
`
`
`
`[alblmlz]
`[AIBImIZ]
`[0|ll...
`
`[! | / |
`
`| +]
`
`unixdecl's:
`
`atom
`string
`dir
`
`::
`::
`::_
`
`(<sn1all> | (large) I <digit> I (special>)
`<atom><aton1>'t
`/{<string>/)'
`
`I tmp/ca1<string> | std(err | out)
`
`“mini-spec” for calendar:
`
`#include “sysdefs”
`#include “unixdefs”
`
`files
`
`::
`
`Figure 2: Example Nonterminal Definitions
`
`The Language Preprocessor
`
`The APC first calls a preprocessor to resolve the “#include” statements, and to check the
`syntax of the mini-spec and the policy. The preprocessor enforces the rule that'all expressions
`must denote a regular language (all expressions must be regular). Regular languages with an
`infinite number of strings are represented by the “at” operator in the regular expression or a cycle
`in the Finite State Machine. Non-regular languages do exist and cannot be represented by these
`constructs. For example, a language such as the one denoted by {11" : n is prime} has no simple
`periodicity, is not regular, and cannot. be represented by the constructs of regular languages[9].
`The preprocessor enforces this rule by making sure that all referenced nonterrninal definitions
`have been defined before they are referenced. A. nonterrninal is not defined until after the carriage
`return, prohibiting expressions of the form: (foo) ::= a I (foo). This forces the use of the “an”
`operator for all loops and is sufficient to enforce that all expressions denote regular languages
`The preprocessor, part of the APC, provides an error message and the line number in the file
`where the error occurred, when a syntax error, such as the one just described, is encountered.
`
`Evaluation of the Lanflage
`
`The language for writing policies and mini-specs is based on regular expressions, which is a
`commonly accepted notation for representing a name space. It is a straightforward matter to
`use the language to represent the names of system resources manipulated by programs, such as
`file and device names, file attributes, environment variables, and system call names. Another
`application would be to encode behavior patterns in a regular expression, such as user profiles,
`using the constructs of the language.
`The primary drawback to this language is that the expressions must be kept simple enough to
`be processed by the APC during a reasonable processing cycle- A “reasonable processing cycle”
`will be specific to a particular installation depending on the price, in processing time, one wishes
`to pay for protection from viruses. This requires some knowledge about regular expressions on
`the part of the individual writing the mini—spec or policy. In some cases, the mini-spec may have
`to be broken down into several pieces or simplified according to regular expression transformation
`rules.
`
`288
`
`
`
`Using the APC
`The APC command is as follows:
`
`ape name-1 [name2] [-Idir...]
`name! is the name of the file that contains the mini-spec; name? is the name of the file that
`contains the policy. If name2 is not supplied, the default is the system policy.
`
`-Id'ir “#include” files are sought first in the current working directory, then in the directories named in
`the «1 options.
`
`When the policy is not supplied by the user a default system policy can be used. This allows
`a user to test out the mini-spec against an individual policy before submitting it to the system
`administrator for installation. It also allows the user to have an individual policy that is more
`stringent than the system policy. For example, suppose the system policy allows modifying of
`any files in any user directory. If a user does not wish to allow modification of the home directory,
`then the user can write an individual policy that only allows modifications to files not in the
`user’s home directory. The user can then use the APC, supplying the user-specific policy, when
`deciding whether to execute new programs. The APC returns a message indicating whether or
`not the program is acceptable according to the policy.
`
`Application of the APC to the Virus Problem
`
`This section discusses the application of the APC to the virus problem. All experiments were
`conducted under SunOS. The distinguishing characteristic of a computer virus is its ability to
`infect other programs by modifying them to include a copy of the virus. Although there are
`other behaviors of programs that can be controlled to prohibit viral activity, all of the policies
`discussed here focus on the modification operation, specifically, the modification of files and
`directories. All of the policies contain a single rule which specifies the directory and file names
`where modification is allowed. All of the mini-specs also contain one rule which specifies the
`directory and file names that the associated program could attempt to modify.
`Test Suite
`
`All of the programs in sections 1 £5 6 of the Unix Reference Manual[l l] were examined for
`possible inclusion in the test suites. These programs include editors, compilers, game programs,
`printing programs, and other basic utility programs available to normal users. The modification
`behavior of each program were studied by reading the Unix manual pages, looking at source code
`when available, and talking with Unix developers when necessary. In some cases, the modification
`activity of a program could not be adequately identified due to the lack of sufficient information.
`Such programs could not be included in the test suite. A total of 125 programs comprise the test
`suite.
`
`Many of the programs in the test suite had the same modification behavior. A total of
`twenty-three unique mini-specs were written to represent the 125 programs in the test suite.
`Three additional mini—specs were written to simulate programs infected with a real virus. The
`reason for including “infected” programs was to show whether each policy prevented infected
`programs from being accepted. All twenty~six mini-specs were tested against each identified
`policy. The details of the program study, the mini-specs, and the programs they represent, are
`presented in detail in [10].
`Policies
`
`The development of the anti-viral poiicies was approached from opposite angles. On the
`one hand, normal user activity was identified and several policies were developed to allow that
`behavior. On the other hand, several viruses were identified and policies were written to prohibit
`their behavior. The basic methodology was to develop policies that allowed normal user behavior
`and prohibited abnormal (viral) behavior.
`
`3A]! of the programs in these sections of the manual are available to normal users. For purposes of these experiufmntsI
`pronoun which require special privileges were not considered.
`
`289
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Policies for Normsl User Activity
`
`The first policy considered is a loose policy that allows modification to any directory and
`any file on the system. The reason for including such a policy is to show the operation of the
`system with respect to viruses when no restriction is piaced on allowable modification activity.
`This policy is comparable to no policy and all programs in the test suite, including the three
`“infected” programs, were accepted. At the opposite end of the spectrum of policies is a tight
`policy that only allows modifications to the standard output and standard error devices. This
`policy is included to represent a policy that allows very little modification activity. A policy such
`as this effectively keeps all viruses out of the system, it does not accept any editors, compilers,
`or programs to manipulate files.
`'
`Policy 3 allows modification to files in specific directories: Nev]. Itmp/,{cwcl} or {home}
`This policy does not allow modifications to any other directory, nor does it allow modifications
`to any subdirectory of these directories- A total of 50% of the programs in the test suite, are
`accepted by this policy. More importantly, this policy successfully rejects all three “infected”
`programs. Policy 4 is more restrictive and only allows modifications to the current working
`directory; this does not include files in subdirectories of the current working directory. Only 42%
`of the programs in the test suite are accepted by this policy. All three “infected” programs are
`also rejected. Policy 5 is the opposite of policy 4 in that modifications are allow to any file located
`anywhere in the system except the current working directory. A total of 59% of programs in the
`test suite were accepted by policy 5, however, two of the “infected” programs were also accepted.
`Policy 6 is also very restrictive; this policy only allows modification to objects located in the
`temporary directory ftmpf. Although this policy correctly rejects the three infected programs,
`it only accepts programs 42% of the programs in the test suite.
`Of all the policies in this section, policy 3 which allows modifications to all four specific
`directories appears to he the best policy in that it accepts that largest percentage of programs.
`None of the policies accept any compilers or editors.
`
`Policies to Prevent Specific Viruses
`
`Four Unix viruses are identified in this section. The details of each virus are not presented
`for security reasons. Instead, each virus is described in terms of the name space of directories
`and/or files that it modifies.
`The Murray Unix Virus infects Unix shell programs. Murray looks for shell programs to infect
`in the user’s bin/ directory and the current working directory. Murray also creates and modifies
`several files in the current working directory that start with a “.”. Since shell programs are not
`identifiable by their name, the policy is written to prohibit any modifications to the user’s fbin/
`directory or current working directory (modifications to subdirectories of the current working
`directory are permitted). Furthermore, this policy only allows modification to files in the home
`directory that do not start with a “3’. Modifications to other files in other locations in the system
`are permitted. This policy accepts the same set of programs that were accepted by policy 5 - the
`policy that does not allow modification to the current working directory. Although this policy
`rejects the mini-spec “infected” with the Murray virus, the other two “infected" programs are
`accepted.
`To simulate the IBM Christmas Tree virus in a Unix environment, policy 8 was written. This
`virus is not technically a virus since it doesn’t copy itself to another program,
`i.e., the virus
`doesn’t infect other programs. Instead, this virus, or worm, sends a copy of itself to all of the
`electronic addresses of all the users listed in the victim’s address alias file- To stop the spread,
`policy 8 prohibits modification of the mail spool directories, the location where all outgoing mail
`is queued until it is sent out of the system. This policy accepts 61% of the programs in the test
`suite. However, it restricts the proper usage of the mail programs so that mail cannot be sent out
`of the system by anyone. Also, this policy does not. reject the other two “infected” mini-specs.
`The virus described in [I] is a general virus that searches for any executable file'and appends
`itself to the executabie. Since this virus can modify any file any where in the system, policy 9
`
`290
`
`
`
`Policy Name
`
`Programs
`Accepted
`
`Specs
`Programs
`Programs
`Accepted
`Represented Accepted
`
`
`n—m
`n—“u-a-
`313— 'c
`1,7,10—12,
`
`-“_—fln
`
`
`
`
`
`1-6,9,10,l2,"ml-n
`
`
`
`
`
`
`
`
`
`
`Table 2: Policy Acce tance Rate
`Mini—
`Total
`
`'7. of
`
`Infected
`
`
`
`
`
`"Km—“ma.“
`not
`1-7,9,10,12,
`'
`
`“mu-a-
`
`l-T,9-l2,
`14,15,
`
`76
`
`61%
`
`yes
`
`Anti»
`
`Anti-
`
`prohibits all modifications except to the devices. Such a policy is very restrictive and, although
`it successfully prohibits all viruses, it allows only 44% of programs.
`Policy 10 is intended to prohibit the Internet Worm. The Internet worm modified many
`things on the system. Most important were the sockets that it wrote to in order to transfer the
`worm from the host machine to the victim machine. The Worm used unnamed sockets which
`
`makes it impossible to use this scheme to prohibit writing to sockets. The worm also created
`files beginning with the letter “x” which it later deleted in an attempt to hide itself. Prohibiting
`modification to files whose name begins with the letter “3:” would halt the Internet worm but it
`would be a simple matter to re-write the Worm to use some other letter. Policy 10 does prohibit
`the “infected” mini-spec which represents a program that is carrying the Internet Worm and
`it accepts 56% of all useful programs. This policy also successfully rejects the other “infected”
`programs. However, this policy would be very simple to circumvent. A second generation of this
`virus could choose a different letter or randomly select a letter other than “x”. In this way the
`virus would be accepted by the policy.
`Policy 11 was deve10ped by using the union operator of the language and combining policies
`7, 8, 9, 3; 10. The reason for including such a policy is to experiment with a single policy for
`all viruses vs. a policy for each individual virus. This policy does successfully reject all three
`“infected” programs, but it only accepts 39% of all programs. Also, it is easy to see that this
`policy doesn’t prohibit all viruses, just those described here.
`
`Evaluation of Empirical Results
`
`Table 2 shows the acceptance rate for each policy just described. Column 1 identifies the
`policy by number, column 2 lists the number of the mini-specs that were accepted, column 3
`shows the total number of programs represented by the accepted mini-specs. Column 4 indicates
`the percentage of the 125 programs in the test suite that were accepted by each policy. The last
`column indicates if any of the “infected” mini—specs were accepted.
`Eleven total policies were identified: 6 policies allow normal user behavior while 5 policies
`prevent a specific virus(es). Policies 1, 5, 7, and 8 accepted one or more of the “infected” mini-
`specs; mini-specs that were included to represent programs infected with a virus. Policies 10
`8E 11 are considered weak policies as it would be very simple to create a virus to circumvent
`these policies. Policy 3, which allows modifications only to specific directories {Nev}. ftmpfi
`
`291
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`{cwd}, {homeD accepts the largest number of programs. In general, policies based on normal
`user behavior accept a larger percentage of programs, especially most necessary programs; those
`based on specific viruses are easily circumvented-
`None of the policies that are effective against viruses accept any editors, compilers, linkers,
`or other programs considered necessary for normal user operation. This leads to the conclusion
`that basing the policy on the modification behavior of programs, although an important activity
`to control for virus prevention, by itself is inadequate. There are two reasons for this. First,
`the nature of Unix programs is that they either modify only standard error and/or standard out
`(39% of programs in the test suite), or they modify any file in any directory (34% of programs
`in the test suite). This results in mini-specs that specify program behavior as “all or nothing?
`for 72% of the programs in the test suite. Clearly, this approach would be more effective if the
`modification characteristics of Unix programs were restricted. The question is: could this be
`done easily without a great deal of impact on users?
`The second reason is the unavailability of user input. This approach is a static, preventative
`mechanism, it is applied once, prior to program installation. The mini-spec attempts to capture
`the potential dynamic behavior of a program but because of its static nature, this results in
`many programs being rejected at installation time that could operate within the confines of the
`policy at run-time. For example, suppose the policy states that the only modifications allowed
`are to ftrnp/ and files can have any name as long as they do not begin with the letter “a”. If the
`mini-spec for a particular program modifies files of any name in [tmp/ the program would not be
`accepted for installation. If the mechanism were applied at run-ti