`
`
`
`
`
`
`
`IDENTIFYING AND CONTROLLING
`UNDESIRABLE PROGRAM BEHAVIORS
`
`Maria M. King*
`MKing@Dockmaster.ncsc.mil
`
`Abstract
`
`This paper describes a new mechanism for comparing selected program properties against a poljicy, or
`set of rules, that states allowable program behavior/2, 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 (APC), is currently implemented under
`SunOS'. This paper will discuss the design and implementation of the APC and the application of the
`APCto the virus 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[i], 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 implementany 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 policy[7] 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 effect 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 humansto act in a trustworthy manner, whichis 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 for
`stating policies 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 ts a set of rules that formally states allowable program behavior, in a particular
`system.
`
`*Formerly Maria M. Pozzo.
`1S$unOSis a trademark of Sun Microsystems, Incorporated.
`
`283
`
`Cs-1020
`CS-1020
`Cisco Systems, Inc. v. Finjan, Inc.
`Cisco Systems, Inc. v. Finjan, Inc.
`
`

`

`
`
`
`
`to the Policy?
`
`
`
`
`Does the Program
`Correspond to
`the Mini-Spec?
`
`Figure 1: High-Level Overview
`
`The term specification when applied to programsis 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-specis 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 ofafilter 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 bedifficult. However, the assumptionin [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 programswill 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 implementedafilter program such as the one proposed in [2]. The
`filter approach appears promising.
`An alternative methodfor verifying that the program conforms to the mini-spec is source code
`to specification correlation. The code-to-spec correlation process would haveto bealtered slightly
`since it is a one-to-one mapping between eachline of code and eachlineof 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 andwill 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 .
`
`WhyRegular Expressions?
`
`At the level of an applications program, a system resource might correspondtoafile, 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, memorylocation,
`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] shows how the Fortran compiler only needs access to xyz.for and
`xyz.obj but can easily gain access to login.com 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
`tule” 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 onerule, i.e., control a single operation. It is a simple matter to extend these ideas to
`multiple rules.
`
`
`
`
`
`Discussion
`
`An alphabet, ©, is a finite set of symbols. A (formal) language, denoted L,is a set of strings
`of symbols from a particular alphabet. The language =*is the set of all strings over a particular
`alphabet 5; thus all languages L over © are a subset of D*. A regular expression, r, is a way of
`describing these languages. The notation L(r) denotes the language described by r.
`Let r; be the regular expression that denotes the mini-spec for a particular operation of
`program i. Theset of strings denoted by7;is a finite-state language over some alphabet ©. The
`language specified by r; is denoted as
`
`(1)
`L(r;)
`Let p be the regular expression that denotes the policy, and L(p)is the language denoted byp.
`Determiningif the mini-specfor 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
`
`(2)
`L(ri) © L(p)
`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 by.fi-
`nite automata; so L(r;) and L(p) are accepted by deterministic finite automata M(r;) and M(p),
`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 showthis, let M = (Q,=,6,qo, F)? be a deterministic
`finite automaton (DFA). Let L be the language over L accepted by M; so L €
`L*. Then, the
`complementary language, &* — L, is accepted by the DFA M’ = (Q,5,6,90,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 [, and L
`be languages over the alphabet ©. Then Ji A Lo = Ty U Tp.
`Returning to equation 2, to answer the question, consider the following equation:
`
`(u* — Lip)) A Li(r) =O ©
`
`(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, 5* — 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 providedin [10].
`
`Language Syntax and Usage
`
`
`
`Table 1 identifies the basic operators of the language. The precedenceis 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. Thefirst four operators listed, loop,
`concatenation, union, and parenthesis for grouping, are standard regular expression operators.
`Note, however, that the loop operator indicates 0 < i whereiis limited by the maximum string
`length on a particular machine. Thus, the expression a* denotes a finite language, whichdiffers
`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 dependentbut it is wise to keep a limit on it. Nonterminal definitions are
`
`2Where Q is the set of all states in the DFA, © is the input alphabet, 6 represents the transition function, go is the initial
`state, F is the set of final states, and go, F C Q.[4, 9]
`
`
`
`286
`
`

`

`
`
`Table 1: Syntax of Language
`
`SYMBOL|MEANING EXAMPLE
`
`
`
`concatenate
`union
`grouping
`
`(2) Series can be used with nonterminal definitions.
`
`nonterminal
`definition
`nonterminal
`reference (1)
`fa |b | c..J
`series (2)
`current working|{cwd}/(a | 6) = {cwd/a,cwd/b}
`directory
`{home}(a | 6) = {home/a,home/b}
`homedirectory
`define expression|files ::= <id>
`
`(a | b)* => {a,65,aa, ab, ba, bb,...}
`a | b* => {a,b, bb, bbb, ...}
`id ::= (a | 6)*
`
`<id>=> (a | 6)*
`
`(1) Nonterminals are 1-8 characters, all small letters.
`
`stored in files; example nonterminal 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
`can be used to represent the same thing, ie., (a | 6 | c) = a |b | c = [a | 6 | 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 aboutfilesystem location, such as Unix or Multics. Ina
`Unix system, for example, all directories in the system would include {cwd}/, {home}/, andall
`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. Thelast 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 showsthat the calendar program cancreate 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].
`Writing Policies and Mini-Specs for Real Programs
`A mimi-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 developmentof 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.
`
`287
`
`
`
`
`
`

`

`
`
`
`
`
`
`
`
`sysdefs:
`
`small
`large
`digit
`special
`
`unixdefs:
`
`atom
`string
`dir
`
`{a]b|... | 2]
`:
`fA|B]... |Z]
`i
`(O|1]...[ 9]
`rr
`= E/L-14
`
`3
`ss
`fe
`
`(<small> | <large> | <digit> | <special>)
`<atom><atom>*
`/(<string>/)*
`
`/tmp/cal<string> | std(err| out)
`
`“mini-spec” for calendar:
`
`#include “sysdefs”
`#include “unixdefs”
`files
`
`i
`
`Figure 2: Example Nonterminal Definitions
`
`The Language Preprocessor
`
`The APCfirst calls a preprocessor to resolve the “#tinclude” 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 “+#” 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 {a” : 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 nonterminal definitions
`have been defined before they are referenced. A nonterminal is not defined until after the carriage
`return, prohibiting expressions of the form: <foo> ::= a|<foo>. This forces the use of the “+”
`operator for all loops andis sufficient to enforce that all expressions denote regular languages.
`The preprocessor, part of the APC, provides an error message and the line numberin thefile
`where the error occurred, when a syntax error, such as the one just described, is encountered.
`
`Evaluation of the Language
`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 downinto several pieces or simplified according to regular expression transformation
`rules.
`
`288
`
`

`

`Using the APC
`The APC commandis as follows:
`
`apc namel [name2] [-Idir...]
`namei is the name of the file that contains the mini-spec; name2 is the name ofthefile that
`contains the policy. If name2 is not supplied, the default is the system policy.
`-Idir “#Hinclude” files are sought first in the current working directory, then in the directories named in
`the -I options.
`
`When thepolicy 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
`anyfiles in any user directory. If a user does not wish to allow modification of the homedirectory,
`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 & 6 of the Unix Reference Manual[11] were examined for
`possible inclusion in the test suite?. 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 manualpages, looking at source code
`when available, and talking with Unix developers when necessary. In somecases, the modification
`activity of a program could not be adequately identified due to the lack of sufficient information.
`Such programs could not be includedin 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 policies 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.
`
`3 All of the programs in these sections of the manual are available to normal users. For purposes of these experiments,
`programs which require special privileges were not considered.
`
`289
`
`
`
`
`
`
`
`

`

`
`
`
`
`
`
`
`
`Policies for Normal 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 norestriction is placed 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 ofpolicies 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.
`/dev/, /tmp/,{cwd} or {home}
`Policy 3 allows modification to files in specific directories:
`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 includefiles 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 anyfile 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 /tmp/. 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 be 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 Virusinfects Unix shell programs. Murraylooks for shell programstoinfect
`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 /bin/
`directory or current working directory (modifications to subdirectories of the current working
`directory are permitted). Furthermore, this policy only allows modification tofiles in the home
`directory that do not start with a “.”. Modifications to otherfiles 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, ie., the virus
`doesn’t infect other programs. Instead, this virus, or worm, sends a copyofitself 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.
`Thevirus described in [1] is a general virus that searches for any executable fileand appends
`itself to the executable. Since this virus can modify any file any where in the system, policy 9
`
`290
`
`

`

`Table 2: Policy Acceptance Rate
`Infected
`%o of
`Mini-
`Total
`
`
`Specs Programs|ProgramsPrograms
`
`
`Accepted Represented|Accepted|Accepted
`
`
`Sea
`
`
`2Tent [38% [no_|
`Spe
`1,7,10-12,
`
`not
`
`1-7,9,10,12,
`
`
`
`
`tetes=a)
`
`
`
`
`
`
`aea[1]Anti-Murray[sameas5|
`pt[ae |e cic
`
`
`rteBeeewTw|e
`
`
`
`Anti-
`
`1-7,9-12,
`14,15,
`
`61%
`
`[9[Anti-Generic|__107,18_|
`Anti-
`1-6,9,10,12,
`
`[ii [Combo[iss88H
`
`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 hideitself. Prohibiting
`modification to files whose name begins with the letter “x” would halt the Internet worm butit
`would be a simple matter to re-write the worm to use some otherletter. Policy 10 does prohibit
`the “infected” mini-spec which represents a program that is carrying the Internet Worm and
`it accepts 56% ofall useful programs. This policy also successfully rejects the other “infected”
`programs. However, this policy would be very simple to circumvent. A second generation ofthis
`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 developed by using the union operator of the language and combining policies
`7, 8, 9, & 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 numberof 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 while5 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
`& 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 (/dev/, /tmp/,
`
`291
`
`
`
`
`
`

`

`
`
`
`
`
`
`
`
`{cwd}, {home}) 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.
`Noneofthe 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 anyfile 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 moreeffective 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 /tmp/ andfiles 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 namein /tmp/ the program would not be
`accepted for installation. If the mechanism were applied at run-time instead, the program might
`execute within the confines o