The following paper was originally published in the Proceedings of the Sixth USENIX UNIX Security Symposium San Jose, California, July 1996.

A Secure Environment for Untrusted Helper Applications (Confining the Wily Hacker)

Ian Goldberg, David Wagner, Randi Thomas, and Eric Brewer Computer Science Division University of California, Berkeley

For more information about USENIX Association contact: 1. Phone: 510 528-8649 2. FAX: 510 548-5738 3. Email: [email protected] 4. WWW URL: http://www.usenix.org

A Secure Environment for Untruste d Help er Applications

Con ningtheWilyHacker

Ian Goldb erg David Wagner Randi Thomas Er ic A. Brewer

fiang,daw,randit,[email protected]

University of California, Berkeley

cious programs to spawn pro ce ss e s andto read or Ab stract

wr iteanunsusp ecting us er's le s [15,18,19,34,36].

Whatisnee ded in thi s new environment, then, i s

Manypopular programs, suchasNetscap e, us e un-

protection for all re source s on a us er's system f rom

trusted help er applications to pro ce ss data f rom the

thi s threat.

network. Unfortunately,theunauthenticated net-

workdatathey interpret could well have b een cre-

Our aim i s tocon netheuntrusted software anddata

ated byanadversary,andthehelp er applications are

by monitor ingand re str ictingthe system calls it p er-

1

usually to o complex to b e bug-f ree. Thi s rai s e s s ig-

forms. We builtJanus , a s ecure environment for

ni cant s ecur ity concer ns. Therefore, it i s de s irable

untrusted help er applications, bytaking advantage

to create a s ecure environmenttocontain untrusted

of the Solar i s pro ce ss tracing f acility. Our pr imary

help er applications. Wepropose toreduce therisk

goals for the prototyp e implementation includese-

of a s ecur ity breachby re str ictingthe program's ac-

cur ity,versatility,and con gurability. Our proto-

ce ss totheoperating system. In particular, weinter-

typeismeanttoserve as a pro of-of-concept, andwe

cept and lter dangerous system calls via the Solar i s

b elieveourtechnique s may havea wider application.

pro ce ss tracing f acility. Thi s enable d us to build a

s imple, clean, us er-mo de implementationofa secure

environment for untrusted help er applications. Our

2 Motivation

implementationhas negligible p erformance impact,

and can protect pre-exi stingapplications.

2.1 Thethre atmodel

Before we can di scuss p oss ible approaches tothe

1 Intro duction

problem, wenee d tostart by clar ifyingthethreat

mo del. Webbrows ers and .mailcap le s makeit

Over the past s everal years theInter net environment

convenient for us ers to view information in a wide

has change d drastically. Thi s network, whichwas

var iety of formatsbyde-multiplexingdocumentsto

once p opulate d almost exclus ively bycooperatingre-

help er applicationsbasedonthedocumentformat.

s earchers whoshare d trusted software anddata, i s

For example, when a us er downloads a Postscr ipt

now inhabited bya much larger andmoredivers e

do cument f rom a remotenetworksite, it may b e

group that include s pranksters, crackers, andbusi-

automatically handle d by ghostview. Since that

ne ss comp etitors. Since the software anddata ex-

downloaded data could b e under adversar ial control,

change d on theInter net i s very often unauthentic-

it i s completely untrustworthy. We are concer ned

ate d, it could eas ily have b een created byanad-

thatanadversary could s endmalicious datathatsub-

versary.

vertsthedocument viewer (through someunsp eci e d

s ecur ity bug or mi sfeature), compromi s ingthe us er's

Web brows ers are an increas ingly p opular tool for

s ecur ity.Therefore weconsider help er applications

retr ievingdatafromtheInter net. They often rely

untrusted, andwishto place them outsidethehost's

on help er applications to pro ce ss var ious kinds of

trust p er imeter.

information. These help er applications are s ecur ity-

cr itical, as they handle untrusted data, butthey are

1

Janus is theRoman go d of entrance s and exits, whohad

not particularly trustworthythems elve s. Older ver-

twoheads andeternally kept watchover do orways andgate-

ways to keep out intruders. s ions of ghostscript, for example, allowed mali-

We b elievethatthisisaprudentlevel of para- thesadtaleofthe sendmail \bug of themonth"

noia. Manyhelp er programs were initially envi- [1,2,3,4,8,9,10,11, 12, 13,14,16]. In anyevent,

s ione d as a viewer for a f r iendly us er andwere not attemptsto build s ecur ity directly intothemany

de s igne d withadversar ial inputsinmind. Further- help er applications would require each program to

more, ghostscript implements a full programming be considere d s eparately|not an easy approachto

language, with completeaccesstothe le system; get r ight. For now, wearestuckwithmanyuse-

manyother help er applications are also very gen- ful programs which o er only minimal assurance s of

eral. Wors e still, the s e programs are generally big s ecur ity; therefore whatwe require i s a general, ex-

and bloated, and large complex programs are notor i- ter nal protection mechani sm.

2

ously ins ecure. Secur ity vulnerabilitie s have b een

Adding new protection features into the

exp os e d in these applications [15,18, 19, 34, 36].

OS: We reject thi s design for several reasons.

First, it i s inconvenient. Developmentand install-

ation b oth require mo di cations totheker nel. Thi s

2.2 The dicultie s

approach, therefore, has little chance of b ecoming

widely us e d in practice. Second, wary us ers may

What s ecur ity requirements are demande d f rom a

wi sh to protect thems elves withoutnee dingtheas-

succe ssful protection mechani sm? Simply put, an

sistance of a system admini strator topatchand

outsider whohas control over thehelp er application

recompile theoperating system. Third, s ecur ity-

must not b e able to compromis e the con dentiality,

cr itical ker nel mo di cations are very r i sky: a bug

integr ity,oravailabilityoftherestofthe system,

could endupallowingnew remoteattacks or al-

includingthe us er's le s or account. Anydamage

low a compromis e d application tosubvert theen-

must b e limited tothehelp er application's di splay

tire system. Thechance s of exacerbatingthe current

window, temp orary le s andstorage, and asso ciated

situation are to o high. Better to nd a us er-level

short-live d ob jects. In other words, we ins i st on the

mechani sm so that us ers can protect thems elves, and

Pr inciple of Least Pr ivilege: thehelp er application

so that pre-exi sting acce ss controls can s erveasa

should b e granted the most re str ictive collection of

backup; even in theworst cas e, s ecur ity cannot de-

capabilitie s require d to p erform itslegitimatedutie s,

creas e.

and no more. Thi s ensure s thatthedamage a com-

promised application can caus e i s limited bythere- The pre-existing reference monitor: The

str icted environmentinwhich it executes. In con- traditional operatingsystem's monolithic reference

monitor cannot protect against attacks on help er ap-

trast, an unprotecte d Unix application thatiscom-

plications directly.At most, it could preventapen-

promised will have all the pr ivilege s of the account

f rom whichitisrunning, whichisunacceptable. etration f rom spreadingtonew accounts once the

brows er us er's accounthas b een compromi s e d, but

Imp os ing a re str icted execution environmenton

bythen thedamage has already b een done. In prac-

help er applications i s more dicultthan it might

tice, against a motivated attacker most op eratingsys-

s eem. Many traditional paradigms suchasthe refer-

tems f ail to preventthe spread of p enetration; once

ence monitor andnetwork rewall are insucienton

oneaccounthas b een subverted, thewhole system

their own, as di scuss e d b elow. In order todemon-

typically f alls in rapid succession.

stratethe dicultyofthi s problem andappreciate

thenee d for a novel solution, we explore s everal p os- The conventional network firewall: Packet

s ible approaches. lters cannot di stingui sh b etween di erenttypes of

HTTP trac, let aloneanalyze thedata for s ecur ity

Building security directly into each helper

threats. A proxy could, butitwould b e hard-pre ss e d

application: Takingthings tothe extreme, we

tounderstand all p oss ible le formats, interpret the

could ins i st all help er applications b e rewr itten in a

often-complex application language s, and squelchall

s imple, s ecure form. We reject thi s as completely un-

dangerous data. Thi s would makefora very complex

reali stic; it i s s imply too muchworkto re-implement

andthus untrustworthyproxy.

them. More practically,we could adopt a react-

ive philosophy, recognizingindividual weaknesses as Wetherefore s ee thenee d for a new, s imple, and

eachapp ears andengineer ing s ecur itypatches one general us er-level protection mechani sm thatdoes

ata time. Hi stor ically,thi s has b een a los ingbattle, not require mo di cation of exi stinghelp er applica-

at least for large applications: for instance, explore tions or operating systems. The usual technique s

andconventional paradigms do not workwell in thi s

2

For instance, ghostscript is more than 60,000 lines of C;

situation. Wehope thatthe dicultyofthe problem

and mpeg play is more than 20,000 line s long.

andthepotential utility of a solution should help to application should haveaccess,ortowhichhostsit

motivateintere st in our pro ject. should b e allowed toop en a TCP connection. In

f act, our program oughtto b e con gurable in thi s

way even on a p er-us er or p er-application bas i s.

3 De s ign

On theother hand, wedidnot str iveforthecriter ia

of safetyorportabilityofapplications. By safety,we

mean protectingtheapplicationfromitsown bugs.

Our de s ign, in thestyle of a reference monitor, cen-

Weallowtheusertorunany program hewishes,

ters aroundthefollowing bas ic assumption:

andwe allowthe executable to play within itsown

addre ss space as muchasitwould like.

We adopte d for our program, then, a s imple, mo du-

An application can do little harm if

lar de s ign:

its access to the underlying

operating system is appropriately

restricted.

 a framework,whichistheessential body of the

program, and

 dynamic modules,usedto implementvar ious as-

Our goal, then, was tode s ign a us er-level mechani sm

pects of a con gurable s ecur ity p olicy by lter-

that monitors an untrusted application and di sallows

ingrelevant system calls.

harmful system calls.

A corollary of the assumption i s thatanapplica-

The f ramework reads a con guration le, whichcan

tion may b e allowed todoanythingitlikes that

be site-, us er-, or application-dep endent. Thi s le

do e s not involve a system call. Thi s means it may

li stswhichofthemodule s should b e loaded, andmay

have completeaccesstoits addre ss space, b othcode

supply parameters tothem. For example, the con g-

anddata. Therefore, any us er-level mechani sm we

uration line

providemust re s ide in a di erent addre ss space. Un-

der Unix, thi s means havinga separate pro ce ss.

path allow read,write /tmp/*

One of our bas ic de s ign goals was security.The

untrusted application should not b e able toaccess

would load the path mo dule, pass ingitthe para-

any part of thesystem or network for which our pro-

meters \allow read,write /tmp/*"at initializa-

gram has not grante d it p ermi ss ion. Weusethe

tion time. Thi s syntax i s intended to allow le s under

term sandboxing todescribe the concept of con n-

/tmp tobeopene d for readingorwriting.

ingahelp er application to a re str icted environment,

within whichithas f ree re ign. Thi s term was rst Eachmodule lters outcertain dangerous system

intro duce d, in a slightly di erentsetting, in [35]. call invocations, accordingtoits area of sp ecializ-

ation. When theapplication attempts a system call,

Toachieve s ecur ity, a slogan wekept in mindwas

theframeworkdispatches that information to relev-

\keep it s imple" [29]. Simple programs are more

ant p olicy mo dule s. Eachmodule rep ortsitsopinion

likely to b e s ecure; s implicityhelps toavoid bugs,

on whether the system call should b e p ermitted or

andmake s it eas ier to ndthos e which creep in [17,

quashed, andanynece ssary action i s taken bythe

Theorem 1]. Wewould liketokeep our program

framework. Wenotethat, followingthe Pr inciple of

s impler than theapplications thatwould rununder

Least Pr ivilege, we let theop erating system execute

it.

a system call only if somemodule explicitly allows

Another of our goals was versatility.Wewould it; thedef ault i s for system calls tobedenie d. Thi s

liketobeable toallowordenyindividual system behavior i s imp ortantbecaus e it causes thesystem

calls exibly, p erhaps dep endingonthe arguments to err on theside of s ecur ity incaseofanunder-

tothe call. For example, the open system call could sp eci e d s ecur itypolicy.

b e allowed or denie d dep endingonwhich letheap-

Eachmodule contains a li st of system calls thatit

plication was tryingtoopen, andwhether it was for

will examineand lter. Notethatsome system calls

reading or for wr iting.

may app ear in s everal mo dules' lists. A mo dule may

ass ign toeach system call a function whichvalidates Our third goal was configurability. Di erent

the argumentsofthe call before the callisexecuted sites have di erent requirementsasto which lesthe

3

bytheop erating system. Thefunction can then pro ce ss, andtocontrol the s econd pro ce ss in var ious

us e thi s information tooptionally up datelocalstate, ways (suchascaus ing s electe d system calls to f ail).

andthen sugge st allowingthe system call, sugge st

Luckily,mostoperating systems have a pro ce ss-

denying it, or make no commentontheattempted

tracing f acility,intended for debugging. Most op-

system call.

eratingsystems o er a program calle d trace(1),

The sugge stion to allowisusedtoindicate a mo d- strace(1),or truss(1) which can obs ervethesys-

ule's explicit approval of the execution of thi s system tem calls p erformed by another pro ce ss as well as

call. The sugge stion todenyindicate s a system call their retur n value s. Thi s i s often implemented with

whichistobedenie d execution. Finally,a \nocom- a sp ecial system call. ptrace(2),which allows

ment" re sp ons e means thatthemodule has no input the tracer to regi ster a callbackthatisexecuted

as tothedispatchofthi s system call. whenever the tracee i ssue s a system call. Unfortu-

nately, ptrace o ers only very coars e-graine d all-or-

Mo dule s are li sted in the con guration le f rom most

nothing tracing: we cannot trace a few system calls

general to most sp eci c, so thatthe last relevant

without tracing all therestaswell. Another di sad-

mo dule for any system call dictates whether thecall

vantage of the ptrace(2) interfaceisthatmanyOS

is to b e allowed or denie d. For example, a sugge stion

implementations providenoway for a tracingpro-

toallow countermands an earlier denial. Notethat

ce ss toab ort a system call without killingthe trace d

a \no comment" re sp ons e has no e ect: in particu-

process entirely.

lar, it do e s not overr ide an earlier \deny" or \allow"

re sp ons e. Somemoremoder n operating systems, such as Sol-

ar i s 2.4 andOSF/1,however, o er a b etter pro ce ss-

Normally,when con icts ar i s e, earlier mo dule s are

tracing f acilitythrough the /proc virtual le system.

overr idden bylater ones. To e scap e thi s b ehavior,

Thi s interf ace allows direct control of the trace d pro-

for very sp ecial circumstance s mo dule s may unequi-

ce ss's memory.Furthermore, it has ne-graine d con-

vo cally allowordeny a system call and explicitly in-

trol: we can reque st callbacks on a p er-system call

sist thatthe ir judgement b e cons idere d nal. In thi s

bas i s.

cas e, no further mo dule s are consulte d; a \sup er-

allow" or \sup er-deny" cannot b e overr idden. The There are only slight di erence s b etween the Solaris

intentisthatthi s feature should b e us e d quite rarely, andthe OSF/1 interf ace s tothe /proc f acility.One

for only themostcritical of us e s. Write acce ss to of them i s that Solar i s provide s an easy way for the

.rhosts could b e sup er-denie d near thetopofthe tracing pro ce ss todeterminetheargumentsandre-

con guration le, for example, to provide a safety tur n value s of a system call p erformed bythe trace d

net in cas e we accidentally mi swr itea subs equent pro ce ss. Also, Solar i s operating system i s somewhat

le acce ss rule. more widely deployed. For the s e reasons, wechos e

Solar i s 2.4 for our implementation.

In de s igningthe f rameworkwe aime d for s implicity

andversatilityasmuch as p oss ible, though these

goals often con ict. One can imagine more versat-

4.2 Thepolicy mo dule s

ile andsophi sticate d algor ithms to di spatch system

calls, butthey would comeatagreat cost to s impli-

4.2.1 Overview

city.

The p olicy mo dules are used to s elect and imple-

ment s ecur ity p olicy deci s ions. They are dynam-

4 Implementation

ically loaded atruntime, so that di erent s ecur ity

p olicie s can b e con gure d for di erentsite s, us ers,

or applications. We implemente d a sample s et of

4.1 Choice of operatingsystem

mo dule s that can b e us e d tosetupthe trace d ap-

plication's environment, andto re str ict itsabilityto

In order to implementourdesign, wenee ded to nd

read or wr ite le s, execute programs, andestabli sh

an op erating system that allowed one us er-level pro-

TCP connections. In addition, the trace d applic-

ce ss towatchthe system calls executed byanother

ation i s prevente d f rom p erformingcertain system

3

In addition, a mo dule can assign to a system call a similar

calls, as de scr ib e d b elow. Theprovide d mo dule s of-

function which gets calle d after the system call has executed,

fer cons iderable exibilitythems elves, so thatmay

just before control is returned to thehelper application. This

con gure them s imply by e ditingthe ir parameters in

function can examinethe argumentstothe system call, as well

the con guration le. However, if di erentmodule s as the return value, andupdatethemodule's lo cal state.

further down the line; s ee Section 4.4. are de s ire d or require d, it i s very s imple to compile

new ones.

Of cours e, protectingthe le system aloneisnot

enough. Nearly anypractical help er application will Policy mo dule s nee d tomakeadeci s ion as towhich

require acce ss tonetwork re source s. For example, system calls to allow, whichtodeny,and for which

all of the programs weconsidere d nee d toopen a afunction must b e calle d todeterminewhattodo.

windowonthe X11 di splay to pre s entdocument con- The rst twotyp e s of system calls are the eas ie st to

tents. In our s ecur ity p olicy,networkaccessmust b e handle.

carefully controlle d: we allownetwork connections

Some example s of system calls that are always al-

only tothe X di splay,andthi s acce ss i s allowe d only

lowe d (in our sample mo dule s) are close, exit,

through a safe X proxy.

fork,and read.Theop erating system's protection

X11 does not its elf providethe s ecur ity s ervice s we on the s e system calls i s sucient for our nee ds.

require (X acce ss control i s all-or-nothing). A rogue

Some example s of system calls thatarealways denie d

X clienthas full acce ss to all other clientsonthe

(in our sample mo dule s) are ones thatwould not suc-

sameserver,soanotherwi s e con ned help er applic-

cee d for an unpr ivilege d pro ce ss anyway,like setuid

ation could compromis e other applications if it were

and mount,alongwith someothers, like chdir,that

allowed uncontrolle d acce ss toX.Fortunately the

we di sallow as part of our s ecur ity p olicy.

rewall communityhas already builtseveral safe X

proxie s thatunderstandthe X proto col and lter out Theharde st system calls tohandle are thos e for

dangerous reque sts[26,31]. Weintegrate d our Janus whicha function must, in general,becalledtode-

prototyp e with Xnest [31], whichletsusrun another terminewhether the system call should b e allowed

completeinstance of the X protocol under Xnest. or denie d. Themajorityofthe s e are system calls

Xnest actsasaserver toits clients (e.g. untrus- suchasopen, rename, stat,and kill whos e argu-

ted help er applications), butits di splay i s painted mentsmust b e checke d against the con gurable s e-

within one windowmanage d bytherootXserver. cur ity p olicy sp eci e d in the parameters given tothe

In thi s way,untrusted applications are s ecurely en- mo dule at load time.

capsulated within thechild Xnest server and cannot

e scap e f rom thi s sandb ox di splay area or a ect other

normal trusted applications. Xnest i s not ideal|it i s

4.2.2 Sample securitypolicy

not as small or s imple as wewould like|butfurther

advance s in X proto col lter ing are likely to improve

We implemente d a sample s ecur ity p olicy totest our

thesituation.

ideas, as a pro of of concept.

Help er applications are allowed to fork children, we

then recurs ively trace. Traced processes can only

4.2.3 Sample mo dule s

send s ignals tothems elves or totheir children, and

never toanuntrace d application. Environmentvar i-

Our mo dule s implementingthi s sample p olicy are able s are initially sanitize d, and re source usage i s

as follows. The basic mo dule supplie s def aults carefully limited.

for thesystem calls which are eas ie st toanalyze,

In our p olicy, acce ss tothe le system i s s everely lim-

andtake s no con guration parameters. The putenv

ited. A help er application i s place d in a particular

mo dule allows oneto sp ecify environmentvar iable

directory; it cannot chdir outofthi s directory.We

settings for thetracedapplication via its paramet-

allow it full acce ss to lesinorbelowthi s directory;

ers; thos e which are not explicitly mentioned are

to prevent e scap e f rom thi s sandb ox directory,ac-

uns et. The sp ecial parameter display caus e s the

ce ss topaths containing .. are always denie d. The

help er application to inher it the parent's DISPLAY.

untrusted application i s allowe d read acce ss tocer-

The tcpconnect mo dule allows us to re str ict TCP

tain carefully controlle d le s reference d byabsolute

connections byhost and/or p ort; thedef aultisto

pathnames, suchasshare d librar ie s and global con-

di sallow all connections. The path mo dule, the most

guration le s. We concentrate all acce ss control

complicated one, letsoneallowordeny le acce ss e s

in the open system call, and always allow read and

accordingtooneormorepatter ns.

write calls; thi s i s safe, b ecaus e write i s only us e-

Becaus e thi s p olicy i s just an example, wehavenot ful when us e d on a le de scr iptor obtained from a

goneintoexcruciatingdetail regardingthe sp eci c system call like open.Thisapproach s impli e s mat-

policy deci s ions implemented in our module s. ters, and also allows us a p erformance optimization

ned to a sandb ox directory.Bydef ault, thi s dir- Our sample con guration le for thi s p olicy can b e

ectory i s created in /tmp witharandom name, but s een in Figure 2 in theAppendix.

the SANDBOX DIR environmentvar iable can b e us e d

tooverr idethi s choice.

4.3 Theframework

4.3.1 Re adingthe con guration le 4.3.3 Runningthe trace d pro ce s s

The f rameworkstartsby readingthe con guration

Theapplication runs until it p erforms a system call.

le, thelocation of which can b e sp eci e d on the

Atthi s p oint, it i s puttosleep,andthe tracing

command line. Thi s con guration le cons i stsof

process wake s up. The tracing pro ce ss determines

line s likethos e shown in Figure 2: the rst word

which system call was attempted, along withthear-

is thenameofthemodule toload,andtherestof

gumentstothe call. It then traverses theappropr iate

the line acts as a parameter tothemodule.

linke d li st in thedispatchtable, in order todetermine

whether to allowortodenythi s system call.

For eachmodule sp eci e d in the con guration le,

dlopen(3x) is used to dynamically load themodule

If the system call i s tobeallowed, the tracingpro-

intothe f ramework's addre ss space. Themodule's

ce ss s imply wakes up theapplication, which pro cee ds

init() function i s calle d, if pre s ent, withthe para-

to completethe system call. If, however, thesys-

meters for themodule as itsargument.

tem call i s tobedenie d, the tracing pro ce ss wakes

up theapplication withthe PRSABORT ag s et. Thi s

The li st of system calls and asso ciated value s and

caus e s the system call toab ort immediately,retur n-

functions in themodule i s then merge d intothe

inga value indicatingthatthe system call f aile d and

f ramework's dispatch table.Thedispatchtable i s an

setting errno to EINTR.Ineither cas e, the tracing

array,indexe d by system call numb er, of linked lists.

process goes backto sleep.

Eachvalue andfunction in themodule i s appended

tothelistinthe di spatchtable thatisindexe d bythe

Thefactthatanaborte d system call retur ns EINTR to

system call to whichitisassociated.

theapplication pre s entsapotential problem. Some

applications are co ded in suchaway that, if they

The re sult, after theentire con guration le has b een

rece iveanEINTR error f rom a system call, they will

read, i s that for each system call, the di spatchtable

retry the system call. Thus, if suchaapplication

provides a linke d li st thatcanbetraversed todecide

tr ie s to execute a system call whichisdenie d bythe

whether to allowordeny a system call.

s ecur ity p olicy,itwillgetstuckinaretryloop. We

detect thi s problem bynoticingwhen a large num-

b er (currently 100) of the same system call withthe

4.3.2 Settingupthe trace d pro ce s s

same arguments are cons ecutively denie d. If thi s o c-

curs, we assumethe trace d application i s not going

After thedispatchtableissetup,theframework gets

tomakeanyfurther progre ss, and just kill the ap-

ready toruntheapplication thatisto b e trace d: a

plication entirely, giving an explanatory me ssage to

child pro ce ss i s fork()ed, andthechild's stateis

the us er. Wewould prefer tobeable toretur n other

cleane d up. Thi s includes settingaumask of 077,

error co des (suchasEPERM)totheapplication, but

setting limits on virtual memory us e, di sablingcore

Solar i s do e s not supp ort thatbehavior.

dumps, switchingtoasandb ox directory,and clos ing

When a system call completes, the tracing pro ce ss unnece ssary le de scr iptors. Mo dulesgetachance

has theabilityto examinetheretur n value if it so to further initialize thechild's state; for instance, the

wi shes. If anymodule had ass ignedafunction to putenv mo dule sanitize s theenvironmentvar iable s.

b e executed when thi s system call completes, as de- The parent pro ce ss waitsforthechild to complete

scr ib e d above, it i s executed atthi s time. Thi s f acil- thi s cleanup, and b egins todebug thechild via the

ity i s not widely us e d, except in one sp ecial cas e. /proc interf ace. It s etsthechild pro ce ss tostop

whenever it b egins or ni she s a system call (actu-

When a fork() or vfork() system call completes,

ally, only a subs et of the system calls are marked in

the tracing pro ce ss checks theretur n value andthen

thi s manner; s ee Section 4.4, b elow). Thechild waits

fork()sits elf. Thechild of the tracing pro ce ss then

until it is being trace d, andexecutes thede s ire d ap-

detaches from theapplication, and b egins tracingthe

plication.

application's child. Thi s metho d safely allows the

trace d application to spawn a child (as ghostview In our sample s ecur itypolicy,theapplication i s con-

5.1 Eas e of us e spawns gs, for example) by ensur ingthatallchildren

of untrusted applications are trace d as well.

The s ecure environmentisrelatively easy toinstall.

Wehave not aime d for extens iveauditing, but log-

All thatisnee ded is toprotect theinvocation of any

gingoftheactions taken bythe f rameworkwould b e

help er application withourenvironment. The most

easy to add to our implementation if desired.

convenientsolution i s to sp ecify our janus program

Weshould p ointoutthatthe Solar i s tracing f acilit-

in a mailcap le, which could lo ok like

ie s will not allow a trace d application to exec() a

setuid program. Furthermore, trace d programs can-

image/*; janus xv %s

not tur n o their own tracing.

application/postscript; janus ghostview %s

video/mpeg; janus mpeg_play %s

video/*; janus xanim %s

Withlittle e ort, a system admini strator could s et

4.4 Theoptimizer

up thein-house securitypolicybylisting janus in

thedef ault global mailcap le; then the s ecure en-

Our program has thepotential to add a non-

vironmentwould b e transparentto all theuserson

tr ivial amountofoverhead tothe trace d application

the system. Similarly, us ers could protect thems elves

whenever it intercepts a system call. In order tokeep

bydoingthesametothe ir p ersonal .mailcap le.

thi s overhead down, weobviously wanttointercept

as few system calls as p oss ible|or at least, as few of

the common one s as p oss ible. However, wedonot

5.2 Applicability

wi sh to give up s ecur ityto gain p erformance.

Therefore, weapply s everal optimizations tothe sys-

Us ers will wanttorun our s ecure environmentwith

tem call di spatchtable b efore theuntrusted help er

pre-exi stinghelp er applications. Wetested a number

application executes. Wenotethatone common cas e

of programs under our s ecure environment, includ-

arises when a mo dule's system call handler always

ing ghostview, mpeg play, xdvi, xv,and xanim.

retur ns thesame allow/denyvalue (andleaves no

Though we followed the Pr inciple of Least Pr ivilege

side e ects); thi s sp ecial cas e allows us to remove

andwere very re str ictive in our s ecur ity p olicy,we

re dundantvalue s in the di spatchtable.

foundthateachoftheapplications had sucient

pr ivilege, andwehad not unduly re str icted the ap-

The most imp ortantoptimization obs erves thatcer-

plications f rom doingthe ir legitimateintende d jobs.

tain system calls, suchaswrite, are always allowed;

so wenee d not regi ster a callback withtheOSfor

In addition, werantheshells sh and bash under

them. Thi s avoids the extra context switches toand

our s ecure environment. Unle ss the us er explicitly

f rom the tracing pro ce ss eachtimethe trace d ap-

tr ie s to violatethe s ecur ity p olicy (e.g., bywriting

plication makes such a system call, andthus thos e

to .rhosts), there i s no indication of the re str icted

system calls can executeat full sp ee d as though

nature of theshell. Attemptstoviolatethe s ecur ity

there were no tracingor lter ing. By eliminatingthe

p olicy are rewarded withashell error me ssage.

nee d to trace common system calls suchasread and

write,we can greatly sp ee d up the common cas e.

5.3 Secur ity

There i s no universally accepted way to ass e ss

whether our implementation i s s ecure; however, there

5 Evaluation

are de niteindications wecanusetomakethi s de-

ci s ion.

The general p opulation i s more intere ste d in e- We b elieveinsecuritythrough s implicity,andthi s

ciency andconvenience than in s ecur ity,soanyse- was a guiding pr inciple throughoutthede s ign and

cur ity pro duct intende d for general us e must addre ss implementation pro ce ss. Our entire implementation

the s e concer ns. For thi s reason, weevaluateour consistsofapproximately 2100 line s of co de: the

prototyp e implementation byanumberofcriter ia, frameworkhas 800, andthemodule s havethere-

including s ecur ity,applicability,andeaseofuse,in maining 1300. Furthermore, wehaveattempted to

addition to p erformance. minimize theamount of s ecur ity-cr itical statewhere

p oss ible. Since thede s ign concept i s a s imple one,

Figure 1: Performance datafor ghostscript and

and b ecaus e theentire program i s small, the imple-

play mpeg

mentation i s eas ier tounderstandandtoevaluate.

Thus, there i s a muchsmaller chance of havingan

ndetected securityhole.

u 30

We p erforme d some s imple sanitychecks tover ify

hat our implementation appropr iately re str ictsap-

t 25

plications. More work on assurance i s nee ded.

antly,thebesttest is outsidescrutiny

Most imp ort 20

byindep endent exp er ience d s ecur ity researchers; a

etaile d co dereviewwould help improvethe assur-

d 15

ance and s ecur ity o ere d by our s ecure environment.

All are encourage d to examine our implementation

for aws. 10 Traced ghostscript times (sec)

5

5.4 Performance

esign potentially adds time-consuming

Since our d 00 5 10 15 20 25 30

text switche s for every system call theuntrus-

con Untraced ghostscript times (sec)

ted application makes, theobvious p erformance met-

ric toevaluateistime. Wemeasure d thepeakper-

12

formance of ghostscript and mpeg play,two large

commonly us e d help er applications, under our s ecure

vironment. Notethat mpeg play in particular i s

en 10

p erformance cr itical.

play was us e d to di splay ninempegmovie s

mpeg 8

ranginginsizefrom53KB(18frames) to740KB

(400 f rames). ghostscript was us e d to di splay

6

seven Postscr ipt le s ranging in s ize f rom 9 KB to

1.7 MB. ghostscript was run non-interactively,so

hat all the page s in thePostscr ipt le were di s-

t 4

playe d in succe ss ion withnouserintervention. We

Traced mpeg_play times (sec)

to ok 100 measurements for each le, 50 trace d under

2

our s ecure environmentand50untrace d, calculating

themean andstandard deviation for eachset.The

measurementswere doneusinganunloaded single-

00 2 4 6 8 10 12

pro ce ssor SPARCstation 20 workstation running Sol-

Untraced mpeg_play times (sec) ar i s 2.4. The Xnest Xwindows proxy [31]was us e d

withthe s ecure environment, but not withtheun-

trace d measurements.

ni cantperformance p enalty.

The re sults are di splaye d in Figure 1. For each

s et, we plotted thetracedtime against theuntrace d

Thenegligible p erformance impact can b e attr ibuted

4

time. Theboxe s aroundthedata p ointsindicate

totheunintrus ivenature of our implementation. Of

onestandard deviation. The diagonal lineshows the

cours e, all computations andmemory reference s that

ideal re sultofnostatistically s igni cantperformance

do not involvethe OS will executeat full sp ee d, so

overhead. In the b e st p oss ible cas e, the error b oxe s

system calls can b e the only source of p erformance

will all inters ect theideal line. Boxe s entirely above

overhead. We rst notethatsystem calls are already

the lineindicatestatistically s igni cantoverhead. As

so time-consumingthattheadditional overhead of

can b e s een, the s ecure environment imp os e s no s ig-

theJanus process lter ing i s ins igni cant. Further-

4

more, most of theheavily us e d system calls (such

Similar re sults were obtained when measur ing f ramerate

per s econd for mpeg play. as read and write) require no acce ss checks and

vers ion that p erforms addre ss-bas e d authentication; therefore runat full sp ee d. By stayingoutoftheap-

it i s intended toprotect s ecur ity-cr itical Unix system plication's way andoptimizing for the common cas e,

daemons [30]. Other re s earchthat also take s advan- wehave allowed typical applications torunwithneg-

tage of share d librar ie s can b e found in [27,24]. We ligible p erformance overhead.

notethat s imple replacementofdangerous C library

calls with a safe wrapp er i s insucient in our exten-

de d context of untrusted and p oss ibly hostile applic-

6 Related work

ations; a hostile application could bypass thi s acce ss

control by s imply i ssuingthedangerous system call

Due tothe accelerated developmentofcommunica-

directly withoutinvokingany library calls.

tion technology,the s ecur ityand protection problems

Fer nandez and Allen [23] extendthe le system pro-

inherentinanopen andfreecommunication envir-

tection mechani sm with p er-us er acce ss control li sts.

onment, suchastheInter net, are relatively new ones

Lai and Gray [28]de scr ib e an approach whichpro-

to solve. Cons equently,muchofthework addre ss ing

tects against Tro jan hors e s and virus e s by limit-

s ecur ity for thi s environmentisstill b e ingdeveloped.

ing le system acce ss: their OS extens ion con nes

Toachieve s ecur ity,weusethe concept of sandb ox-

us er pro ce ss e s tothe minimal le system pr ivilege s

ing, rst intro duce d byWahb e et al. in thecon-

nee de d, relyingonhintsfromthe commandlineand

text of software f ault i solation [35]. However, they

(when nece ssary) run-time us er input. TRON [7]dis-

were actually solving a di erent problem. Whatthey

courage s Tro jan hors e s by adding p er-pro ce ss capab-

achieved was safety for truste d mo dule s runningin

ilitie s support tothe le system di scretionary acce ss

the same addre ss space as untrusted module s. They

controls. These works all su er twoma jor di sadvant-

ignore d the problem of system-level s ecur ity; con-

age s: they require ker nel mo di cations, andthey do

vers ely,we do not attempt toprovide safety.They

not addre ss i ssue s suchascontrol over pro ce ss and

also us e binary-rewr itingtechnology to accompli sh

network re source s.

the ir goals, whichpreventsthem f rom running ar-

Domain andTyp e Enforcement(DTE)isaway to

bitrar ily general pre-exi stingapplications.

extendthe OS protection mechani sms to let sys-

Java [25] i s an comprehens ive system that addre ss e s,

tem admini strators sp ecify ne-grained mandatory

amongother things, b othsafetyand s ecur ity, al-

acce ss controls over theinteraction b etween s ecur ity-

though it achieves securityby a di erentapproach

relevantsub jectsandobjects. A re s earch group

f rom ours. Java cannot s ecure pre-exi sting pro-

at TIS has amass e d cons iderable exp er ience with

grams, b ecaus e it require s us e of a new language.

DTE andits practical application to Unix systems

We do not havethi s problem; our de s ign will run

[5,6, 32, 33]. DTE i s an attractiveand broadly ap-

anyapplication, and so i s more versatile in thi s re-

plicable approachtomandatory acce ss control, but

sp ect. However, Java o ers manyother advantage s

itsmain di sadvantage i s that it require s ker nel mo di-

thatwe do not addre ss; for instance, Javaprovides

cations; we aime d instead for us er-level protection.

architecture-indep endence, while Janus only applie s

tonativecodeandprovide s no help with p ortability.

7 Limitations andfuture work

OmniWare [20]take s advantage of software f ault

i solation technique s and compiler support to safely

executeuntruste d co de. LikeJava, it also has

7.1 Limitations of the prototyp e

architecture-indep endence, extens ibility, ande-

ciency as imp ortant goals.

Oneinherent limitation of theJanus implementation

We notetwo imp ortant di erence s b etween theJava is thatwe can only succe ssfully runhelp er applica-

approachandtheJanus philosophy.TheJava pro- tions which do not legitimately nee d many pr ivilege s.

tection mechani sm i s much more complex, andis Our approach will eas ily accommo dateany program

clos ely intertwine d withtherestofJava's other func- that only require s s imple pr ivilege s, suchasaccessto

tionality.Incontrast, wehave more limite d goals, a preference s le. Application developers may want

explicitly aim for extreme s implicity,andkeep these- tokeep thi s in mindand not assume, for example,

cur itymechani sm orthogonal f rom the non-s ecur ity- thattheir applications will b e able toaccessthewhole

cr itical functionality. le system.

securelib is a share d library that replace s theC Wehavefollowed one s imple direction in our proto-

accept, recvfrom,and recvmsg library calls bya typ e implementation, butothers are p oss ible as well.

spawned help er applications as well. The arguments One could cons ider us ing sp ecialize d Unix system

which leave us suspicious of help er applications also calls to revoke certain pr ivilege s. Thetwomajor

apply towebbrows ers: they are large, complex pro- contenders are chroot(),to con netheapplication

grams thatinterpret untrusted networkdata. For ex- within a safe directory structure, and setuid(),to

ample, a bu er overrunbugwas found in an earlier change to a limite d-pr ivilege accountsuchasnobody.

versionoftheNetscap e brows er [21]. Themain chal- Unfortunately, programs nee d sup erus er pr ivilege s

lenge i s thatbrows ers legitimately require many more tousethese feature s; s ince wewere committed to

pr ivilege s; for instance, most manage con guration a us er-level implementation, wedecided to ignore

le s, datacaches, andnetworkconnections. Of these, them. However, thi s design choice could b e recon-

the broader network acce ss s eems toposethe most sidere d. Other security p olicie s (suchasmandatory

dicultie s. audit logs) may also b e more appropr iate in some

environments.

We b elieveproxie s are a promi s ingapproach for im-

provingcontrol over network accesses. By taking ad- The most fundamental limitation of our implement-

vantage of earlier workin rewalls, wewere able to ation, however, stems f rom its sp ecialization for a

eas ily integrateasafeXproxy into our prototyp e. single op erating system. EachOSto whichJanus

Wehaveshown thatone can guard acce ss tosys- mightbeporte d require s a s eparate s ecur ityana-

tem calls with a reference monitor constructed from lys i s of its system calls. Also, a bas ic assumption of

pro ce ss-tracing f acilitie s; we susp ect thatone can ef- Janus i s thattheoperating system provides multiple

fectively and exibly guard acce ss totheoutsidenet- addre ss space s, allows trappingofsystem calls, and

workwithexistingproxie s developed bythe rewall make s it feas ible tointerp os e proxie s where nece s-

community.Oneissueishowtointerpose proxie s sary. Solar i s 2.4 has the most convenientsupp ort

forcibly up on untrusted andunco operativeapplic- for these mechani sms; we b elieve our approachmay

ations. We currently us e environmentvar iable s as also apply to someother Unix systems. On theother

hints|for instance, wechange the DISPLAY var iable hand, platforms that do not supp ort these services

to p ointtoaproxy X s erver, and di sallow acce ss to cannot directly b ene t f rom our technique s. In par-

anyother X di splay|butthi s only works for well- ticular, our approach cannot b e applie d toPCsrun-

behaved applications that consultenvironmentvar i- ning MS-DOS or Microsoft Windows. Theutilityof

able s cons i stently.Onemightconsider implementing the s e con nementtechnique s, then, will b e determ-

suchhintswithashare d library that replace s net- ined bytheunderlyingoperatingsystem's supp ort

work library calls with a safe call to a s ecure proxy. for us er-level s ecur ity pr imitives.

So f ar wehave followed the p olicy thatahelp er ap-

plication should not b e able to communicate withthe

7.2 Future work

outsidenetwork, s ince there are s everal subtle s ecur-

ity i ssue s with addre ss-bas e d authentication, trust

In thi s pap er, wehavelimite d di scuss ion tothetopic

perimeters, andcovert channels [22]. Integration

of protectinguntrusted help er applications. It would

with lter ingproxie s and ne-graine d control over

also b e intere stingto explore howthese technique s

acce ss toother network s ervice s, suchasdomain

might b e extended to a more ambitious scope.

nameservers andremoteweb s ervers, would enable

One exciting area for further re s earchinvolves Java

our technique s to b e us e d in broader contexts. The

applet s ecur ity.Java [25] i s s ee ingwidespread de-

overlap with re s earchinto rewalls lends hope that

ployment, butseveral implementation bugs [22]have

the s e problems can b e solved satisfactor ily.

started toshake con dence in itssecuritymodel. For

more protection, one could runJavaappletswithin a

s ecure environment builtfromtechnique s described

in thi s pap er. Thi s approachprovides defens e in

8 Conclus ion

depth: if theJavaapplet s ecur itymechani sm i s com-

promised, there i s still a s econdlineofdefens e. We

Wede s igned and implemented a secure environment

are exp er imentingwiththi s approach; more workis

for untrusted help er applications. We re str ict an un-

nee ded.

truste d program's acce ss totheop erating system by

us ingthe pro ce ss tracingfacilityavailable in Solar i s Another natural extens ion of thi s workistorunweb

2.4. In thi s way,wehavedemonstrated thefeasib- brows ers under theJanus s ecure environment. The

ilityofbuildingand enforcing practical s ecur ity for recurs ive tracingofchild pro ce ss e s would ensure that

untrusted help er applications. running a brows er under Janus would protect all

[7] Andrew Berman, Virgil Bourassa, and Er ik Sel- The Janus approachhas twomain advantage s:

b erg. TRON: Pro ce ss-sp eci c le protection for

the UNIX operating system. In Proc. 1995

 The Janus protection mechani sm i s orthogonal

USENIX Winter Technical Conference, page s

f rom other application functionality, so our us er-

165{175. USENIX Asso c., 1995.

mo de implementation i s s imple and clean. Thi s

make s it more likely to b e s ecure, and allows

[8] CERT advi sory CA-88:01, 1988.

our approachto b e broadly applicable to all ap-

plications.

[9] CERT advi sory CA-90:01, January 1990.

 We can protect exi stingapplications withlittle

[10] CERT advi sory CA-93:15, Octob er 1993.

p erformance p enalty.

[11] CERT advi sory CA-93:16, Novemb er 1993.

We feel thatthi s e ort i s a valuable step toward s e-

[12] CERT advi sory CA-94:12, July 1994.

cur ity for theWorld WideWeb.

[13] CERT advi sory CA-95:05, February 1995.

[14] CERT advi sory CA-95:08, August 1995.

9 Availability

[15] CERT advi sory CA-95:10, August 1995.

TheWebpage

[16] CERT advi sory CA-95:11, Septemb er 1995.

http://www.cs.berkeley.edu/~daw/janus/

will contain more information on availabilityofthe

[17] William R. Che swickandSteven M. Bellovin.

Janus software de scr ib e d in thi s pap er.

Firewal ls and Internet Security: Repel ling the

Wily Hacker. Addi son-We sley, 1994.

[18] Fre der ickCohen. Personal communication.

10 Acknowle dgements

[19] Fre der ickCohen. Inter net hole s. Network Se-

Wewould liketothank Steven Bellovin, David Op-

curity Magazine,January 1996.

p enheimer, Armando Fox, Steve Gr ibble, andthean-

onymous reviewers for their helpful comments.

[20] Colusa Software. OmniWare technical overview,

1995.

[21] Ray Cromwell. Bu er over ow, Septem-

Reference s

ber 1995. Announce d on the Inter net.

http://www.c2.net/hacknetscape/.

[1] [8lgm]-Advisory-16.UNIX.s endmail-6-Dec-

1994, December 1994.

[22] Drew Dean, Edward W. Felten, and Dan S.

Wallach. Java s ecur ity: From HotJavato Nets-

[2] [8lgm]-Advisory-17.UNIX.s endmailV5-2-May-

cap e andbeyond. In Proc. of the 1996 IEEE

1995, May 1995.

Symposium on Security and Privacy, 1996.

[3] [8lgm]-Advisory-17.UNIX.s endmailV5.22-Aug-

[23] G. Fer nandez and L. Allen. Extendingthe

1995, August 1995.

Unix protection mo del with acce ss control li sts.

In Proc. Summer 1988 USENIX Conference,

[4] [8lgm]-Advisory-20.UNIX.s endmailV5.1-Aug-

page s 119{132. USENIX Asso c., 1988.

1995, August 1995.

[24] Glenn S. Fowler, YennunHuang, David G.

[5] Lee Badger, Daniel F. Ster ne, David L. Sher-

Kor n, and Herman Rao. A us er-level replicated

man, andKennethM.Walker. A domain and

le system. In Summer 1993 USENIX Confer-

typ e enforcement UNIX prototyp e. USENIX

enceProceedings, page s 279{290. USENIX As-

Computing Systems, 9(1):47{83, Winter 1996.

so c., 1993.

[6] Lee Badger, Daniel F. Ster ne, David L. Sher-

[25] Jame s Goslingand Henry McGilton. TheJava man, Kenneth M. Walker, and Sheila A.

language environment: A white pap er, 1995. Haghighat. Practical domain andtyp e enforce-

http://www.javasoft.com/whitePaper/ ment for UNIX. In Proc. 1995 IEEE Symposium

javawhitepaper on Security and Privacy, 1995. 1.html.

[26] Br ian L. Kahn. Safe us e of X window system Note: CERT advi sor ie s are available on theInter net

proto col across a rewall. In Proc. of the 5th from

USENIX UNIX Security Symposium, 1995. ftp://info.cert.org/pub/cert advisories/.

8lgm advi sor ie s can b e obtained from

[27] David G. Kor n andEduardo Krell. The3-D

http://www.8lgm.org/advisories/.

le system. In Summer 1989 USENIX Confer-

enceProceedings, page s 147{156. USENIX As-

so c., 1989.

[28] Nick Lai andTerence Gray.Strengtheningdis-

cretionary acce ss controls to inhibit Tro jan

hors e s and computer virus e s. In Proc. Sum-

mer 1988 USENIX Conference, page s 275{286.

USENIX Asso c., 1988.

[29] Butler Lampson. Hints for computer system

de s ign. In Proceedings of the 9th ACM Sym-

posium on Operating Systems Review,volume

17:5, page s 33{48. Bretton Wo o ds, 1983.

[30] William LeFebvre. Re str ictingnetworkaccess

to system daemons under SunOS. In UNIX

Security Symposium III Proceedings, page s 93{

103. USENIX Asso c., 1992.

[31] Davor Matic. Xnest. Available in the X11R6

source. Also ftp://ftp.cs.umass.edu/pub/

rcf/exp/X11R6/xc/programs/Xserver/hw/

xnest.

[32] David L. Sherman, Daniel F. Ster ne, Lee

Badger, and S. Murphy. Controllingnetwork

communication with domain andtyp e enforce-

ment. Technical Rep ort 523, TIS, March1995.

[33] Daniel F. Ster ne, Terry V. Benzel, Lee Badger,

KennethM.Walker, Karen A. Oostendorp,

David L. Sherman, andMichael J. Petkac.

Brows ingtheweb safely withdomain andtyp e

enforcement. In 1996 IEEE Symposium on Se-

curity and Privacy, 1996. Re s earchabstract.

[34] Je Upho . Re: Guideline s on cgi-bin scr ipts,

August 1995. Post to bugtraq mailinglist.

http://www.eecs.nwu.edu/cgi-bin/mfs/

files2/jmyers/public html/bugtraq/

0166.html?30#mfs.

[35] Rob ert Wahbe, Steven Lucco, Thomas E. An-

derson, and Susan L. Graham. Ecient

software-bas e d f ault i solation. In Proc. of the

Symp. on Operating System Principles,1993.

[36] Chr i stian Wettergren. Re: Mimequestion...,

March 1995. Post to bugtraq mailinglist.

http://www.eecs.nwu.edu/cgi-bin/mfs/

files2/jmyers/public html/bugtraq/

1995a/0759.html?30#mfs.

Figure 2: Sample con guration le

basic

putenv display

putenv HOME=. TMP=. PATH=/bin:/usr/bin:/usr/ucb:/usr/local/bin:/usr/local/X11/bin

:/usr/bin/X11:/usr/contrib/bin:/usr/local/bin XAUTHORITY=./.Xauthority LD_LIBRARY

_PATH=/usr/local/X11/lib

tcpconnect allow display

path super-deny read,write,exec */.forward */.rhosts */.klogin */.ktrust

# this is the paradigm to deny absolute paths and allow relative paths

# (of course, we will later allow selected absolute paths)

# assumes someone will put us in a safe sandboxeddir.

# note that the wildcard `*' can match anything, including /

path allow read,write*

path deny read,write /*

# allow certain explicit paths

path allow read /dev/zero /dev/null /etc/netconfig /etc/nsswitch.conf /etc/hosts

/etc/resolv.conf /etc/default/init /etc/TIMEZONE /etc/magic /etc/motd /etc/servic

es /etc/inet/services /etc/hosts /etc/inet/hosts

# note: subtle issues here.

# make sure tcpconnect is loaded, to restrict connects!

# /dev/ticotsord is the loopback equivalent of /dev/tcp.

path allow read,write /dev/tcp /dev/ticotsord

# where libraries live; includes app-defaults stuff too

path allow read /lib/* /usr/lib/* /usr/local/X11/lib/* /usr/local/X11R6/lib/* /us

r/share/lib/zoneinfo/* /usr/local/lib/* /usr/openwin/lib/*

# these are here so you can read the files placed by Netscape and Mosaic

path allow read /var/tmp/* /tmp/*

# this is where binaries live; it should look a lot like your PATH

path allow read,exec /bin/* /usr/bin/* /usr/ucb/* /usr/local/bin/* /usr/local/X11

/bin/* /usr/bin/X11/* /usr/contrib/bin/* /usr/local/bin/*