Program monitoring in a mandatory-results model

Citation
Program monitoring in a mandatory-results model

Material Information

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

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.
General Note:
Title from PDF of title page.
General Note:
Document formatted into pages; contains 27 pages.
Statement of Responsibility:
by Srikar Reddy Reddy.

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:
002317625 ( ALEPH )
660838938 ( OCLC )
E14-SFE0003078 ( USFLDC DOI )
e14.3078 ( USFLDC Handle )

Postcard Information

Format:
Book

Downloads

This item has the following downloads:


Full Text
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



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


printinsert_linkshareget_appmore_horiz

Download Options

close
Choose Size
Choose file type
Cite this item close

APA

Cras ut cursus ante, a fringilla nunc. Mauris lorem nunc, cursus sit amet enim ac, vehicula vestibulum mi. Mauris viverra nisl vel enim faucibus porta. Praesent sit amet ornare diam, non finibus nulla.

MLA

Cras efficitur magna et sapien varius, luctus ullamcorper dolor convallis. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Fusce sit amet justo ut erat laoreet congue sed a ante.

CHICAGO

Phasellus ornare in augue eu imperdiet. Donec malesuada sapien ante, at vehicula orci tempor molestie. Proin vitae urna elit. Pellentesque vitae nisi et diam euismod malesuada aliquet non erat.

WIKIPEDIA

Nunc fringilla dolor ut dictum placerat. Proin ac neque rutrum, consectetur ligula id, laoreet ligula. Nulla lorem massa, consectetur vitae consequat in, lobortis at dolor. Nunc sed leo odio.