Server Security

Proceedings of the

14th Systems Administration Conference

(LISA 2000)

New Orleans, Louisiana, USA

December 3– 8, 2000

THE ADVANCED COMPUTING SYSTEMS ASSOCIATION

© 2000 by The USENIX AssociationAll Rights ReservedFor more information about the USENIX Association:Phone: 1 510 528 8649FAX: 1 510 548 5738Email: office@usenix.orgWWW: http://www.usenix.orgRights to individual papers remain with the author or the author's employer.

Permission is granted for noncommercial reproduction of the work for educational or research purposes.This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein.

SubDomain: Parsimonious

Server Security

Crispin Cowan, Steve Beattie, Greg Kroah-Hartman, Calton Pu, Perry Wagle and Virgil Gligor1

–WireX Communications, Inc.

ABSTRACT

Internet security incidents have shown that while network cryptography tools like SSL arevaluable to Internet service, the hard problem is to protect the server itself from attack. The hostsecurity problem is important because attackers know to attack the weakest link, which isvulnerable servers. The problem is hard because securing a server requires securing every piece ofsoftware on the server that the attacker can access, which can be a very large set of software for asophisticated server.Sophisticated security architectures that protect against this class of problemexist, but because they are either complex, expensive, or incompatible with existing applicationsoftware, most Internet server operators have not chosen to use them.

This paper presents SubDomain: an OS extension designed to provide sufficient security toprevent vulnerability rot in Internet server platforms, and yet simple enough to minimize theperformance, administrative, and implementation costs. SubDomain does this by providing aleastprivilegemechanism forprogramsrather than for users. By orienting itself to programs rather thanusers, SubDomain simplifies the security administrator’s task of securing the server.

This paper describes the problem space of securing Internet servers, and presents theSubDomain solution to this problem. Wedescribe the design, implementation, and operation ofSubDomain, and provide working examples and performance metrics for services such as HTTP,SMTP,POP,and DNS protected with SubDomain.

Introduction

Common server operating systems such asLinux, Windows, Solaris, etc.are subject to vulnera-bility rot as security vulnerabilities (i.e., implementa-tion bugs) are discovered in the component softwareof these operating systems. For instance, a buffer over-flow discovered in the BIND domain name server [15]allowed remote attackers to gain root privileges on avariety of system platforms, and a similar vulnerabil-ity in Microsoft’sIIS (web server) [21] allows remoteattackers to gain administrative control of Windowsservers. The recommended defense for general pur-pose servers is to keep the host system up to date withvendor patches to close these vulnerabilities.

However,many of these systems are beingpressed into use as the basis forserver appliances:servers intended for largely unattended operation byunskilled users. But because these operating systemsare subject to vulnerability rot, they need to be fre-quently upgraded with vendor patches. While this isan acceptable approach for general purpose servers(where a skilled system administrator is expected tomaintain the system) it is not acceptable to applianceusers, who expect a device with the maintenance fac-tor of a toaster.

1Cowan, Beattie, and Pu are formerly of the Oregon Grad-

uate Institute, where much of this work was done. Cowanand Beattie are now with WireX Communications, and Pu isnow with the Georgia Institute of Technology.Wagle is stillwith the Oregon Graduate Institute, and Gligor is with theUniversity of Maryland. Kroah-Hartman is with WireX.

The classical security solution to vulnerabilityrot is the notion ofleast privilege:the technique ofgranting subjects in a system precisely the capabilitiesthey need to perform their function, and no more [33].Effective use of least privilegeminimizesthe potentialdamage that results when a trusted program is pene-trated by minimizing the degree to which the programis trusted.

Security architectures that provide least privilegemechanisms exist, but because they are either com-plex, expensive, or incompatible with existing applica-tion software, appliance vendors have not chosen touse them. Existing defenses entail these complexitiesprecisely because they were designed to handle thegenerality of a general purpose server,and thus mustdeal with user least privilege. This generality compli-cates the least privilege abstraction, making theenforcement mechanism more complex to implementand use.

This paper present SubDomain: an OS extensiondesigned to provide sufficient security to prevent vul-nerability rot in server appliances, and yet simplify asmuch as possible to minimize the performance,administrative, and implementation costs. SubDomaindoes this by providing a least privilege mechanism forprogramsrather than forusers.The security restric-tionscomplementthe system’sexisting permissions,allowing a program to be secured independent of whomay be using the program. This notion is especiallyeffective on server appliances, and enables program-specific confinement information to be distributed

355

2000 LISA XIV – December 3-8, 2000 – New Orleans, LA

SubDomain: Parsimonious Server Securitywith the program(see the section on SubDomain com-patibility).

By specifically addressing least privilege for pro-grams, we can provide a mechanism that has a rela-tively small implementation and simple operation.Small implementations are important for security sys-tems to avoid vulnerabilities due to bugs in theenforcement mechanism itself.Simple operation isimportant for security systems to avoid misconfigura-tion. Even more so than in most OS design issues, par-simony is critical to security [33] making SubDo-main’srelative simplicity of design and implementa-tion an important feature.

We present the SubDomain notation for recur-sively specifying the sub-domain of resources avail-able to a software component, our implementation ofSubDomain as an enhancement to the Linux kernel,our application of SubDomain confinement to severalexample applications, performance metrics on the costof SubDomain confinement, and our analysis of thesecurity of a system protected by SubDomain.

The challenge of supporting least privilege is toprovide a specification system that is expressiveenough to specify privileges that are actually minimal,is convenient enough that administrators can reason-ably specify least privileges, and yet preserves com-patibility and performance. While SubDomain strivesfor simplicity relative to other least privilege mecha-nisms, it provides for finer granularity least privilegein one important regard: SubDomain can confinearbi-trarysoftware components, at a finer granularity thanthe native OS process, i.e., procedures and modules.This is especially important for component-based ser-vices such as Apache [9] and its loadable modules (seethe section on confinement).

The rest of this paper is organized as follows.The next elaborates on the problem of vulnera-ble/buggy software, and describes the abstract solutionofleast privilegeto minimize the potential damagedue to attacks against vulnerable software. Readersfamiliar with least privilege can skip ahead to the thirdsection, which describes the SubDomain securityenhancement, and how it advances over previous leastprivilege mechanisms by providing finer granularity,and simplifying the problem of confining suspectpro-grams.The fourth demonstrates SubDomain’scom-patibility by confining assorted software components,includingsub-process modules.The fifth section pre-sents the performance costs of SubDomain confine-ment. The subsequent section 6 describes related workspecifically addressing the problem of confining sus-pect programs. The final section presents our conclu-sions.

The Problem: Vulnerable Programs and Least

PrivilegeMany security vulnerabilities result from bugs in‘‘trusted’’programs. A‘‘trusted program’’isa356

Cowan, et al.

program that runs with privilege that some attackerwould like to have, and the program fails to keep thattrust if there is a bug in the program that allows theattacker to acquire that privilege. Some examplesinclude:

Buffer Overflows:Many privileged programs con-tain ‘‘buffer overflow’’vulnerabilities, a prob-lem endemic to C programs that provide poorbounds checking on user-supplied input. Bufferoverflows are very common [18, 19] and verydangerous [32, 29], allowing attackers to takecontrol of programs from an anonymous nodeon the internet.

Race Conditions:Many privileged programs also

contain ‘‘race condition’’vulnerabilities. Here,the problem is that careless root privileged pro-cesses create files without adequate checkingfor the prior existence of the file. The problemis that the attacker can create a symbolic orhard link in the file system between the time theprivileged program checks for existence and thetime it creates the file, with the result that theroot program unwittingly uses its authority tocorrupt some other critical file [12].

Special Character Processing:While few root

privileged programs are written in shell script-ing languages, many other programs with‘‘interesting’’privileges are written as shellscripts, especially CGI/ PERL [41] programsfor processing web forms. CGI programs runwith the authority of the web server,and mustprocess arbitrary input from arbitrary users. Ifthe attacker can provide input (using creativeURLs) to a CGI program that yields control tothe attacker,then the attacker can gain controlof the web server,e.g., the PHF program(included in early NCSA and Apache webservers) allowed the attacker to present a URLto the web server that would cause PHF to startanxtermon the attacker’s display [14].

Note that while ‘‘trusted’’usually refers to highlyprivileged processes (e.g., root processes) they canactually be processes withanyprivileges that theattacker wants but does not have. The general case isthat any program installed on a computer that pro-cesses input from potentially hostile users becomes apotential vulnerability.Eliminating these vulnerabili-ties requires some form of assurance that the programin question does not contain exploitable bugs, but thiskind of assurance is problematic. Some classes ofbugs, e.g., buffer overflow vulnerabilities, can beeliminated through various compiler techniques [39,17, 26, 37]. Other forms of vulnerabilities are unde-tectable at compile time, e.g., race conditions [12] andgeneral logic errors.

The only way to assure the complete absence ofasecurity vulnerability in a program is through expen-sive manual verification. In the absence of such verifi-cation, one must either suffer the risk of potential vul-nerabilities, orcontainthe potential damage. Note that2000LISA XIV – December 3-8, 2000 – New Orleans, LA

Cowan, et al.

the activities we seek to constrain are ‘‘those thatcause damage to the system,’’i.e.,safety properties[1] with respect tointegrity.Weare not addressingother security issues, such asinformation flows[27]that might disclose secrets. Readers already familiarwith least privilege mechanisms can skip to to the nextsection for a description of SubDomain, our contribu-tion to the field.

The Solution: Least Privilege

The classic solution to the problem of unknownsecurity vulnerabilities is to perform each activity withtheleast privilegerequired to complete that task [33].While this does not stop exploitation of these vulnera-bilities, it does contain the damage as much as possi-ble. An attacker who gets control of a least privilegeprocess can, at most, read secrets and corrupt data thatthe exploited process has access to, and no more.

The challenge of supporting least privilege is toprovide a sufficientlyfine-grainedmechanism to spec-ify privileges that are actually minimal, while also pre-serving compatibility and performance. It is conceptu-ally simple to divide system privileges into fine-grained units and then attribute the exact requiredprivileges to a given activity,but the result of such anapproach is specification notation that is tedious tomaintain (breaking compatibility) and an enforcementmechanism that is slow (breaking performance).

Practical least privilege therefore involvesabstracting the system resources to expedite least priv-ilege specifications. Matching least privilege abstrac-tions to native OS resources in turn enables efficientleast privilege enforcement. Least privilege is also auseful notion in managinguserprivileges, leadingmany systems to combine least privilege for users andprograms into a single mechanism, as described in thenext subsection.

However,ifthe problem is bugs in programs thatcan be accessed by completely untrusted users, thenuser-oriented least privilege mechanisms may becomeawkward or inadequately expressive. The section onusers and rolls describes some more elegantapproaches to using user privilege mechanisms to con-fine suspect programs. The third section discussesSubDomain, our OS security enhancement that partic-ularly address the problem of least privilege for pro-grams, and a penultimate section discusses relatedwork specifically aimed at program confinement.Using User Privileges to Confine Programs

Least privilege for users is a classic way of struc-turing a system, and many operating systems providefacilities for constraining the privileges of a givenuser.User-oriented least privilege facilities can beadapted to confining collection of programs by creat-ing asyntheticuser,and then running the program asthat user.

The classic example is the UNIX setuid facility:thesetuidbit for an executable file indicates that theprogram runs with the privilege of the owner of the2000 LISA XIV – December 3-8, 2000 – New Orleans, LA

SubDomain: Parsimonious Server Security

file instead of the privilege of the invoking user.Oftenthis is used to createsetuid rootprograms that providecontrolled access to protected resources by expandingthe privileges the program runs with to be all of root’sprivileges. Touse setuid to confine a program to asmaller set of resources, a new synthetic user can becreated that has those privileges, e.g.,nobody.Pro-grams can then be madesetuid nobodyto confine theiractions to a small set of privileges.

One limitation to this approach is that all user-IDs, even synthetic user-IDs, can access all files onthe system that permit ‘‘other ’’accesses. Another lim-itation to this approach is that only root can create newuser-IDs. The result is that normal users cannot con-struct ad hoc ‘‘sandboxes’’for programs that they maychoose to install and run. Users are then left with theirchoice of:

•beg the system administrator to create a newuser-ID for them,

•do not install software that is not trusted,

•run untrusted software without protection, noneof which is very appealing.

So in principle, synthetic user-IDs and thesetuidmechanism can support least privilege for programs,but in practice it forces root to do all the work. There-fore this technique is rarely deployed, people run un-trustworthy software with much more privilege than isnecessary,and suffer the consequent security risks.Users and Roles

Because synthesizing user-IDs is awkward, thenotion of aroleemerged. A role is a collection ofrelated privileges [2]. In 1986, Bobert and Kain intro-duced the notion oftype enforcement:objects (files)are assigned totypes,subjects (processes) are assignedto domains, and tables determine which domains haveaccess to which types. Badger et al expanded on thisnotion [7, 8]. In a similar vein,role-based access con-trol(RBAC) [22, 34] assigns users to roles, and thengrants privileges to the roles.

Similar to thesetuidapproach described previ-ously,roles can be pressed into service confining pro-grams to a least privilege set of resources by assumingaspecific role just prior to executing the program.While using roles to confine programs is more elegantthan synthesizing user-IDs, it is still fundamentallyoverloading a user-oriented access control mechanismto manage software defects. In the next section, wedescribe our mechanism to specifically address theproblem of vulnerable software.

SubDomain Security: Recursive Component Con-finementSubDomain is a kernel extension designedspecifically to provide least privilege confinement tosuspect programs. SubDomain allows the administra-tor to specify thedomainof activities the program canperform by listing the files the program may access,and the operations the program may perform.

357

SubDomain: Parsimonious Server SecuritySubDomain restrictionscomplementthe native accesscontrols, in that SubDomain neverexpandsthe set offiles a program may access, i.e., any file access mustpass the native access controls and the SubDomainrestrictions before access is granted. Thus SubDomainconfinement makes a program monotonically safer torun.

The next subsection describes the SubDomainnotation and semantics.Then, the subsequent subsec-tion explains how SubDomain leverages work in safeprogramming models likeproof-carrying code[30] toachieve component confinement below the granularityof a native process.The final subsection describes theSubDomain implementation.

SubDomain Notation & Semantics

Figure 1 shows a trivial SubDomain specifica-tion, in which thefooprogram is given read access tothe /etc/readme file, write access to the /etc/writemefile, and execute access to the /usr/bin/bar file. Whenever the program foo is run, by any user,itisrestrictedto access these specified files with these modes. Sub-Domain profiles can also grant access to directoriesthrough simple globbing, i.e., the profile in Figure 1grants the foo program to all files in /mydir.

foo {

/etc/readme /etc/writeme /usr/bin/bar /mydir/* }

rwxr,,,,

Cowan, et al.

Sub-components may also want a SubDomainthat is completely unrelated to the parent domain. Forexample, a web server application might need to sendsome e-mail while processing a web form, and thusinvokes a mail delivery agent whose SubDomain iscompletely different. Wesupport this need withabso-lute subdomains,denoted by a subdomain specifica-tion following anxwithout a+or a-.Figure 3 showsan example absolute subdomain in which the bar pro-gram run from the foo program has access to a com-pletely different subdomain than the foo program.

foo {

/etc/readme r,/etc/writeme w,/usr/bin/bar x{

/usr/lib/otherread r,/var/opt/otherwrite w,},}

Figure3:Absolute SubDomain.

When a confined process tries to perform a file opera-tion that is not permitted, two things happen:

1. Thesyscall returns with the error EPERM, justas if the attempt had failed due to a standardUNIX file system permission error.

2. Thekernel generates a syslog entry describingthe attempted violation.Intrusion detectionsystems can thus collect what ever informationthey want, and act accordingly,e.g., kill theoffending process if such drastic steps aredesired.

Sub-process Confinement

The section on related work describes severalother systems that provide program-confinementmechanisms. However,with the exception of Java [4]the smallest component that they can confine is anative OS process. In contrast, SubDomain providesthe unique feature of being able to confine compo-nents that are only a portion of an OS process. Histori-cally of little practical interest, the need for sub-pro-cess confinement comes from the rise in popularity ofscriptable servers and loadable modules.Let usexpand upon these concepts.

A‘‘scriptable server’’ isaserver program that,from time to time, interprets a script or a programwithin itself, i.e., server-side includes [5], PHP webpages [6], Java servlets [3], etc. Such scripts are legiti-mately sub-component programs requiring separateconfinement. Scriptable servers often have their ownsecurity mechanisms, but in depending on suchrestrictions, we are depending on application correct-ness, which is the dependence we seek to avoid in thefirst place. Wewould rather have a confinement mech-anism that can be enforced by the operating system sothat we do not depend on the correctness of the serverapplication.

‘‘Loadable modules’’or‘‘plug-ins’’isthe notionof providing a (fairly) fixed API in an application so2000LISA XIV – December 3-8, 2000 – New Orleans, LA

Figure1:Trivial subDomain.

foo {

/etc/readme /etc/writeme /usr/bin/bar /usr/bin/baz }

rwxx

,,

+{/etc/otherwrite w} ,-{/etc/writeme w},

Figure2:Relative SubDomain

Thex(execute) capability is of particular impor-tance: what restrictions should apply to the child pro-cess? By default, the child process inherits the parent’s

SubDomain, preventing the confined program from‘‘escaping’’its confinement by executing an unre-stricted child process.However,sub-components ofan application may require different capability setsthan the application as a whole. For instance, gamesonly need strong privileges to initialize video con-trollers, and mail delivery agents only need strongprivileges to actually write to a user’s mail box. Thuschild programs can be given different constraints byspecifying arelative subdomain,denoted by axfol-lowed by a+or-followed by a SubDomain specifica-tion. Forexample, Figure 2 shows a SubDomain forfoo that says that when the sub-component bar is run,it canalsohave write permission to the /etc/otherwritefile. Conversely,itsays that when foo runs the sub-componentbaz,itmay not write to the /etc/writemefile.358

Cowan, et al.

that extensions to can be loaded into the application,either at start-time or run-time. ‘‘Plug-in’’isthe com-mon term for desktop applications (i.e., Netscape Nav-igator & Shockwave, Microsoft Word and EndNote)while ‘‘module’’isthe common term for servers (e.g.,Apache andmod_perl).

Themod_perlmodule for Apache provides a per-fect example of the sub-process problem.PERLscripts run at the behest of the Apache web server arenormally interpreted by starting a separate process torun the PERL interpreter,and then interpreting thePERL script in that separate process.mod_perlloads aPERL interpreter directly into the Apache process toavoid the cost of starting the PERL interpreter process.While this is good for server throughput, it is bad forsecurity:

•Bugs inmod_perlcan crash the Apache webserver process.

•Program-confinement mechanisms that onlyoperate on OS processes cannot confine scriptsinterpreted bymod_perlseparate from theApache web server process.

The SubDomain solution to the ‘‘scripting &module’’problem is to provide for subdomains forsub-process components, in cooperation with theenclosing application. The notation for a sub-processsubdomain is unchanged from that of separate-processsubdomains shown in Figure 1 through Figure 3. Theeffect is to create a variety of ‘‘hats’’that process canwear,one for each sub-process component that it calls.The ‘‘cooperation’’required from the enclosing pro-gram is that it should call the newchange_hat() systemcall before calling the sub-process component.

The requirement to callchange_hat() implies thatwe are once again trusting the application, which Sub-Domain is supposed to avoid.However,weare trust-ing the application code a great dealless,inthat theapplication only has to make appropriate calls tochange_hat(), which is much simpler than constructingand enforcing an effective ‘‘sandbox’’environment[20]. Successfully callingchange_hat() with the nameof a sub-component before calling the sub-componentseems easy enough to do correctly.

In addition to the requirement that enclosingapplication correctly callschange_hat(), we alsorequire that the sub-component doesnotcallchange_hat() to escape to a more liberal subdomain.Here, we employ acookieargument tochange_hat() toprevent the confined module from escaping. The con-taining process initially callschange_hat() with a par-ticular cookie value, and furtherchange_hat() calls thatdo not provide a matching cookie argument are treatedas security violations.

Thus for the containing process to prevent sub-component from escaping from thechange_hat() Sub-Domain, it need only provide a cookie value that thecontained sub-component cannot easily guess. Werec-ommend fetching a word from /dev/random, but anyreasonable source of entropy can be used.

2000 LISA XIV – December 3-8, 2000 – New Orleans, LA

SubDomain: Parsimonious Server Security

The security of this method depends on the sub-componentnotbeing able to read the parent process’scookie value. Here, SubDomain can leverage thepower oflanguage-based security protection systemssuch as proof-carrying code [30], strong type checking[39, 26, 37], and other language-based protectionschemes [24, 40]. Such methods can, in principle,provethat the sub-component will not invoke thechange_hat() system call.

Programming language techniques provide pow-erful protection, but also impose significant practicalconstraints, not the least of which is that the sub-com-ponent needs to be written in a particular language. Inpractice, we can still get reasonable assurance that thesub-component cannot read the containing process’scookie value if it is written in a scripting language,i.e., a language that isinterpretedrather than one com-piling to native CPU instructions. In the practical set-ting of scripts for web servers, most such programsthat are executed by loadable modules are scriptinglanguages, e.g., PERL [41], PHP [6], and Java [3].While noformalassurances are available, in practice itis easy to trust, say,mod_perlto not address randommemory.

To see the power of this approach, consider thechronic problem of securely supporting Microsoft’s‘‘Front Page Extensions,’’acollection of non-standardHTML tags that the server interprets to provide moredynamic HTML content. Microsoft provides amod_fpApache module and collection of helper programs, butthey have a poor security history [36]. There is no cur-rent practical method to securely supportmod_fp.

SubDomain can solve themod_fpproblem bytreating web pages containing ‘‘Front Page Exten-sions’’tags as sub-components, and assigning eachsuch page to a subdomain. So long as themod_fpmod-ule can be trusted not to call thechange_hat() systemcall, then no errant action ofmod_fpcan violate thesecurity policy of the subdomain for the page it isinterpreting.

SubDomain Implementation

The basic architecture of SubDomain is shown inFigure 4. The SubDomain policy engine is imple-mented as a Linux [38] loadable kernel module.Fol-lowing the usual UNIX permissions checking, the rel-evant system calls (open(),exec(),read(), etc.) aremodified to check if the calling process is a confinedprocess. If so, the request is referred to the SubDo-main module for further inspection. The SubDomainmodule then either returns normally (if the request ispermitted) or returns an EPERM error (if the request isdenied).

Once loaded, the SubDomain module disablesmodule unloading to prevent tampering with the Sub-Domain policy engine. A user-level parser reads sub-domain profiles from /etc/subdomain.d/* to convertthe textual representation of profiles into kernel datastructures, and inserts the updated profiles into the

359

SubDomain: Parsimonious Server Securitykernel via asysctl() interface. By convention, the/etc/subdomain.d/foo file would confine the foo pro-gram, but as shown previously,the actual name of theconfined program is in the file, so confining multiplecomponents with a single file is possible. Only rootprocesses can access this kernel interface, and SubDo-main-confined programs may notaccessthe profileinterface. In future work we will add further authenti-cation requirements to the kernel’sprofile interface.SubDomain Parsimony

SubDomain is simpler than competing least priv-ilege mechanisms described in the section on relatedwork in both implementation and usage. With regardto implementation, the SubDomain module and kernelpatches amount to 4500 lines of C code, and the non-kernel parser is 825 lines. In contrast, the DTE kernelenhancement [7, 8] is over 40,000 lines of code. Therelatively simple semantics of SubDomain enable asmaller implementation. ‘‘Smaller ’’isimportant forsecurity systems, where correctness is critical, becausebugs are approximately liner in code size.

SubDomain’susage is simpler than its competi-tors in that it is easier to devise and inspect SubDo-main confinement profile than in other systems, whichwe elaborate on in the next section.

SubDomain Compatibility

We test the compatibility of SubDomain byputting it to work confining a variety of software com-ponents common to Internet servers, both large andsmall. SubDomain can confine binary-only programs,so long as there is no need for sub-process confine-ment. If sub-process confinement is required, then theprogram source needs to be edited and re-compiled toinsert appropriate calls tochange_hat().

Like the ‘‘synthetic user’’ approach mentionedearlier,SubDomain confinement requires administra-tor intervention. However,SubDomain confinement iseasier for the administrator in the following ways:Ease of Application:A SubDomain profile does

not interfere with any other aspects of the sys-tem except the SubDomain mechanism. Thus it

Cowan, et al.

is easy to install a SubDomain profile alongwith the confined program. In particular,because the SubDomain profile is independentof the system the program is being installed on,the profile can beincludedwith the programbeing distributed. In contrast, it is difficult toinclude a synthetic user in conventional pro-gram packages (e.g., tar balls or RPMpackages).2

•It is easy for the administrator to inspect a Sub-Domain specification to determine the preciseaspects of the system that are exposed to thatprogram. In contrast, the exposure entailed by asynthetic user is non-obvious: the administratormust consider all files that are accessible to‘‘anybody,’’which is a non-trivial exercise onnon-trivial file systems.

The Kernel Wrapper approach [23] provides forconfinement scripts that are full Turing-equiva-lent programs. While this provides extensiveflexibility,italso means that the completenessand safety of an inserted kernel wrapper is notamenable to automatic analysis. In contrast,SubDomain profiles are easy to inspect todetermine the security implications of updatingaSubDomain profile. Furthermore, it isstrictlysafe to install a SubDomain profile where noneexisted before, because SubDomain strictlylimits program privileges.

These factors have important implications forsoftware distribution.Because SubDomain confine-ment profiles are system independent and guaranteedto be safe to install, it becomes feasible to packageSubDomain confinementwith the program itself.Thusan end user can consider installing a new program onaserver appliance, and because of the SubDomainconfinement information packaged with the program,the user can understand the security implications ofinstalling that program. In future work, we plan to

2Note that bundling synthetic user IDs is exactly the ap-

proach taken by qmail [11], which results in excellent se-curity for qmail, but also imposes substantial packagingdifficulties that have hampered qmail’sspread.

/etc/subdomain.d/*textParserdata structuressysctl()File accessrequestse.g. open(),read()KernelNormalaccess controlsRejectSubDomainModuleAcceptFigure4:SubDomain implementation

360 2000LISA XIV – December 3-8, 2000 – New Orleans, LA

Cowan, et al.

develop future tools that will assist the administratorin determining the security implications of a set ofSubDomain confinements

Which programs need to be confined with Sub-Domain depends on the convenience and securityneeds of the host system, and thus is an adjustable pol-icy.The administrator can specify which of the fol-lowing classes of programs must be confined withSubDomain before they are allowed to execute at all:All Programs:All programs that execute on the

host must be associated with a SubDomain,either explicitly,orinherited from a SubDo-mained parent program. This mode is suitablefor bastion hosts.

All Listed User-IDs:All programs running under

one of the user-IDs specified by the administra-tor must be associated with a SubDomain. Forinstance, the httpd user-ID runs many programson behalf of the web server,and SubDomainconfinement ensures that these programs willnot affect other parts of the system. This modeis suitable for confining a potentially vulnerablecollection of services on a system that alsohosts critical data.

All root Programs:All programs running with a

real or effective user-ID of ‘‘root.’’This modeallows a SubDomain profile to be used toachieve the classic goal of breaking up root’sall-too-powerful privileges. The (defunct)POSIX 1.e ‘‘capabilities’’model subdividedroot’spowers into a static set of 32 separategroups of ‘‘capabilities’’, and individual pro-grams could assume part of root’spowers byflipping on one or more of these sets of capabil-ities. SubDomain allows arbitrary sets of privi-leges to be grouped together,rather than accept-ing the groupings specified by POSIX 1.e.

Only Specified Programs:Only the programs that

have a SubDomain specified are thus confined,i.e., ‘‘default allow.’’This mode assumes thatall programs on the host are adequately securedexceptfor the programs being SubDomained.While not especially secure, this mode is con-venient, e.g., for use on a client workstation torun a suspect program recently downloadedfrom the Internet.

The procedure for confining a program is to startwith a null subdomain specification, run the applica-tion, observe the system log for complaints aboutattempts to access files outside the subdomain, andthen add those files to the subdomain specification.This procedure is presently manual, because due con-sideration is required for two stages in this procedure:Running the application:The application needs to

be run under all of the ‘‘kinds’’ofinput that itis expected to experience in a production envi-ronment, i.e., a comprehensive test suite. Deter-mining these inputs requires some knowledge2000 LISA XIV – December 3-8, 2000 – New Orleans, LA

SubDomain: Parsimonious Server Security

of the application to ensure complete coverage.Failure to provide complete coverage results inasubdomain that is too ‘‘tight’’, and the appli-cation will occasionally fail to access resourcesthat it needs.

Granting the privilege:We are confining the appli-cation precisely because we donottrust it, andtherefore we cannot automatically assume thatevery file the application tries to access undertest is a legitimate file for the program toaccess. The file should be included in the sub-domain only after due consideration of thesecurity implications.

For applications where source code is available, pre-dicting the set of required resources should be feasi-ble. If anticipating the set of files an application needsto access is truly difficult, then it is quite likely thatthe application represents a significant security threat,and should not be installed on hosts requiring security.

For applications where source code is not avail-able, a run-time testing methodology must be used toexperimentally identify all of the file resources that aprogram may try to access. Tofacilitate this, we usethedepprogram that we developed for the InDepen-dence project [16] (funded by a student grant fromUSENIX). This program usesstrace() to monitor theexecution of a subject program, and amasses a list ofall the files accessed.dep’s use ofstrace() imposesheavier performance and compatibility overhead thanSubDomain, but is none the less sufficient for explor-ing the file system domain of many programs. Tofur-ther ease use,depaccumulates files accessed acrossmultiple runs, so that a large test suite can be applied,and then the list of files accessed inspected once at theend of testing.

/home/httpd/cgi-bin/Count.cgi {/etc/ld.so.cache /lib/lib*

/lib/ld-linux.so.2 /etc/nsswitch.conf /etc/wwwcounter.conf /etc/localtime

/var/log/httpd/wwwcount/wwwcount_log /var/lib/wwwcount/*

/var/lib/wwwcount/data/* }

r,r,r,r,r,r,rw,r,rw,

Figure5:SubDomain for wwwcount CGI scriptAn example subdomain profile is shown in Fig-ure 5, providing all of the resources needed to run thewwwcount CGI program (a popular web page hitcounter program). Note the use of simple globbing toreduce the size of the subdomain specification whenaccess to an entire directory is required. Figure 6shows a more elaborate profile for the Apache webserver itself, under a particular configuration. A list ofsome of the programs that we have confined andtested, along with the size of their subdomains, arelisted in Table 1.

361

SubDomain: Parsimonious Server Security

/usr/local/apache/bin/httpd {/r/dev/null rw/dev/urandom r/etc/group r/etc/hosts r/etc/host.conf r/etc/ld.so.cache r/etc/localtime r/etc/nsswitch.conf r/etc/passwd r/etc/resolv.conf r/home/httpd/perl/* r/lib/* r/usr r/usr/lib/gconv/ISO8859-1.so r/usr/lib/gconv/gconv-modules r/usr/lib/perl5/5.00503/* r/usr/lib/perl5/site_perl/5.005/i386-linux/* r/usr/local r/usr/local/apache r/usr/local/apache/conf/* r/usr/local/apache/htdocs/* r/usr/local/apache/logs* wl/usr/share/locale/en_US/* r/usr/share/locale/locale.alias r}

Cowan, et al.

system call as a baseline for comparison against thechange_hat() system call, asget_pid() is commonlyregarded as the simplest system call.

As expected, he major overhead appears in theopen(),exec() andchange_hat() system calls, whereSubDomain is checking the action against the subdo-main specification for the confined process.Program Simplebashshell scriptPHF CGI programCGI Mail programhtsearchCGI programwwwcountCGI programApacheweb serverlpdlpqlpcPostfixMail Delivery AgentPostfix-script helper programSizeof SubDomain31 files14 files7files11 files10 files33 files16 files10 files11 files15 files65 files,,,,,,,,,,,,,,,,,,,,,,,,,

Figure6:SubDomain for Apache Web Server.

SubDomain Performance

Here we present a variety of SubDomain perfor-mance measurements. The next section describes ourmicrobenchmarks on mediated system calls, and thesection after that describes our macrobenchmarks on aconfined PERL script interpreted by themod_perlApache module.Microbenchmarks

Here we use the usual benchmarking techniqueto measure affected system calls by crafting programsthat issue each system call 10,000 times, run the pro-grams several times, discard the first run to avoid coldcache effects, and average the remainder.All testswere performed on a dual-processor Pentium III 700MHz, with 256 MB of RAM. Table 2 summarizesthese results. Weinclude measurement of theget_pid()

System Call

fork() exec() open()

get_pid() vs.change_hat()

Standard Cost29513873.711.81

Table 1:SubDomain-confined programs.Macrobenchmarks

Our macrobenchmark is SubDomain confine-ment of a PERL script to be executed via themod_perlApache module, thus exercising SubDomain’scapa-bility to confineactive contentscripts. Toexercise theweb server’s cache, we replicated the PERL script1000 times, and used the Webstone performancebenchmark to measure the overhead cost of PERLscripted web pages protected with SubDomain vs.without protection. The PERL script itself reads twofiles with some busy-work in between, simulating ascript that fetches a ‘‘container ’’template from onefile, HTML content from another file, and does someinterim processing to merge the two, e.g., compute aSubDomain Cost295 1487 5.39 4.70

%Overhead0%7%45%159%

Table 2:SubDomain Microbenchmarks in microseconds.

/perl/0/cgitest-001.cgi {

/usr/lib/perl5/site_perl/5.005/i386-linux/Apache/Registry.pm /etc/localtime

/usr/lib/perl5/5.00503/*

/home/httpd/perl/0/cgitest-001.cgi

/home/httpd/perl/0/cgitemplate-001.html /home/httpd/perl/0/cgidata-001 /var/log/httpd/* }

rrrrrrw

Figure7:Test PERL script’sSubDomain profile.

362 2000LISA XIV – December 3-8, 2000 – New Orleans, LA

Cowan, et al.

hit counter.The SubDomain profile for this script isshown in Figure 7.

The test environment used the same dual-proces-sor Pentium III 700 MHz server with 256 MB ofRAM, and a private network (crossover cable) via 100Mbit ethernet.

The test results are shown in Table 3, measuredfor 5 to 10 concurrent client connections. Tests wererun twice, and the results averaged. For all cases, theSubDomain overhead is between 1% and 2%, i.e., inthe noise range.

Related Work

Here we describe work that, similar to SubDo-main, specifically attacks the problem of confiningsuspect programs. Despite the age of the notion ofleast privilege [33], much of this work has emergedrelatively recently.Itisour conjecture that this is aresult of a shift in emphasis from defending secrecy(the dominant concern for military organizations) todefendingintegrity(the dominant concern for Inter-net-connected businesses) and the emergence of thenotion ofsurvivability[35]. This list of related work isnecessarily partial, as the total body of related work isvery large.TRON

The TRON system [10] is a kernel enhancementfor ULTRIX that can confine a program’sexecution to

TestStandard SubDomain %OverheadStandard SubDomain %OverheadStandard SubDomain %OverheadStandard SubDomain %OverheadStandard SubDomain %OverheadStandard SubDomain %Overhead

#ofConnection Clients Rate

5

5667788991010

75.97 75.19 1% 78.14 76.56 2% 78.38 77.24 1.45% 78.26 76.71 2% 78.24 77.02 1.6% 78.43 77.07 1.7%

SubDomain: Parsimonious Server Security

aprotection domain consisting of a finite set ofcapa-bilitiesin the form of file names. TRON adds thetron_fork() system call, which functions exactly likethe classic fork() system call, except that it specifiesthe protection domain as an extra argument. TRON issemantically most similar to SubDomain: the protec-tion domains are the same (sets of files) and are simi-larly applied to host programs, orthogonal to user priv-ileges. The major differences are:

•TRON is discretionary,while SubDomain ismandatory.TRON provides user commands torun programs in a confined domain, while Sub-Domain always runs a specified program in aconfined domain. Thus in the usual DAC vs.MAC trade-off, TRON is more convenient forindividual users, while SubDomain is moreconvenient for securing entire systems, e.g.,server appliances.

•TRON’sfinest granularity is the ULTRIX pro-cess; it cannot confine loadable modules.Janus

Janus [25] is a user-level mechanism for confin-ing programs to a specific set of resources. Intended toconfine ‘‘helper ’’applications run from within a Webbrowser,Janus uses theptrace() system call and amonitoring process to mediate all system calls madeby the helper application. If the action proposed by thehelper application violates a policy set by the user,then the monitoring process rejects the request. ThisAvg. ResponseTime (ms)

66.566.50%77781.3%8990.51.7%1021042%115 116.5 1.3%127129.52%

Avg. ClientThroughput

26.2926.021%27.0426.492%27.1326.731.5%27.0826.542%27.0826.661.6%27.1526.671.7%

Table 3:SubDomain macrobenchmarks with WebStone.

2000 LISA XIV – December 3-8, 2000 – New Orleans, LA363

SubDomain: Parsimonious Server Securityapproach requires four system calls to be executed toeffect one confined system call.Java 2 Security

The Java 2 security model [4] allows the JVM tobe configured to assign particular capabilities to desig-nated Javaclasses,similar to the SubDomain notion ofassigning file system capabilities to programs.This isan enrichment over the original Java security model[26] which assigned one fixed set of capabilities toremotely-loaded applets (almost nothing), and anotherfixed set of capabilities to locally-loaded applets(almost everything).

The Java 2 security mechanism is notable as theonly system other than SubDomain capable of confin-ing sub-process components, in that Java classes aretypically smaller than the host OS processes. Natu-rally,the Java 2 security model does not apply to non-Java native executables.chrootJail

Thechroot() system call3makes the argumentdirectory be the effective root directory,i.e., ‘‘/’’forthe invoking process. The point of this operation isthat the file system domain for the affected process isnow limited to the contents of the argument directory.Any files that the application needs to access must beplaced inside thechrootdirectory,orthe access willfail.

Thechroottechnique is a popular form of con-finement, in large part because standard kernels (e.g.,Linux) support it. However,chroothas defects in allthree of the dimensions a security enhancement shouldaddress:

Security:chrootjails are resistant to oblivious

attempts to escape the jail, i.e., attempts toaccess files that are not accessible within thejail. However,ifthe attacker can execute theirown code within thechrootjail, it is fairly easyto break the jail and access outside files. Thusjailed programs generally cannot be trustedwith strong privileges, i.e., it is insecure todepend on chroot to confine a root process.Compatibility:Eachchroot’d program must have

the necessary components of the file systemreplicated within its jail, which is problematic ifthe program requires access to a large, complexset of files, i.e., shell scripts need all invokedprograms replicated into thechrootjail. Thussetting up a chroot jail can be a lot of tedious,complex work. The chroot technique alsobreaks programs that need to interact with otherparts of the system.

Performance:Becausechrootjails require duplica-tion of all resources needed by the jailed pro-gram (soft or hard links could be used as escaperoutes) they consume excessive disk space andfile system buffer cache space.

3‘‘man chroot’’

Cowan, et al.

Type Enforcement

The type enforcement work [13, 7, 8] hasrecently been extended to provide better support forprogram confinement.Kernel hypervisors[28] pro-vide a facility for installing small state machines thatintercept kernel system calls and enforce a securitypolicy.Such a facility can be viewed as a tool thatcould be used to build a SubDomain-like least privi-lege system. Fraiser,Badger and Feldman provide asimilar tool for building security policy enforcementautomata [23]. SubDomain provides the following keyadvantages over this technique:

Parsimony:SubDomain is much simpler than the

TE and DTE implementations; the SubDomainkernel code is approximately 1/10 the size ofthe DTE kernel patch. Simplicity is critical insecurity systems.

Safety:The DTE Wrapper system [23] allows code

to be inserted into the operating system to per-form mediation. While this is a powerful tech-nique, it is also dangerous:maliciousDTEwrapper code could just as easily be inserted. Incontrast, SubDomain profiles are easy toinspect to determine the security implicationsof updating a SubDomain profile. Furthermore,it isstrictlysafe to install a SubDomain profilewhere none existed before, because SubDomainstrictly limits program privileges.4Application-Specific Mechanisms

Various application environments provide theirown least privilege-like mechanisms. For instance, thePERL interpreter includes a facility known as ‘‘taint’’,in which input provided to the PERL scriptcannotbeused to formulate an action (i.e., system() operation)unless it has been ‘‘adequately’’inspected by thePERL script [41]. PERL also includes a ‘‘safe PERL’’facility,where in the programmer can specify a set ofPERL operators that the script may not use.

Another application-specific least privilegemechanism is the notion of ‘‘wrappers.’’For example,CGI Wrappers [31] causes a CGI script to be run withthe user-ID of the script owner,rather than the user-IDof the web server.Combined with the synthetic user-ID notion described previously,CGI Wrappers canconstruct a least privilege environment for CGIscripts.

PACLs: Program-based Access Control Lists

We believe PACLs [42] to be the first instance ofan access control system based on the program per-forming the operation. The PACL system is the exactdual of the SubDomain notion: files have an accesscontrol list that enumerates programs that are permit-ted to operate on that file. A simulated PACL systemwas built and evaluated, but an actual PACL systemwas never finished.

4This observation due to Blaine Burnham.

onmost UNIX Systems

364 2000LISA XIV – December 3-8, 2000 – New Orleans, LA

Cowan, et al.

Status & Availability

The implementation is not complete with respectto the description in this paper.

•The absolute and relative sub-domainsdescribed earlier are not complete: child pro-cesses either inherit the parent’sprofile, or usetheir own profile if one is specified.

•The multiple modes of requiring SubDomainconfinement described previously is only par-tially implemented. The implementation cur-rently supports ‘‘paranoid’’mode where all pro-cesses must have SubDomain confinement, and‘‘open’’mode, where only the programs thatare specified are confined by SubDomain.

SubDomain is implemented for Linux, and is availablefrom http://immunix.org.The kernel enhancementportion is licensed under the GPL, and the non-kernelportions are proprietary to WireX but available forfree for non-commercial use.

Conclusions

Vulnerable software is a major security problem,mandating constant system administrator attention tokeep systems up to date with vendor-supplied securitypatches. This is especially problematic for complexInternet servers, which are required to provide exten-sive services to anyone on the Internet. Some form ofconfinement mechanism to approximate least privilegeis the generic solution, but often imposes more coststhan administrators deploying in ‘‘internet time’’canbear.Our SubDomain confinement mechanismadvances over previous confinement work, simplify-ing both implementation and administration overheadsby confiningprogramsinstead ofusers.

This approach enables SubDomain confinementto be packaged with programs, in contrast with con-finement mechanisms that are bound to the system.SubDomain also provides fine-grained protection,confining software componentsfinerthan the host OSprocess, providing the unique capability to protectpotentially vulnerable servermodulessuch asMicrosoft’sFront Page Extensions to the Apache webserver.Wehave implemented and tested the system,showing that it provides all three essential propertiesof a security enhancement: enhanced security,soft-ware compatibility,and preserved performance.

Author Information

Dr.Crispin Cowan is co-founder and ChiefResearch Scientist of WireX Communications, Inc.,and is a Research Assistant Professor at the OregonGraduate Institute, where he teaches graduate coursesin system security.His research focuses on makingexisting systems more secure without breaking com-patibility or compromising performance. ProfessorCowan has authored 28 refereed publications, includ-ing those describing the StackGuard compiler fordefending against buffer overflow attacks.Reach himelectronically at crispin@wirex.com.

2000 LISA XIV – December 3-8, 2000 – New Orleans, LA

SubDomain: Parsimonious Server Security

Steve Beattie is one of the original developersand the current maintainer of the StackGuard compilerenhancement. He is employed in the Advanced R&DGroup at WireX Communications, Inc., who gra-ciously pays him to work on such fun projects asStackGuard and SubDomain. He received a MastersDegree in Computer Science from the Oregon Gradu-ate Institute, and was previously employed as a Jack-of-all-Trades Sysadmin in a Large Dead-Tree Publish-ing Corporation.

Calton Pu received his Ph.D .from University ofWashington in 1986 and served on the faculty ofColumbia University and Oregon Graduate Institute.Currently,heisholding the position of Professor andJohn P.Imlay,Jr. Chair in Software at the College ofComputing, Georgia Institute of Technology.Heisleading the Infosphere project that combines hisresearch interests. First, he has been working on next-generation operating system kernels to achieve highperformance, adaptiveness, security,and modularity,using program specialization, software feedback, anddomain-specific languages. This area has includedprojects such as Synthetix, Immunix, Microlanguages,and Microfeedback, applied to distributed multimediaand system survivability.Second, he has been workingon new data and transaction management by extendingdatabase technology.This area has included projectssuch as Epsilon Serializability,Reflective TransactionFramework, and Continual Queries over the Internet.He has published more than 30 journal papers andbook chapters, 100 conference and refereed workshoppapers, and served on more than 40 program commit-tees. Heis currently an associate editor of IEEETKDE, DAPD, and IJODL.

Greg Kroah-Hartman is one of the main LinuxUSB developers, and the current Linux USB Serialand USB Bluetooth driver maintainer.Heisalso theauthor and maintainer of the Linux usbview programwhich is being shipped in most of the major Linux dis-tributions. His free software is being used by morepeople than any closed source projects he has everbeen paid to develop. He is currently employed in theAdvanced R&D group at WireX Communications Inc,and has a Bachelors Degree in Computer Science.

Perry Wagle received his MS in Computer Sci-ence at Indiana University in 1995, and in 1997 heheaded to the Oregon Graduate Institute to join theImmunix project’ssurvivability research, whereamong other things, he was was the primary program-mer of the StackGuard enhancement to GCC.Ratherthan go with WireX like the rest of Immunix last year,he stayed at OGI to work on the Infosphere project.He is interested in applying programming languagetechnology to operating systems problems. For exam-ple, survivability presents an interesting problem: howeffectively can you transform or assist legacy codethat is intolerate to security faults so that it respondssensibly to attacks?

365

SubDomain: Parsimonious Server SecurityVirgil D. Gligor received his B.Sc., M.Sc., andPh.D. degrees from the University of California atBerkeley.Hehas been at the University of Marylandsince 1976, and is currently a Professor of Electricaland Computer Engineering. He has worked in theareas of acces control on several UNIX systems an isthe co-designer of two automated tools, one forcovert-channel analysis of (C language) source code(written in PROLOG), and the other for penetrationanalysis, which have been used by IBM Corporationfor analysis of Secure Xenix and for TIS Inc TrustedXenix. His work helped define precisely the notion ofthe denial of service, and received the Best ResearchPaper Award at the 1988 IEEE Symposium onResearch in Security and Privacy for research work inthis area (paper co-authored with his graduate studentC.F.Yu). Heis the co-author of several US patents inthe areas of intrusion detection, penetration analysismethods and tools, and role-based access control.

References

[1] Alpern,Bowen and Fred B. Schneider,‘‘Defin-ing Liveness,’’Information Processing Letters,21(4):181-185, 1985.

[2] Amoroso,Edward,Fundamentals of ComputerSecurity Technology,Prentice Hall, EnglewoodCliffs, NJ, 1994.

[3] Anonymous,The Java Web Server ArchitectureOverview,http://www.javasoft.com/products/java-server/documentation/webserver1.1/ ,1997.

[4] Anonymous,JDK 1.2 Security,http://java.sun.com/products/jdk/1.2/docs/guide/security/index.html ,March 1998.

[5] Assorted,NCSA HTTPd Tutorial: Server SideIncludes,http://hoohoo.ncsa.uiuc.edu/docs/tutorials/includes.html .

[6] Assorted,PHP Hypertext Processor,http://php3.org/ .

[7] L.Badger,D.F.Sterne, et al., ‘‘Practical Domainand Type Enforcement for UNIX,’’Proceedingsof the IEEE Symposium on Security and Privacy,Oakland, CA, May 1995.

[8] LeeBadger,Daniel F.Sterne, David L. Sherman,Kenneth M. Walker,and Sheila A. Haghighat,‘‘ADomain and Type Enforcement UNIX Proto-type,’’Proceedings of the USENIX Security Con-ference,1995.

[9] BrianBehlendorf, Roy T.Fielding, Rob Hartill,David Robinson, CliffSkolnick, Randy Terbush,Robert S. Thau, and Andrew Wilson,ApacheHTTP Server Project,http://www.apache.org.[10] AndrewBerman, Virgil Bourassa, and Erik Sel-berg, ‘‘TRON: Process-Specific File Protectionfor the UNIX Operating System,’’Proceedingsof the 1995 Winter USENIX Conference,USENIX Association, 1995.

[11] D.J. Bernstein,qmail,http://cr.yp.to/qmail.html ,

1990.366

Cowan, et al.

[12] M.Bishop and M. Digler,‘‘Checking for Race

Conditions in File Accesses,’’Computing Sys-tems,9(2):131-152, http://olympus.cs.ucdavis.edu/bishop/scriv/index.html ,Spring 1996.

[13] W.E.Bobert and R. Y.Kain, ‘‘A Practical Alter-native to Hierarchical Integrity Policies,’’Pro-ceedings of the 8th National Computer SecurityConference,Gaithersburg, MD, 1985.

[14] CERT,Advisory CA-96.06: Vulnerability in

NCSA/Apache CGI Example Code,ftp://info.cert.org/pub/cert_advisories/CA-96.06.cgi_example_code ,September 1996.

[15] CERT,Advisory CA-98.05: Multiple Vulnerabilities

in BIND,ftp://info.cert.org/pub/cert_advisories/CA-98.05.bind_problems ,May 1998.

[16] CrispinCowan, Ryan Finnin Day,and Hao Zhao,

InDependence: Automating the Discovery ofApplication Dependencies,http://www.cse.ogi.edu/DISC/projects/independence, 1997.

[17] CrispinCowan, Calton Pu, Dave Maier,Heather

Hinton, Peat Bakke, Steve Beattie, Aaron Grier,Perry Wagle, and Qian Zhang, ‘‘StackGuard:Automatic Adaptive Detection and Prevention ofBuffer-Overflow Attacks,’’7th USENIX SecurityConference,pages 63-77, San Antonio, TX, Jan-uary 1998.

[18] CrispinCowan, Perry Wagle, Calton Pu, Steve

Beattie, and Jonathan Walpole, ‘‘Buffer Over-flows: Attacks and Defenses for the Vulnerabil-ity of the Decade,’’DARPAInformation Surviv-ability Conference and Expo (DISCEX),January2000; Also presented as an invited talk at SANS2000, Orlando, FL, http://schafercorp-ballston.com/discex ,March 23-26, 2000.

[19] MicheleCrabb, ‘‘Curmudgeon’sExecutive Sum-mary,’’The SANS Network Security Digest,Michele Crabb, editor,Contributing Editors:Matt Bishop, Gene Spafford, Steve Bellovin,Gene Schultz, Rob Kolstad, Marcus Ranum,Dorothy Denning, Dan Geer,Peter Neumann,Peter Galvin, David Harley,Jean Chouanard,SANS, 1997.

[20] DrewDean, Edward W.Felten, and Dan S. Wal-lach, ‘‘Java Security: From HotJava to Netscapeand Beyond,’’Proceedings of the IEEE Sympo-sium on Security and Privacy,Oakland, CA,http://www.cs.princeton.edu/sip/pub/secure96.html ,1996.

[21] eEye,IIS Remote Hole,http://www.eye.com/

database/advisories/ad06081999/ad06081999.html ,June 1999.

[22] DavidF. Ferraiolo and Richard Kuhn, ‘‘Role-Based Access Control,’’Proceedings of the 15thNational Computer Security Conference, Balti-more,MD, October 1992.

[23] Tim Fraser,Lee Badger,and Mark Feldman,

‘‘Hardening COTS Software with Generic Soft-ware Wrappers,’’Proceedings of the IEEE2000LISA XIV – December 3-8, 2000 – New Orleans, LA

Cowan, et al.

Symposium on Security and Privacy,Oakland,CA, May 1999.

[24] NealGlew and Greg Morrisett, ‘‘Type-Safe

Linking and Modular Assembly Language,’’Twenty-Sixth ACM SIGPLAN-SIGACT Sympo-sium on Principles of Programming Languages,pages 250-261, San Antonio, TX, http://www.cs.cornell.edu/talc/papers.html ,January 1999.[25] IanGoldberg, David Wagner,Randi Thomas,

and Eric Brewer,‘‘A Secure Environment forUntrusted Helper Applications,’’6th USENIXSecurity Conference,San Jose, CA, July 1996.[26] JamesGosling and Henry McGilton, ‘‘The Java

Language Environment: A White Paper,’’http://www.javasoft.com/docs/white/langenv/, May 1996.[27] J.A. McLean, ‘‘A General Theory of the Com-position for Trace Sets Closed Under SelectiveInterleaving Functions,’’Proceedings of theIEEE Symposium on Security and Privacy,pages79-93, Oakland, CA, May 1994.

[28] Terrance Mitchem, Raymond Lu, and Richard

O’Brien, ‘‘Using Kernel Hypervisors to SecureApplications,’’Proceedings of the Annual Com-puter Security Application Conference,Decem-ber 1997.

[29] Mudge,How to Write Buffer Overflows,http://

l0pht.com/advisories/bufero.html, 1997.

[30] George C. Necula and Peter Lee, ‘‘Safe Kernel

Extensions Without Run-Time Checking,’’Pro-ceedings of the USENIX 2nd Symposium on OSDesign and Implementation (OSDI’96),http://www.usenix.org/publications/library/proceedings/osdi96/necula.html ,1996.

[31] NathanNeulinger,CGIWrap: User CGI Access,

http://www.unixtools.org/cgiwrap/ ,1997.

[32] AlephOne, ‘‘Smashing The Stack For Fun And

Profit,’’Phrack,7(49), November 1996.

[33] JeromeH. Saltzer and Michael D. Schroeder,

‘‘The Protection of Information in ComputerSystems,’’Proceedings of the IEEE,63(9),November 1975.

[34] R.S. Sandhu, E. J. Coyne, H. L. Feinstein, and

C. E. Youman, ‘‘Role Based Access ControlModels,’’IEEE Computer,pages 38-47, Febru-ary 1996.

[35] HowieShrobe,ARPATech ’96 Information Sur-vivability Briefing,http://www.darpa.mil/ito/ARPAT ech96_Briefs/survivability/survive_brief.html ,May 1996.

[36] MarcSlemko,Microsoft FrontPage 98 Security

Hell,http://www.worldgate.com/marcs/fp/ ,October1997.

[37] RobertE. Strom and Shaula Alexander Yemini,

‘‘Typestate: A Programming Language Conceptfor Enhancing Software Reliability,’’IEEETransactions on SoftwareEngineering,12(1):157-171, January 1986.

[38] LinusTorvalds, et al.,Linux Operating System,

http://www.linux.org/ .2000 LISA XIV – December 3-8, 2000 – New Orleans, LA

SubDomain: Parsimonious Server Security

[39] UnitedStates Department of Defense,Reference

Manual for the Ada Programming LanguageANSI/MIL-STD-1815A-1983,United StatesDepartment of Defense, February 1983.

[40] RobertWahbe, Steven Lucco, Thomas E. Ander-son, and Susan L. Graham, ‘‘Efficient Software-Based Fault Isolation,’’Proceedings of the Four-teenth ACM Symposium on Operating SystemPrinciples (SOSP’93),pages 203-216, Asheville,NC, December 1993.

[41] LarryWall, Tom Christiansen, and Randal L.

Schwartz,Programming Perl,O’Reilly & Asso-ciates, Inc., 2nd edition, 1996.

[42] D.R. Wichers, D. M. Cook, R. A. Olsson, J.

Crossley,P.Kerchen, K.Levitt, and R. Lo,‘‘PACL’s:AnAccess Control List Approach toAnti-viral Security,’’Proceedings of the 13thNational Computer Security Conference,pages340-349, Washington, DC, October 1-4 1990.

367