USF Libraries
USF Digital Collections

Program monitoring in a mandatory-results model

MISSING IMAGE

Material Information

Title:
Program monitoring in a mandatory-results model
Physical Description:
Book
Language:
English
Creator:
Reddy, Srikar Reddy
Publisher:
University of South Florida
Place of Publication:
Tampa, Fla.
Publication Date:

Subjects

Subjects / Keywords:
Security policies
Safety
Liveness
Security automata
Policy enforcement
Dissertations, Academic -- Computer Science -- Masters -- USF   ( lcsh )
Genre:
bibliography   ( marcgt )
non-fiction   ( marcgt )

Notes

Abstract:
ABSTRACT: In many real enforcement systems, a security-relevant action must return a result before the application program that invoked that action can continue to execute. However, current models of runtime mechanisms do not capture this requirement on results being returned to application programs; current models are limited to reasoning about policies and enforcement in terms of actions alone, without considering the results of those actions. This thesis presents a more general model of runtime policy enforcement in which all actions return (possibly void- or unit-type) results. This mandatory-results model more accurately reflects the capabilities and limitations of real enforcement mechanisms, particularly those mechanisms that operate by monitoring function/method invocations. We analyze the new model to show that result-returning runtime monitors enforce a strict superset of the safety policies, including some nontrivial liveness policies.
Thesis:
Thesis (M.S.C.S.)--University of South Florida, 2009.
Bibliography:
Includes bibliographical references.
System Details:
Mode of access: World Wide Web.
System Details:
System requirements: World Wide Web browser and PDF reader.
Statement of Responsibility:
by Srikar Reddy Reddy.
General Note:
Title from PDF of title page.
General Note:
Document formatted into pages; contains 27 pages.

Record Information

Source Institution:
University of South Florida Library
Holding Location:
University of South Florida
Rights Management:
All applicable rights reserved by the source institution and holding location.
Resource Identifier:
aleph - 002317625
oclc - 660838938
usfldc doi - E14-SFE0003078
usfldc handle - e14.3078
System ID:
SFS0027394:00001


This item is only available as the following downloads:


Full Text

PAGE 1

ProgramMonitoringinaMandatory-resultsModelbySrikarReddyReddyAthesissubmittedinpartialfulllmentoftherequirementsforthedegreeofMasterofScienceinComputerScienceDepartmentofComputerScienceandEngineeringCollegeofEngineeringUniversityofSouthFloridaMajorProfessor:JayLigatti,Ph.D.LawrenceO.Hall,Ph.D.RahulTripathi,Ph.D.DateofApproval:July1,2009Keywords:Securitypolicies,Safety,Liveness,Securityautomata,PolicyenforcementcCopyright2009,SrikarReddyReddy

PAGE 2

ACKNOWLEDGEMENTSIamextremelythankfultomyadvisorDr.JayLigatti,forhisguidanceandmotivationthoughoutthecompletionofthisthesis.Thisthesiswouldnothaveexistedinitscurrentformunlessforhisneverendingsupport.Thisthesisderivesfromthecurrentworkingprojecttitled"SecurityAutomatawithMandatoryResults".IwouldliketothankDr.LarryHallandDr.RahulTripathiforbeingonmythesissupervisorycommittee.Ialsoliketothankmylabmatesatthesecurityandprogramminglanguageslabfortheirvaluablesuggestionsinformattingthisthesis.LastbutnotleastIliketothankmyfriendsatUniversityofSouthFloridafortheirmoralsupport.ThisresearchwassupportedinpartbyNSFgrantsCNS-0716343andCNS-0742736.

PAGE 3

TABLEOFCONTENTSLISTOFFIGURESiiABSTRACTiiiCHAPTER1INTRODUCTION1CHAPTER2BACKGROUNDNOTATIONANDDEFINITIONS42.1Notation42.2PoliciesandProperties5CHAPTER3PROPERTYENFORCEMENTWITHMANDATORY-RESULTSAU-TOMATAMRAS83.1OperationalSemanticsofMRAs83.2MRA-basedEnforcement123.2.1EectiveEnforcement133.2.2InputandOutputExecutionswithMRAs14CHAPTER4ANALYSISOFMRA-ENFORCEABLEPOLICIES18CHAPTER5RELATEDWORKANDCONCLUSIONS225.1RelatedWork225.2Conclusion23REFERENCES25i

PAGE 4

LISTOFFIGURESFigure1.1Existingmodelofaninsecureapplicationasecuredbyaprogrammonitorb.2Figure1.2Thisthesis'smodelofaninsecureapplicationwithresultsasecuredbyaprogrammonitorb.3Figure3.1Single-stepsemanticsofmandatory-resultsautomatamonitor-controlledtransitions.10Figure3.2Denitionsofinputandoutputjudgments.16Figure4.1Relationshipsbetweensafety,liveness,andMRA-enforceableproperties.21ii

PAGE 5

ProgramMonitoringinaMandatory-resultsModelSrikarReddyReddyABSTRACTInmanyrealenforcementsystems,asecurity-relevantactionmustreturnaresultbe-foretheapplicationprogramthatinvokedthatactioncancontinuetoexecute.However,currentmodelsofruntimemechanismsdonotcapturethisrequirementonresultsbeingreturnedtoapplicationprograms;currentmodelsarelimitedtoreasoningaboutpoliciesandenforcementintermsofactionsalone,withoutconsideringtheresultsofthoseactions.Thisthesispresentsamoregeneralmodelofruntimepolicyenforcementinwhichallactionsreturnpossiblyvoid-orunit-typeresults.Thismandatory-resultsmodelmoreaccuratelyreectsthecapabilitiesandlimitationsofrealenforcementmechanisms,particularlythosemechanismsthatoperatebymonitoringfunction/methodinvocations.Weanalyzethenewmodeltoshowthatresult-returningruntimemonitorsenforceastrictsupersetofthesafetypolicies,includingsomenontriviallivenesspolicies.iii

PAGE 6

CHAPTER1INTRODUCTIONRuntimeenforcementmechanismsdynamicallymonitoruntrustedtargetapplicationstoensurethatthoseapplicationsadheretodesiredpolicies.Althoughcomputabilityandprooftheoryprovidegoodframeworksforunderstandingwhichpoliciescanbeenforcedontargetapplicationsthroughstaticanalysis,wecurrentlylacksucientlygeneralframeworksforunderstandingwhichpoliciescanbeenforcedthroughruntimemechanisms.Thisthesispresentsanew,generalframeworkforreasoningaboutruntimeenforcementandinvestigatesthelimitsofenforcingpoliciesdynamically,animportantproblemgiventhepopularityofruntimemechanismsinrewalls,operatingsystems,auditingtools,spamlters,intrustion-detectionsystems,access-controlsystems,etc.Muchresearchhasbeenperformedtomodelgenericruntimemechanismsandanalyzetheirenforcementcapabilitiescf.Chapter5.1.However,existingmodelsofgenericrun-timemechanismsarebasedonthesystemabstractionsshowninFigure1.1.Figure1.1adepictsatargetapplicationissuinginstructions|ormoreabstractly,actions|foranunder-lyingsystemsuchasanoperatingsystem,virtualmachine,orCPUtoexecute.Wecansecuretheapplicationbyinterposingamonitoringmechanismbetweentheapplicationandtheunderlyingsystem,asinFigure1.1b.Themechanism,asecuritymonitor,dynamicallytransformstheapplication'sactionstoensurethattheoverallsequenceofactionsactuallyexecutedisvalidi.e.,satisesadesiredpolicy.AlthoughexistingmodelsofsoftwaresecuritytintotheframeworkofFigure1.1,thatframeworkfailstocapturethesemanticsofpracticalsystems,inwhichactionsreturnresultsandanapplicationcannotcontinueexecutingafterissuinganactionauntilreceivinga1

PAGE 7

Figure1.1.Existingmodelofaninsecureapplicationasecuredbyaprogrammonitorb.resultfora.Figure1.2adepictsthismorepracticalscenario,whichencompassesapplicationactionsthat:1.Returnresults,suchasactionsfordereferencingpointers,forreturninguserinput,forreadingandreturningdatainaleornetworkbuer,etc.2.Raiseexceptions,suchasactionsfordereferencingpossiblynullpointers,writingtopossiblynonexistentlesornetworkports,etc.Inthiscase,wesimplytreattheexceptionsthatcanberaisedaspotentialreturnvalues.3.Donotreturnresults,suchasactionsforoutputtingtexttoamonitorormovingdatafromoneregistertoanother.Inthiscase,theactionshaveanimplicitorexplicitvoidorunitreturntype,sowecanviewtheunderlyingsystemasreturninganactualvoidorvalueuponcompletionofoneoftheseactions.Hence,allactions,eventhosenotnormallyconsideredtoreturnresults,tintoaframeworkinwhichactionsreturnresults.Besidesinterposingonanddynamicallytransformingactions,practicalmonitorscaninterposeonanddynamicallytransformactionresults,asFigure1.2billustrates.Thisisacrucialcapabilityforenforcingmanysecuritypolicies,suchasprivacy,access-control,andinformation-owpolicies,whichmayrequiremechanismstosanitizetheresultsofactionsbeforeapplicationsaccessthoseresults.Forexample,policiesmayrequirethatsystemlesgethiddenwhenuser-levelapplicationsretrievedirectorylistings,orthatemailmessagesaggedbyspamltersdonotgetreturnedtoemail-clientapplications.Becauseexistingframeworksforreasoningaboutgenericruntimemechanismsdonotmodelresultsofactions,onecannotuseexistingframeworkstospecifyorreasonaboutenforcementofsuchpolicies.2

PAGE 8

Figure1.2.Thisthesis'smodelofaninsecureapplicationwithresultsasecuredbyaprogrammonitorb.ContributionsThisthesisgeneralizesexistingframeworksofruntimeenforcementtocapturethepracticalabilityofmonitorstotransformbothactionsandresults,asillustratedinFigure1.2b.Wemakethefollowingcontributions.1.Chapter2modiesexistingdenitionsofpolicies,properties,andprogramexecutions,totakeintoaccountactionresults.2.Chapter3denesmandatory-resultsautomataMRAs,newmodelsofrun-timeen-forcementmechanismsthatinterposeonandensurethesecurityoftwostreamsofevents:applicationactionsandtheresultsofthoseactions.MRAsareobligatedtooutputaresulttotheapplicationforitsmostrecentlyinvokedactionbeforetheapplicationcaninvokeanotheraction.3.Chapter4analyzesMRAstoshowthattheyenforceastrictsupersetofthesafetypolicies,includingsomenontriviallivenesspolicies.Thisthesisaddressesoneofwhatweconsidertobethetwoprincipalshortcomingsofexistingruntime-enforcementframeworks:theinabilitytoreasonaboutresultsofactionsandconcurrency.Weleavethecomplexissuesofconcurrencyinmonitoringframeworksforfutureworkandherefocusonmonitoringsynchronousactionsi.e.,actionsforwhichtheapplicationmustreceiveareturnvaluebeforecontinuingtoexecuteandtheresultsofthoseactions.3

PAGE 9

CHAPTER2BACKGROUNDNOTATIONANDDEFINITIONSBeforedeningmandatory-resultsautomataMRAsandwhatitmeansforanMRAtoenforceapolicy,werstneedtodenepoliciesandsetupsomebasicnotationforspecifyingsystemsandtraces.Mostofthenotationanddenitionspresentedinthischapterareextendedversionsofnotationanddenitionsinpreviousworkextendedtoincluderesultsofactions[1,2,3].2.1NotationWedeneasystemabstractly,intermsoftheactionsitcanexecutetoperformcom-putationandthepossibleresultsofthoseactions.Thesystem'sinterfacedeterminesitsactionset;forexample,iftheexecutingsystemisanoperatingsystemthenactionswouldbesystemcalls;iftheexecutingsystemisavirtualmachinethenactionswouldbevirtual-machine-codeinstructionse.g.,Javabytecode,includingcallstoAPIlibrariesintegratedwiththevirtualmachine;andiftheexecutingsystemismachinehardwarethentheac-tionswouldbemachine-codeinstructions.WeusethemetavariableAtorepresentthenonempty,possiblycountablyinnitesetofactionsonasystemandRdisjointfromAtorepresentthenonempty,possiblycountablyinnitesetofresults.Aneventiseitheranactionoraresult,andweuseEtodenotethesetofeventsonasystem;E=A[R.GivenasetofeventsE,actEreferstoalltheactionsinEandresEtoalltheresultsinE.Anexecutionortraceisapossiblyinnitesequenceofevents.Atraceofatargetapplicationisthesequenceofeventsthatoccurduringarunofthatapplication;theex-ecutionhasnitelengthiftherunterminatesandinnitelengthotherwise.Becauseweassumesynchronousactions,allexecutionscontainalternatingactionsandresults;thatis,4

PAGE 10

allexecutionsunderconsiderationinthisthesishavetheforma0;r0;a1;r1;:::;an;rnora0;r0;a1;r1;:::;anora1;r1;a2;r2;:::wherer0istheresultofactiona0,r1istheresultofa1,etc..Thesymbolrepresentsazero-lengthexecutioninwhichnoeventsoccur.Wheneventeoccursinexecutionx,wewritee2x.Wedenotethesequenceofactionsinanexecutionxasactsxandthesequenceofresultsinxasrsltsx.Moreover,wedenotetheitheventi2Nofexecutionxasx[i]andthelengthofniteexecutionxasjxj.Wealsodenotethesetofallnite-lengthexecutionsonasystemwitheventsetEasE,allinnite-lengthexecutionsasE!,andallnite-andinnite-lengthexecutionsasE1.Weletthemetavariableerangeoverevents,aoveractions,roverresults,"andxoverexecutions,andXoversetsofexecutionsi.e.,subsetsofE1.Sometimesitwillbeconvenienttouseasametavariablerangingoveractionsand,whilerangesoverresultsand.Thenotationx;"representsconcatenationoftwoexecutionsxand"therstofwhichmusthavenitelength.Whenxisaniteprexof"wewritex"or"x,andwhenxisaproperprexof"wewritex"or"x.Finally,whenEisclearfromcontext,wemakeextensiveuseofabbreviationsoftheform9x":Finplaceofthemoreverbose9x2E:x"^F.2.2PoliciesandPropertiesApolicyisapredicateonsetsofexecutions[2];asetofexecutionsXE1satisesapolicyPifandonlyifPX.Somepoliciesarealsoproperties.PolicyPisapropertyifandonlyifthereexistsacharacteristicpredicate^PoverE1suchthatforallXE1,thefollowingistrue[2]:PX8x2X:^PxPropertyThisdistinctionbetweenpropertiesandmoregeneralpoliciesisimportantwhenrea-soningaboutdynamicenforcementmechanismsbecausesuchmechanismsmonitorasingleexecutionatatimeandmakedecisionsaboutwhetherthatsingleexecutionissecure,5

PAGE 11

therebyenforcingpropertiesratherthanpolicies.Incontrast,static-analysismechanismscanenforcenonpropertypoliciesbyconsideringallexecutionsofanapplication.Thereisaone-to-onecorrespondencebetweenapropertyPanditscharacteristicpred-icate^P,soweusethenotation^Punambiguouslytorefertobothacharacteristicpredicateandthepropertyitinduces.When^P",wesaythat"satisesorobeystheproperty,or"isvalidorlegal;similarly,if:^P"thenwesaythat"violatesordisobeystheproperty,or"isinvalidorillegal.Propertiessatisedbytheemptyexecutionthataredecidableovernite-lengthexecutionsarecalledreasonableproperties.Becausethedenitionsofpolicyandpropertyaboveoperateonexecutionscontainingresults,itispossibletodenepoliciesthattakeresultsintoconsideration.Forexample,apolicymightbesatisedbyexactlythosesetsofexecutionsXinwhichallnaturalnumbersngetreturnedastheresultofactionainsomeexecutioninX.Thispolicyisnotapropertybecausethereisnopredicate^PthatcanlookatindividualexecutionsinisolationtodeterminewhethertheresultsofallaactionsinallexecutionsofXformacompletesetofnaturalnumbers.Ontheotherhand,considerapolicysatisedbyexactlythosesetsofexecutionsXinwhichnoresultofanylsactioninanyexecutioninXcontainsthestring.hidden.ThispolicyisapropertybecauseitissatisedifandonlyifeveryexecutioninXlacks.hidden-containingresultstoalllsactions.Properties,suchasthehidden-lespolicyjustdescribed,specifyingthatnothingbadeveroccurs"arecalledsafetyproperties[4].Thiswell-studiedclassofpropertiesincludescommonlyenforcedpropertiessuchasaccess-controlpropertiesspecifyingthatnoillegalaccessingofresourceseveroccurs.Technically,safetymeansthateveryinvalidexecutionmusthavesomeinvalidprexafterwhichallextensionsareinvalid[5],soaproperty^PonasystemwitheventsetEisasafetypropertyifandonlyif:8"2E1::^P"=9"0":8x"0::^PxSafety6

PAGE 12

Ontheotherhand,livenesspropertiesstatethatnothingirremediablybadeverhappensinaniteamountoftime[1].Likesafetyproperties,livenesspropertiesarewellstudied.Butunlikesafetyproperties,livenessincludesparticularlydicult-orimpossible-to-enforcepropertiessuchasthatanapplicationwilleventuallyinputaparticularvalueorterminate.Formally,aproperty^PonasystemwitheventsetEisalivenesspropertyifandonlyif:8"2E:9x":^PxLivenessExactlyonepolicyisbothasafetyandalivenessproperty:theproperty>,whichconsidersallexecutionsvalid[1].7

PAGE 13

CHAPTER3PROPERTYENFORCEMENTWITHMANDATORY-RESULTSAUTOMATAMRASHavingdenedexecutions,policies,andpropertiesinthepreviouschapter,wearereadytoformallymodelmonitorsthatbehaveasinFigure1.2b.3.1OperationalSemanticsofMRAsSynchronousapplicationactionsimposeamajorconstraintonhowmonitorsmaybe-have;themonitorsmustreturnaresulttothetargetbeforeseeingthenextactionthetargetwishestoexecute.Realprogrammonitorse.g.,ascreatedintheNaccio[6],PoET/PSLang[7],Polymer[8],LoPSiL[9],andConSpec[10]systemshavethismandatory-resultsconstraint,anditisforthisconstraintthatmandatory-resultsautomataarenamed.WemodelasMRAsmonitorsthatcaninterposeonandtransformsynchronousactionsandtheirresults.AnMRAMistupleE;Q;qo;,whereEistheeventsetoverwhichMoperates,QistheniteorcountablyinnitesetofpossiblestatesofM,qoisM'sinitialstate,andisatransitionfunctionoftheform:QE!QE,whichtakesM'scurrentstateandaneventbeinginputtoMeitheranactionthetargetisattemptingtoexecuteoraresulttheunderlyingsystemhasproducedandreturnsanewstateforMandaneventtobeoutputfromMeitheranactiontobeexecutedontheunderlyingsystemoraresulttobereturnedtothetarget.Incontrasttopreviouswork[11,12,3],wedonotrequiretobedecidableitmaynothaltonsomeinputs;thisabilityofMRAstodivergeaccuratelymodelstheabilitiesofrealruntimemechanisms.WecalliohqioiacongurationofmonitorM,whereqisM'scurrentstate,iiseitherortheactioncurrentlyinputtoMbythetargetprogram,oiseitherortheaction8

PAGE 14

beingoutputbyMtotheexecutingsystem,iiseitherortheresultbeinginputtoMbytheexecutingsystem,andoiseitherortheresultbeingoutputbyMtothetargetprogram.Whenwedonotcareaboutthevaluesofi,o,i,andoincongurationiohqioi,wesimplywritethecongurationasq.Also,wenormallydonotbothertowritethedotsincongurations,soahqiristhesameasahqir.ThestartingcongurationofanMRAisahq0i;thatis,themonitorbeginsexecutinginitsinitialstatewiththerstapplicationactionbeinginput.Noticethatourbracket-basednotationforcongurationsmatchesthegraphicrepresentationofmonitors'inputsandoutputsasshowninFigure1.2b.WearenowreadytodescribetheoperationalsemanticsofMRAs,asdenedbyala-beledsingle-stepjudgmentwhoseformisiohqioi"T"S// M0i0ohq0i0o0i.ThisjudgmentmeansthatMRAMistakingasinglestepfromcongurationiohqioitoconguration0i0ohq0i0o0iwhilebuildingtargetexecution"Tandsystemexecution"S.Thetargetexecution"Tistheexecutionviewedbythetarget;inotherwords,"Tisthesequenceofactionsthatthetargethassentto,andtheresultsthetargethasreceivedfrom,themonitor.Similarly,thesystemexecution"Sistheexecutionviewablebythesystem,thatis,alltheactionsexecutedon,andtheresultsofactionsexecutedon,theunderlyingsystem.Analnoteaboutnotationusedinoursingle-stepjudgment:becauseMwillalwaysbeclearfromthecontext,wenormallyomititfromthejudgment.ThedenitionofMRAs'single-stepsemanticsappearsinFigure3.1.TherearethreeinferencerulesdeningMRAtransitionsinFigure3.1;eachruleallowsanMRAtotransitionfromacurrentstateqtoanewstateq0.TherstruleIns-on-ActenablesanMRAtoinsertanactiona0thatwillbeexecutedbeforethemonitorreturnsaresulttothetargetfortheactionacurrentlybeinginputtotheMRA;becausea0willbeexecuted,itisplacedintothesystemexecution.ThesecondruleRes-on-InsenablesanMRAtoupdateitsstateinresponsetoreceivingtheresultofanactionitjustinserted;becausetheresultiscomingfromtheunderlyingsystem,ittoogetsplacedintothesystemexecution.ThethirdruleRes-on-ActenablesanMRAtoreturnaresultrtothetargetapplicationforanactionathatthetargethassentasinputtotheMRA;becauseaandrareeventsviewable9

PAGE 15

iohqioi"T"S// 0i0ohq0i0o0i q;a=q0;a0 ahqia0// ahq0ia0Ins-on-Actq;r=q0; ahqirr// ahq0iRes-on-Insq;a=q0;r ahqia;r// rhq0iRes-on-ActFigure3.1.Single-stepsemanticsofmandatory-resultsautomatamonitor-controlledtran-sitions.bythetarget,theygetplacedintothetargetexecution.Thesimplicityoftheseinferencerules,asmuchasispresent,istheproductofmucheortanditeratingthroughnumerousless-satisfactoryattempts.Inadditiontothemonitor-controlledtransitionsshowninFigure3.1,therearetwosingle-steptransitionsbetweencongurationsthatcanoccuroutsideofthemonitor'scon-trol.First,thetransitionrhqi)167(!ahqioccurswhenthemonitorhasnishedprocessinganinputactionbyreturningaresultrtothetarget,andthenthetargetsendsitsnextactionatothemonitor;however,ifthetargetgeneratesnoadditionalactionsthentheMRAnevermakesatransitionfromandthereforeterminatesincongurationrhqi.Thesecondsingle-steptransitionoutsideofthemonitor'scontrolisahqia0!ahqir,whichoccurswhentheexecutingsystemreturnsaresultrforaninsertedactiona0.Thistransitionalwaysoc-cursinourmodelfromcongurationahqia0becauseweassumethattheunderlyingsystemreturnsaresultforeveryactionitisaskedtoexecute.WenextmakeseveralobservationsabouttheoperationalsemanticsofMRAs:1.Awildcard existsinthepremiseofruleRes-on-Insinplaceofaneventebecausetherule,whichcausesnoeventtobeoutputfromtheMRA,ignorese'svalue.10

PAGE 16

2.AnMRAcanaccept"anapplicationactionabyinsertingitwithruleIns-on-Act,receivingandrememberingtheresultrofexecutingawithruleRes-on-Ins,andthenreturningrtotheapplicationwithruleRes-on-Act.3.AnMRAcanhalt"anapplicationbyinsertinganactionlikeexit,iftheunderlyingsystemcanexecutesuchanaction.Alternatively,anMRAcanenteraninnitelooptoblockadditionalactionsandresultsfrombeinginputandoutput.AnMRAcanachieveasimilareectbyrepeatedlytransitioningwiththeRes-on-Actrule,whichwillcausethesystembutnottargetexecutiontoterminate.4.MRAsareobligatedtoreturnresultstoapplicationsbeforereceivingnewinputac-tions.NotransitionsdescribedaboveallowanMRAtoinputanewactionuntilithasdischargedthelastactionbyreturningaresultforit.5.Wemakenoassumptionsabouttheunderlyingsystemthatexecutesapplicationac-tionsbeyondthatitproducessomeresultpossiblyanexceptionforeveryactionitisaskedtoexecute.Theunderlyingsystemmayproduceresultsnondeterministicallyorthroughuncomputablemeanse.g.,byreadingaweathersensororspontaneouskeyboardinput.Thisdesigncapturestherealitythatmonitorscanonlydeterminetheresultsofmanyactionse.g.,getCurrentCloudCover,inputNextCharFromUser,ormorecommonactionslikereadFileDataordereferenceLocationbyhavingtheunderlyingsystemexecutethoseactions.Thisdesignalsomakesthesingle-stepre-lationnondeterministic,asthesystemmayreturnanyofanumberofresultsforthesameactioninanexecution.6.JustasMRAsareagnosticofhowtheunderlyingsystemgeneratesresults,MRAsareagnosticofhowthetargetgeneratesactions.AgnosticismoftargetapplicationsmakesMRAspurelydynamicenforcementmechanisms;MRAscannotuseanyknowledgeofapplicationsourcecodei.e.,howapplicationsgenerateactionswhenenforcingproperties.11

PAGE 17

Theseobservationsdescribeideasthatmatchourunderstandingofhowrealprogrammoni-torssuchasareimplementedintheNaccio[6],PoET/PSLang[7],Polymer[8],LoPSiL[9],andConSpec[10]systemsbehave.Havingdenedthesingle-stepsemanticsofMRAs,wedenethemulti-stepjudgmentinthestandardwayasthereexive,transitiveclosureofthesingle-stepjudgment.Themulti-stepjudgmentformisq"T"S// q0where"Tand"Sarethetargetandsystemexecu-tionsformedviaconcatenationsduringthemulti-steptransitionfromcongurationqtocongurationq0.3.2MRA-basedEnforcementWeadoptthenotionthatmechanismsenforcepolicieswhentheyaresoundandtranspar-ent[13,14,15,3].Soundnessrequiresthattheobservableexecution,whichistheexecutionoutputfromthemechanism,mustsatisfythedesiredpolicy.Soundnessaloneisunsatis-factory,though,becauseanymechanismcanenforceanyreasonablepropertybysimplyrejectingallinputsandalwaysoutputtinganemptyexecutionthus,allofitsobservableoutputsarevalid.Transparencypreventsthissituationbyrequiringmechanismstopre-servethesemanticsofvalidinputexecutions;iftheapplicationandsystemonlyprovidevalidinputstothemechanism,thenthemechanismmustnotalterthesemanticsofthosevalidinputs.Toreasonabouttransparencyandwhetheramechanismpreservesthesemanticsofvalidinput,weassumethepresenceofasystem-specicequivalencerelationonpossiblyinnite-lengthexecutions.Whenxx0wesaythatxandx0aresemanticallyequiva-lent.Weplacenoconstraintsonthisequivalencerelationbeyondthatpropertiesmaynotdistinguishbetweenequivalentexecutions.Onemorejudgmentwillmakeiteasiertodeneenforcement.Forreasoningaboutbothsoundnessandtransparency,weneedawaytosaythatanenforcementmechanismMtakes"iasitsinput,andtransforms"iintotheoutputexecution"o.Thisideaofviewingtheroleofenforcementmechanismsastransformingpossiblyinvalidinputexecutionsintovalid12

PAGE 18

executionssoundness,whilepreservingthesemanticsofvalidinputexecutionstrans-parency,comesfromearlierwork[11,3].WhenmechanismMtransformsinputexecution"iintotheoutputexecution"o,wewrite"i+M"o.Deningthe+MjudgmentforMRAsisabittricky,sowepostponethatdenitionuntilwenishdeningenforcement.Fornow,andthroughoutChapter3.2.1,letusassumethatwealreadyhaveadenitionof+MforallMthatareMRAs.3.2.1EectiveEnforcementWedeneenforcementintermsofsoundnessandtransparency.Asinearlierwork[11,3],wecallthisstyleofenforcementeectiveenforcement"becauseitdeneswhenamechanismisbehavingfullyeectivelyandreliesontheequivalencerelation.Denition1EectiveEnforcement.AnMRAM=E;Q;qo;eectivelyenforcesaproperty^PonasystemwitheventsetEandsemanticequivalencerelationifandonlyif:8"i;"o2E1:"i+M"o=^P"o^^P"i="i"oBecauseequivalencerelationsaresystemspecic,andbecauseearlierworkhasprovedthatequivalencerelationsenablesecurityautomatatoenforceanyreasonablepropertyincluding,forexample,termination[3],wefollowpreviousworkandfocushereonsystemsinwhichtheequivalencerelationisjustthesystem-independentequalityrelation=.Byfocusingonexecutionequality,weareconsideringlowerboundsontrueenforcementcapabilities;anypropertyeectively=enforceableonasystemwithequivalencerelationmustalsobeeectivelyenforceablebecauseequalityimpliesequivalence.Toreasonaboutpossiblyinnite-lengthexecutionsbeingequal,weformallydenetwoexecutionstobeequalwhentheyshareallthesameprexes.Denition2EqualityofExecutions.ForalleventsetsEandexecutionsx1;x22E1,x1=x2ifandonlyif8"x1:"x2and8"x2:"x1.13

PAGE 19

Fortheremainderofthisthesis,wewillwriteeectiveenforcement"orjustenforce-ment"inplaceofeective=enforcement".3.2.2InputandOutputExecutionswithMRAsWenowreturntothepostponedissueofwhichexecutionsMRAsinputandoutput;ourgoalistodenewhenthe"i+M"ojudgmentholdsforanMRAMandpossiblyinnite-lengthexecutions"Tand"S.Thereareseveralhurdlestoovercomeinordertodenethistransformsrelation,butitsdenitionwillenableustojudgewhethergivenMRAsenforcedesiredproperties.WehavealreadydenedinChapter3.1howMRAsbuilduptargetandsystemexecu-tionswiththemulti-stepjudgmentq"T"S// q0.However,thisjudgmentonlyletsusreasonaboutthetargetandsystemexecutionsafteranitenumberofsteps.MRAsmaymakeaninnitenumberoftransitionswhilemonitoringaprogramrun,sowemustgeneralizethemulti-stepjudgmenttohandlepossiblyinnite-lengthtargetandsystemexecutionsbuiltupthroughpossiblyinnitelymanyMRAtransitions.Hence,weintroducethejudgment"TooM// "StoindicatethattheMRAM,beginninginitsinitialstate,buildstargetandsystemexecutions"Tand"Sduringitsentirerun.Intuitively,"TooM// "Sholdsifandonlyif,ananynitenumberofsteps,Monlybuildstargetandsystemexecutionsthatareprexesof"Tand"S,andconversely,Mbuildstargetandsystemexecutionscontainingeveryprexof"Tand"S.Formally,wedene"TooM// "Sasfollows.Denition3PossiblyInnite-lengthTargetandSystemExecutions.ForallMRAM=E;Q;qo;and"T;"S2E1,"TooM// "Sifandonlyif:1.8q02Q:8"0T2E:8"0S2E:qo"0T"0S// q0^acts"0Tacts"T^rslts"0Srslts"S="0T"T^"0S"S2.8"0T"T:8"0S"S:9q02Q:9"00T"0T:9"00S"0S:qo"00T"00S// q0Todenethetransformsjudgment,wealsomustdenewhichexecutionamonitorin-putsandwhichitoutputs.Untilnow,ourrulesforMRAshavebuilttargetandsystem14

PAGE 20

executions,ratherthaninputandoutputexecutions,sowehavetodenehowtoconverttargetandsystemexecutionsintoinputandoutputexecutions.Targetandsystemexecu-tionsaretheexecutionsvisibletotargetsandsystems,butinputandoutputexecutionsaretheexecutionsinputto,andoutputfrom,theMRAitself.Thatis,aninputexecutionincludestheactionsinputfromthetargetandtheresultsofthoseactionsasinputfromtheunderlyingsystem.Anoutputexecutionincludesactionsoutputtothesystemandtheresultsofthoseactionsasoutputtothetargetprogram.Hence,soundnesswillrequirethattheactionsactuallyexecutedbythesystemandtheresultsactuallyreturnedtothetargetarevalid,allowingustoreasonaboutMRAsenforcingresult-sanitizationproperties,suchasthehidden-lespolicydescribedinChapter2.2.Also,transparencywillrequirethatiftheMRAreceivesavalidstreamofactionsfromthetargetandresultsfromthesystem,thenitmustendupoutputtingthosesameactionstothesystemandthosesameresultstothetarget.Givenpossiblyinnite-lengthtargetandsystemexecutions"Tand"S,webuildtheinputexecutionbytakingalltheactionsin"Tandinterspersingtheresultstothoseactionsasrstfoundin"S.Similarly,webuildtheoutputexecutionbytakingalltheactionsin"Sandinterspersingtheresultstothoseactionsasrstfoundin"T.Thus,wewouldconverttargetexecutiona1;r1;a2;r2andsystemexecutiona1;r2;a2;r1intoinputexecutiona1;r2;a2;r1andoutputexecutiona1;r1;a2;r2.Similarly,wewouldconverttargetexecutiona1;r1;a2;r2andsystemexecutiona2;r1;a1;r2intoinputexecutiona1;r2;a2;r1andoutputexecutiona2;r2;a1;r1.However,anissueariseswhenanactionain"Tisnotpresentin"S,sowehavenoresulttoincludeforain"i.Inthiscasewekeepain"ibutusea'sresultrfrom"T,ratherthanfrom"S,asa'sresultin"i.Thus,actiona,whichthetargetsenttotheMRA,correctlycountsasaninputaction,andbecausetheMRAneveractuallyinputaresultforafromthesystem,wetreattheresultrthattheMRAreturnedtothetargetforawhichistheonlyresultwehaveforaastheinputexecution'sresultfora.NotethatincludingrintheinputexecutiondoesnotdamagetheoutputexecutionbecausetheMRAneveroutputa,sorcouldnotbeincludedintheoutputexecutionanyway.Ananalogousissueariseswhenan15

PAGE 21

input"T;"S="i input;"S=Input-Dota62"S inputa;r;"T;"S=a;r;input"T;"SInput-No-Swapa62"S inputa;r;"T;"S;a;r0;"0S=a;r0;input"T;"S;"0SInput-Swap output"T;"S="o output"T;=Output-Dota62"T output"T;a;r;"S=a;r;output"T;"SOutput-No-Swapa62"T output"T;a;r0;"0T;a;r;"S=a;r0;output"T;"0T;"SOutput-SwapFigure3.2.Denitionsofinputandoutputjudgments.actionain"Sisnotpresentin"T;theissuegetsresolvedinthesamewaybykeepingain"oandusinga'sresultfrom"Sasa'sresultin"o.Puttingalltheserulestogether,wewouldconverttargetexecutiona1;r1;a1;r1;a2;r2;a3;r3andsystemexecutiona4;r4;a3;r1;a1;r2intoinputexecutiona1;r2;a1;r1;a2;r2;a3;r1andoutputexecutiona4;r4;a3;r3;a1;r1.Figure3.2denestwojudgmentsinput"T;"S="iandoutput"T;"S="othatholdwhennite-lengthtargetandsystemexecutions"Tand"Shavebeenproperlyconvertedintonite-lengthinputandoutputexecutions"iand"ointhemannerjustdescribed.Wegeneralizethesedenitionstoinnite-lengthexecutionsusingatechniquesimilartoourgeneralizationofthemulti-stepjudgmentwithnite-length"Tand"Stothe"TooM// "Sjudgmentwhichallowsinnite-length"Tand"S.Therstgeneralizedjudgment,allowingallexecutionstohaveinnitelengthandindicatingthattargetandsystemexecutions"Tand"Sforminputexecution"i,iswrittenas"Tin"S="i.Thatis,inisanoperatorthatbuilds"isimplybystartingwith"Tandswappinginresultsfrom"Sfortheactionsin"T.16

PAGE 22

Similarly,"Tout"S="oindicatesthatpossiblyinnite-length"ocontainsalltheactionsof"S,withtheresultsofthoseactionsin"Tswappedin.Todenethe"Tin"S="ijudgment,weintuitivelyrequiretheinputfunctiontoreturnonlyprexesof"iwhengivenprexesof"T,andconversely,theinputfunctionmustreturnallprexesof"i.The"Tout"S="ojudgmentisdenedsimilarly.Formaldenitionsoftheinandoutoperatorsappearbelow.Denition4in.ForalleventsetsEand"T;"S;"i2E1,"Tin"S="iifandonlyif:1.8"0T"T:9"0S"S:input"0T;"0S"i2.8"0i"i:9"0T"T:9"0S"S:input"0T;"0S="0iDenition5out.ForalleventsetsEand"T;"S;"o2E1,"Tout"S="oifandonlyif:1.8"0S"S:9"0T"T:output"0T;"0S"o2.8"0o"o:9"0S"S:9"0T"T:output"0T;"0S="0oAtlast,wearereadytodenetransformationofapossiblyinnite-lengthinputex-ecution"itoapossiblyinnite-lengthoutputexecution"obyanMRAM,writtenas"i+M"o.ThisjudgmentholdswhenMbuildstargetandsystemexecutions"Tand"S,and"Tin"S="iand"Tout"S="o.Denition6MRATransformation.ForallMRAsM=E;Q;q0;andexecutions"i;"o2E1:"i+M"oifandonlyif9"T;"S2E1:"TooM// "S^"Tin"S="i^"Tout"S="o.17

PAGE 23

CHAPTER4ANALYSISOFMRA-ENFORCEABLEPOLICIESThischaptercomparesthesetofpropertiesMRAscanenforcewiththemoreestablishedsetsofsafetyandlivenessproperties.FirstweshowthatMRAscanenforceanyreasonablesafetyproperty.ThetechniqueforenforcinganysafetypropertywithanMRA,aswithothersecurityautomata[3],istoacceptalleventsaslongastheysatisfythesafetypropertyandceaseexecution1assoonasaninvalidinputeventisdetected.Inthisway,theMRAwillonlyoutputvalidexecutionssoundness,andiftheinputexecutionisvalidthentheMRA'soutputwillmatchitsinputbecausethepropertyisasafetyproperty,whichimpliesthatallprexesofallvalidexecutionsmustalsobevalid.Theorem7.Anyreasonablysafetyproperty^PonasystemwitheventsetEcanbeenforcedbysomeMRA.Proof.WeconstructanMRAMthatenforcesanysuch^Pasfollows:1.States:Q=EEthecurrenttargetexecutionpairedwiththecurrentsystemexecution2.Startstate:q0=;3.Transitionfunctionforsimplicitywewriteintermsofhigh-leveltransitions:Considerprocessinganinputactionainstateq="T;"S: 1Ourproofsinthischapterceaseexecution"byhavingtheMRAsenterinniteloopstoblocktheMRAsfromreceivingadditionalinputsandoutputs.Inpractice,runtimemechanismscouldenterinniteloopsbutwouldtypicallyceaseexecutionmorestraightforwardlybyinvokinganexitaction.Weusetheinnite-loopapproachtoceaseexecutioninourproofsbecauseitdoesnotconstrainustoconsidersystemswithexit-styleactions.18

PAGE 24

aIf^P"T;a,theninsertaandletrbetheresultobtainedforafromthesystem.Then,if^P"T;a;r,returnrtothetargetandcontinueinstate"T;a;r;"S;a;r.Otherwise,if:^P"T;a;rthenenteraninniteloop.bOtherwise,if:^P"T;athenenteraninniteloop.Nowwelet"2E1betheautomatoninput.If^P"thenbythedenitionofsafety,allprexesof"mustbevalid,sobythedenitionofM,Mwilloutputalltheprexesof".Hence,Moutputs"inthiscaseandcorrectlyenforces^Ponvalidexecutions.Inthecasewhere:^P",wemustonlyshowthatMissound.BythedenitionofM,onlyvalidactionsandresultsgetoutput,soMissoundandcorrectlyenforces^Ponallexecutions. Moreover,thereexistnonsafety,nonlivenesspropertiesenforceablebyMRAs.Theorem8.Thereexistsareasonableproperty^PonasystemwitheventsetEthatisneitherasafetynoralivenesspropertybutcanbeenforcedbyanMRAM.Proof.LetE=fa1;a2;rg,wherea1anda2areactionsandrisaresult.Alsolet^Pbesatisedbyexactlythoseexecutionsmatchingthepatterna1;r1.^Pisreasonablebecauseitisdecidableoverallniteinputsand^P.^Pisnotasafetypropertybecausethereexistsaninvalidexecutiona1thatcanbeextendedtoavalidexecutiona1;r.^Pisalsonotalivenesspropertybecausethereexistsaninvalidnite-lengthexecutiona2thatcannotbeextendedtoavalidexecution.WenextdeneanMRAMtoenforcethisreasonablenonsafety-nonlivenessproperty.Moperatessimplybyrepeatingthefollowing:iftheinputactionisa1theninserta1tobeexecuted,obtainitsresultr,andoutputrtothetargetastheresultofa1;otherwise,iftheinputactionisa2thenenteraninniteloopi.e.,outputnoadditionalactionsorresults.Misasoundenforcerwithrespectto^Pbecauseitsoutputexecutionswillonlyeverbeoftheforma1;r1becauseitonlyoutputsa1actionsandrresults,anditalwaysoutputsanrforeverya1itoutputs.MisalsotransparentbecauseitnevermodiesvalidinputexecutionsbecauseMoutputseverya1andritinputs.Hence,Mcorrectlyenforcesthisreasonablenonsafety-nonlivenessproperty^P. 19

PAGE 25

Therealsoexistsomenonsafety,livenesspropertiesenforceablebyMRAs,asthefollow-ingtheoremshows.Theorem9.Thereexistsareasonableproperty^PonasystemwitheventsetEthatisnotasafetypropertybutisalivenesspropertyandcanbeenforcedbyanMRAM.Proof.LetE=fa;rg,whereaisanactionandrisaresult.Alsolet^Pbesatisedbyexactlythoseexecutionsthatmatchthepatterna;r1.^Pisreasonablebecauseitisdecidableoverallniteinputsand^P.^Pisnotasafetypropertybecausethereexistsaninvalidexecutionathatcanbeextendedtoavalidexecutiona;r.^Pisalivenesspropertybecausetheonlyinvalidnite-lengthexecutionshavetheforma;r;a,butanysuchexecutioncanbeextendedintoavalidexecutionbyappendinganr.WenextdeneanMRAMtoenforcethisreasonablenonsafety-livenessproperty.Moperatessimplybyrepeatingthefollowing:readtheinputactiona,inserta,obtainitsresultr,andreturnrtothetarget.Thus,Mexecuteseveryactionthetargetattemptstoexecute,andMreturnseveryresultgeneratedbythesystemtothetarget.Misasoundenforcerwithrespectto^Pbecauseforeveryathatitinputs,itoutputsa,inputsr,andoutputsr.Therefore,itsoutputexecutionswillonlyeverbeoftheforma;r1.MisalsotransparentbecauseitnevermodiesvalidinputexecutionsbecauseMoutputseveryaandritinputs.Hence,Mcorrectlyenforcesthisreasonablenonsafety-livenessproperty^P. TherearesomelivenesspropertiesunenforceablebyMRAs,suchastermination.AnMRAcannotenforceterminationbecauseinordertobetransparent,itmustoutputallvalidinputexecutions,soforanyinnite-lengthinputexecutionwhichmustbeinvalid,theMRAwouldhavetooutputallofitsprexes,implyingthattheMRAoutputstheentireinnite-lengthinputexecutionoveritsinnite-lengthrun.BecausenoMRAcanenforcethislivenesspropertytermination,therearealsosomenonsafety-nonlivenesspropertiesproper-tiesunenforceablebyMRAs,whichwecanobtainbytakingtheconjunctionofterminationandanysafetyproperty;anMRAcannotnotenforcesuchanonsafety-nonlivenessproperty20

PAGE 26

Figure4.1.Relationshipsbetweensafety,liveness,andMRA-enforceableproperties.forthesamereasonitcannotenforcetheterminationpropertyalone.Figure4.1summarizesallofthesendings.21

PAGE 27

CHAPTER5RELATEDWORKANDCONCLUSIONS5.1RelatedWorkInthepastdecadeseveralresearchershavemodeledruntimeprogrammonitorsasse-curityautomataandanalyzedtheirenforcementpowers;arecentarticlesurveystheseresults[3].Tobrieysummarizepreviouswork:Schneidershowedthattruncationau-tomatawhichacceptvalidapplicationactionsandhalttargetapplicationsuponinputtinginvalidactionsenforceonlysafetyproperties[2];Viswanathan,Kim,andothersrenedthesesafetyboundsbyaddingcomputabilityconstraintstothesafetypropertiesbeingen-forced[16,17];Fongshowedthattruncationautomatawithlimitedmemorye.g.,withspacetostoreonlyaboundednumberofactionsseencanstillenforcepracticallyusefulsafetypolicies[18];WalkerandAktugetal.presentedtechniquesforstaticallyguaranteeingthatpoliciesrepresentedbytruncationautomatagetenforcedatruntime[19,20,10];Dam,Jacobs,Lundblad,andPiessensfoundthatseparatingmonitorablemultithreadedapplica-tioncodefromunmonitorableJavaAPIcodepreventsinlinedtruncationautomatafromenforcingsomesafetypropertiestheycouldotherwiseenforce[21];LeGuernicetal.andHamlenetal.consideredsomeenforcementcapabilitiesofruntimesecurityautomatawithaccesstosourcecode[22,23,15];Ligatti,Bauer,andWalkerdenedexecution-transformingmonitorscallededitautomata,denedpolicyenforcementinthepresenceofeditautomata,andfoundthateditautomataenforcereasonablerenewalproperties[3,24];andFalcone,Fernandez,andMouniercomparedthesetofpropertiesenforceablewithedit-automata-likemonitorswiththesafety-progresshierarchyofpropertiesasdenedbyChang,Manna,and22

PAGE 28

Pnueli[25][26].Inaddition,securityautomatahaveformedthebasisofseveralpolicy-specicationlanguages[7,14,8,10].Someofthesecurity-automata-relatedresearchmentionedabovehasconsideredresultsofactions[20,10,21],butinallthesecasesthemodelshavebeenconstructedtohandlethespeciccaseofmonitoringJavaAPImethodsinvokedbyJavaapplications.Also,thesepreviousmodelstreatresultsaskindsofactions.Treatingresult-returnsasactionsposesnoproblemsinthesemodelsbecausetheyconsidermonitorstobetruncationautomata,whichalwaysacceptvalidactionsandresultsandhaltthetargetwhenencounteringaninvalidactionorresult.Incontrast,thisthesisgivesmonitorsthepracticalabilitytoediti.e.,transformactionsandresults,whichforcesustodeneanewoperationalsemanticsforsecurityautomatathatcarefullydistinguishesbetweenhowtheautomatacaneditactionsandresultsbecausethemonitorscanfreelyoutputanynumberofactionsforeveryactioninputbutmayonlyoutputatmostoneresultforeveryactioninputandcannotinputanewactionuntilaresultforthecurrentinputactionhasbeenoutput.5.2ConclusionThisthesishaspresentedamodelofruntimemonitorsthatimprovesonexistingmodelsbycapturingtherealisticconstraintthatmonitorsmustreturnaresultforoneactionbeforebeingabletoseethenextactionwhichtheapplicationmaygeneratebasedontheresultoftherstaction.Incorporatingresultsintothemodelandobligatingmonitorstoreturnpossiblyvoidorunitresultsforallmonitoredactionspreventsthemonitorsfromenforcingsomeproperties,butmonitorsmodeledbyMRAscannonethelessenforceastrictsupersetofthesafetypolicies.Thesendingsareimportantbecausetheyimproveourunderstandingofthesortsofpolicieswecaneverhopetoenforcedynamicallyinsystemswithsynchronousactions.Wehopethatwithcontinuedresearch,wewillbeabletodevelopalgorithmsfordecompos-inggeneralpoliciesintostaticallyanddynamicallyenforceablesubpolicies,suchthatwe23

PAGE 29

couldenforceamaximumsetofpolicyconstraintsstaticallyandtheremainingconstraintsdynamically.24

PAGE 30

REFERENCES[1]BowenAlpernandFredB.Schneider.Deningliveness.InformationProcessingLetters,21:181{185,October1985.[2]FredB.Schneider.Enforceablesecuritypolicies.ACMTransactionsonInformationandSystemsSecurity,3:30{50,February2000.[3]JayLigatti,LujoBauer,andDavidWalker.Run-timeenforcementofnonsafetypolicies.ACMTransactionsonInformationandSystemSecurity,12:1{41,January2009.[4]LeslieLamport.Provingthecorrectnessofmultiprocessprograms.IEEETransactionsofSoftwareEngineering,3:125{143,1977.[5]BowenAlpernandFredSchneider.Recognizingsafetyandliveness.DistributedCom-puting,2:117{126,1987.[6]DavidEvansandAndrewTwyman.Flexiblepolicy-directedcodesafety.InIEEESecurityandPrivacy,Oakland,CA,May1999.[7]UlfarErlingssonandFredB.Schneider.SASIenforcementofsecuritypolicies:Aretrospective.InProceedingsoftheNewSecurityParadigmsWorkshop,pages87{95,CaledonHills,Canada,September1999.[8]LujoBauer,JayLigatti,andDavidWalker.Composingexpressiveruntimesecuritypolicies.ACMTransactionsonSoftwareEngineeringandMethodology,18:1{43,2009.25

PAGE 31

[9]JayLigatti,BillyRickey,andNalinSaigal.LoPSiL:Alocation-basedpolicy-specicationlanguage.InInternationalICSTConferenceonSecurityandPrivacyinMobileInformationandCommunicationSystemsMobiSec,June2009.[10]IremAktugandKatsiarynaNaliuka.ConSpec{aformallanguageforpolicyspecica-tion.InProceedingsoftheFirstInternationalWorkshoponRunTimeEnforcementforMobileandDistributedSystems,September2007.[11]JayLigatti,LujoBauer,andDavidWalker.Editautomata:Enforcementmechanismsforrun-timesecuritypolicies.InternationalJournalofInformationSecurity,4{2:2{16,February2005.[12]JayLigatti,LujoBauer,andDavidWalker.Enforcingnon-safetysecuritypolicieswithprogrammonitors.In10thEuropeanSymposiumonResearchinComputerSecurityESORICS,Milan,Italy,September2005.[13]JayLigatti,LujoBauer,andDavidWalker.Editautomata:Enforcementmechanismsforrun-timesecuritypolicies.TechnicalReportTR-681-03,PrincetonUniversity,May2003.[14]UlfarErlingsson.TheInlinedReferenceMonitorApproachtoSecurityPolicyEnforce-ment.PhDthesis,CornellUniversity,November2003.[15]KevinHamlen,GregMorrisett,andFredB.Schneider.Computabilityclassesforenforcementmechanisms.ACMTransactionsonProgammingLanguagesandSystems,28:175{205,January2006.[16]MaheshViswanathan.FoundationsfortheRun-timeAnalysisofSoftwareSystems.PhDthesis,UniversityofPennsylvania,2000.[17]MoonjooKim,SampathKannan,InsupLee,OlegSokolsky,andMaheshViswantathan.Computationalanalysisofrun-timemonitoring|fundamentalsofJava-MaC.InRun-timeVerication,June2002.26

PAGE 32

[18]PhilipW.L.Fong.Accesscontrolbytrackingshallowexecutionhistory.InIEEESymposiumonSecurityandPrivacy,Oakland,CA,May2004.[19]DavidWalker.Atypesystemforexpressivesecuritypolicies.InTwenty-SeventhACMSymposiumonPrinciplesofProgrammingLanguages,pages254{267,Boston,January2000.[20]IremAktug,MadsDam,andDilianGurov.Provablycorrectruntimemonitoring.InProceedingsofthe15thInternationalSymposiumonFormalMethods,May2008.[21]MadsDam,BartJacobs,AndreasLundblad,andFrankPiessens.Securitymonitorinliningformultithreadedjava.InProceedingsoftheEuropeanConferenceonObject-OrientedProgrammingECOOP,July2009.[22]GurvanLeGuernic,AnindyaBanerjee,ThomasJensen,andDavidA.Schmidt.Automata-basedcondentialitymonitoring.InProceedingsoftheAsianComputingScienceConferenceASIAN,December2006.[23]GurvanLeGuernic.Automaton-basedcondentialitymonitoringofconcurrentpro-grams.InProceedingsoftheComputerSecurityFoundationsSymposiumCSF,pages218{232,July2007.[24]JayLigatti.PolicyEnforcementviaProgramMonitoring.PhDthesis,PrincetonUni-versity,June2006.[25]EdwardChang,ZoharManna,andAmirPnueli.Characterizationoftemporalpropertyclasses.InProceedingsofAutomata,LanguagesandProgramming,volume623ofLNCS,pages474{486.Springer-Verlag,1992.[26]YliesFalcone,Jean-ClaudeFernandez,andLaurentMounier.Enforcementmonitor-ingwrt.thesafety-progressclassicationofproperties.InProceedingsofthe24thAnnualACMSymposiumonAppliedComputing|SoftwareVericationandTestingTrackSAC-SVT,2009.27


xml version 1.0 encoding UTF-8 standalone no
record xmlns http:www.loc.govMARC21slim xmlns:xsi http:www.w3.org2001XMLSchema-instance xsi:schemaLocation http:www.loc.govstandardsmarcxmlschemaMARC21slim.xsd
leader nam 2200373Ka 4500
controlfield tag 001 002317625
005 20100903141236.0
007 cr bnu|||uuuuu
008 100903s2009 flua ob 000 0 eng d
datafield ind1 8 ind2 024
subfield code a E14-SFE0003078
040
FHM
c FHM
035
(OCoLC)660838938
049
FHMM
090
QA76 (Online)
1 100
Reddy, Srikar Reddy.
0 245
Program monitoring in a mandatory-results model
h [electronic resource] /
by Srikar Reddy Reddy.
260
[Tampa, Fla.] :
b University of South Florida,
2009.
500
Title from PDF of title page.
Document formatted into pages; contains 27 pages.
502
Thesis (M.S.C.S.)--University of South Florida, 2009.
504
Includes bibliographical references.
516
Text (Electronic thesis) in PDF format.
3 520
ABSTRACT: In many real enforcement systems, a security-relevant action must return a result before the application program that invoked that action can continue to execute. However, current models of runtime mechanisms do not capture this requirement on results being returned to application programs; current models are limited to reasoning about policies and enforcement in terms of actions alone, without considering the results of those actions. This thesis presents a more general model of runtime policy enforcement in which all actions return (possibly void- or unit-type) results. This mandatory-results model more accurately reflects the capabilities and limitations of real enforcement mechanisms, particularly those mechanisms that operate by monitoring function/method invocations. We analyze the new model to show that result-returning runtime monitors enforce a strict superset of the safety policies, including some nontrivial liveness policies.
538
Mode of access: World Wide Web.
System requirements: World Wide Web browser and PDF reader.
590
Advisor: Jay Ligatti, Ph.D.
653
Security policies
Safety
Liveness
Security automata
Policy enforcement
690
Dissertations, Academic
z USF
x Computer Science
Masters.
773
t USF Electronic Theses and Dissertations.
4 856
u http://digital.lib.usf.edu/?e14.3078