Tải bản đầy đủ - 0 (trang)
Chapter 5. Designing Trusted Operating Systems

Chapter 5. Designing Trusted Operating Systems

Tải bản đầy đủ - 0trang

Wesaythatanoperatingsystemistrustedifwehave

confidencethatitprovidesthesefourservicesconsistentlyand

effectively.Inthischapter,wetakethedesigner'sperspective,

viewingatrustedoperatingsystemintermsofthedesignand

functionofcomponentsthatprovidesecurityservices.Thefirst

foursectionsofthischaptercorrespondtothefourmajor

underpinningsofatrustedoperatingsystem:

Policy.Everysystemcanbedescribedbyitsrequirements:

statementsofwhatthesystemshoulddoandhowitshould

doit.Anoperatingsystem'ssecurityrequirementsareaset

ofwell-defined,consistent,andimplementablerulesthat

havebeenclearlyandunambiguouslyexpressed.Ifthe

operatingsystemisimplementedtomeetthese

requirements,itmeetstheuser'sexpectations.Toensure

thattherequirementsareclear,consistent,andeffective,

theoperatingsystemusuallyfollowsastatedsecurity

policy:asetofrulesthatlayoutwhatistobesecuredand

why.Webeginthischapterbystudyingseveralsecurity

policiesfortrustedoperatingsystems.

Model.Tocreateatrustedoperatingsystem,thedesigners

mustbeconfidentthattheproposedsystemwillmeetits

requirementswhileprotectingappropriateobjectsand

relationships.Theyusuallybeginbyconstructingamodelof

theenvironmenttobesecured.Themodelisactuallya

representationofthepolicytheoperatingsystemwill

enforce.Designerscomparethemodelwiththesystem

requirementstomakesurethattheoverallsystem

functionsarenotcompromisedordegradedbythesecurity

needs.Then,theystudydifferentwaysofenforcingthat

security.Inthesecondpartofthischapterweconsider

severaldifferentmodelsforoperatingsystemsecurity.

Design.Afterhavingselectedasecuritymodel,designers

chooseameanstoimplementit.Thus,thedesigninvolves



bothwhatthetrustedoperatingsystemis(thatis,its

intendedfunctionality)andhowitistobeconstructed(its

implementation).Thethirdmajorsectionofthischapter

addresseschoicestobemadeduringdevelopmentofa

trustedoperatingsystem.

Trust.Becausetheoperatingsystemplaysacentralrolein

enforcingsecurity,we(asdevelopersandusers)seeksome

basis(assurance)forbelievingthatitwillmeetour

expectations.Ourtrustinthesystemisrootedintwo

aspects:features(theoperatingsystemhasallthe

necessaryfunctionalityneededtoenforcetheexpected

securitypolicy)andassurance(theoperatingsystemhas

beenimplementedinsuchawaythatwehaveconfidenceit

willenforcethesecuritypolicycorrectlyandeffectively).In

thefourthpartofthischapterweexplorewhatmakesa

particulardesignorimplementationworthyoftrust.

Thechapterendswithsomeexamplesofactualtrusted

operatingsystems.Severalsuchsystemshavebeenwritten,

andmoreareunderdevelopment.Insomecases,thesecure

systemswereoriginallydesignedforsecurity;inothers,

securityfeatureswereaddedtoexistingoperatingsystems.Our

examplesshowthatbothapproachescanproduceasecure

operatingsystem.







5.1.WhatIsaTrustedSystem?

Beforewebegintoexamineatrustedoperatingsystemin

detail,letuslookmorecarefullyattheterminologyinvolvedin

understandinganddescribingtrust.Whatwouldittakeforusto

considersomethingsecure?Thewordsecurereflectsa

dichotomy:Somethingiseithersecureornotsecure.Ifsecure,

itshouldwithstandallattacks,today,tomorrow,andacentury

fromnow.Andifweclaimthatitissecure,youeitheraccept

ourassertion(andbuyanduseit)orrejectit(andeitherdonot

useitoruseitbutdonottrustit).Howdoessecuritydiffer

fromquality?Ifweclaimthatsomethingisgood,youareless

interestedinourclaimsandmoreinterestedinanobjective

appraisalofwhetherthethingmeetsyourperformanceand

functionalityneeds.Fromthisperspective,securityisonlyone

facetofgoodnessorquality;youmaychoosetobalance

securitywithothercharacteristics(suchasspeedoruser

friendliness)toselectasystemthatisbest,giventhechoices

youmayhave.Inparticular,thesystemyoubuildorselectmay

beprettygood,eventhoughitmaynotbeassecureasyou

wouldlikeittobe.

Wesaythatsoftwareistrustedsoftwareifweknowthatthe

codehasbeenrigorouslydevelopedandanalyzed,givingus

reasontotrustthatthecodedoeswhatitisexpectedtodoand

nothingmore.Typically,trustedcodecanbeafoundationon

whichother,untrusted,coderuns.Thatis,theuntrusted

system'squalitydepends,inpart,onthetrustedcode;the

trustedcodeestablishesthebaselineforsecurityoftheoverall

system.Inparticular,anoperatingsystemcanbetrusted

softwarewhenthereisabasisfortrustingthatitcorrectly

controlstheaccessesofcomponentsorsystemsrunfromit.For

example,theoperatingsystemmightbeexpectedtolimit

users'accessestocertainfiles.

Totrustanyprogram,webaseourtrustonrigorousanalysis



andtesting,lookingforcertainkeycharacteristics:

Functionalcorrectness.Theprogramdoeswhatitis

supposedto,anditworkscorrectly.

Enforcementofintegrity.Evenifpresentederroneous

commandsorcommandsfromunauthorizedusers,the

programmaintainsthecorrectnessofthedatawithwhichit

hascontact.

Limitedprivilege:Theprogramisallowedtoaccesssecure

data,buttheaccessisminimizedandneithertheaccess

rightsnorthedataarepassedalongtootheruntrusted

programsorbacktoanuntrustedcaller.

Appropriateconfidencelevel.Theprogramhasbeen

examinedandratedatadegreeoftrustappropriateforthe

kindofdataandenvironmentinwhichitistobeused.

Trustedsoftwareisoftenusedasasafewayforgeneralusers

toaccesssensitivedata.Trustedprogramsareusedtoperform

limited(safe)operationsforuserswithoutallowingtheusersto

havedirectaccesstosensitivedata.

Securityprofessionalsprefertospeakoftrustedinsteadof

secureoperatingsystems.Atrustedsystemconnotesonethat

meetstheintendedsecurityrequirements,isofhighenough

quality,andjustifiestheuser'sconfidenceinthatquality.That

is,trustisperceivedbythesystem'sreceiveroruser,notbyits

developer,designer,ormanufacturer.Asauser,youmaynotbe

abletoevaluatethattrustdirectly.Youmaytrustthedesign,a

professionalevaluation,ortheopinionofavaluedcolleague.

Butintheend,itisyourresponsibilitytosanctionthedegreeof

trustyourequire.

Itisimportanttorealizethattherecanbedegreesoftrust;



unlikesecurity,trustisnotadichotomy.Forexample,youtrust

certainfriendswithdeepsecrets,butyoutrustothersonlyto

giveyouthetimeofday.Trustisacharacteristicthatoften

growsovertime,inaccordancewithevidenceandexperience.

Forinstance,banksincreasetheirtrustinborrowersasthe

borrowersrepayloansasexpected;borrowerswithgoodtrust

(credit)recordscanborrowlargeramounts.Finally,trustis

earned,notclaimedorconferred.ThecomparisoninTable5-1

highlightssomeofthesedistinctions.

Table5-1.QualitiesofSecurityandTrustedness

Secure



Trusted



Either-or:Somethingeitherisoris Graded:Therearedegreesof

notsecure.

"trustworthiness."

Propertyofpresenter



Propertyofreceiver



Assertedbasedonproduct

characteristics



Judgedbasedonevidenceand

analysis



Absolute:notqualifiedastohow

used,where,when,orbywhom



Relative:viewedincontextofuse



Agoal



Acharacteristic



Theadjectivetrustedappearsmanytimesinthischapter,asin

trustedprocess(aprocessthatcanaffectsystemsecurity,or

aprocesswhoseincorrectormaliciousexecutioniscapableof

violatingsystemsecuritypolicy),trustedproduct(an

evaluatedandapprovedproduct),trustedsoftware(the

softwareportionofasystemthatcanbereliedupontoenforce

securitypolicy),trustedcomputingbase(thesetofall

protectionmechanismswithinacomputingsystem,including

hardware,firmware,andsoftware,thattogetherenforcea



unifiedsecuritypolicyoveraproductorsystem),ortrusted

system(asystemthatemployssufficienthardwareand

softwareintegritymeasurestoallowitsuseforprocessing

sensitiveinformation).Thesedefinitionsareparaphrasedfrom

[NIS91b].Commontothesedefinitionsaretheconceptsof

enforcementofsecuritypolicy

sufficiencyofmeasuresandmechanisms

evaluation

Instudyingtrustedoperatingsystems,weexaminecloselywhat

makesthemtrustworthy.







5.2.SecurityPolicies

Toknowthatanoperatingsystemmaintainsthesecuritywe

expect,wemustbeabletostateitssecuritypolicy.Asecurity

policyisastatementofthesecurityweexpectthesystemto

enforce.Anoperatingsystem(oranyotherpieceofatrusted

system)canbetrustedonlyinrelationtoitssecuritypolicy;

thatis,tothesecurityneedsthesystemisexpectedtosatisfy.

Webeginourstudyofsecuritypolicybyexaminingmilitary

securitypolicybecauseithasbeenthebasisofmuchtrusted

operatingsystemdevelopmentandisfairlyeasytostate

precisely.Then,wemovetosecuritypoliciesthatcommercial

establishmentsmightadopt.



MilitarySecurityPolicy

Militarysecuritypolicyisbasedonprotectingclassified

information.Eachpieceofinformationisrankedataparticular

sensitivitylevel,suchasunclassified,restricted,confidential,

secret,ortopsecret.Theranksorlevelsformahierarchy,and

theyreflectanincreasingorderofsensitivity,asshownin

Figure5-1.Thatis,theinformationatagivenlevelismore

sensitivethantheinformationinthelevelbelowitandless

sensitivethaninthelevelaboveit.Forexample,restricted

informationismoresensitivethanunclassifiedbutlesssensitive

thanconfidential.WecandenotethesensitivityofanobjectO

byrankO.Intherestofthischapterweassumethesefive

sensitivitylevels.



Figure5-1.HierarchyofSensitivities.



Informationaccessislimitedbytheneed-to-knowrule:

Accesstosensitivedataisallowedonlytosubjectswhoneedto

knowthosedatatoperformtheirjobs.Eachpieceofclassified

informationmaybeassociatedwithoneormoreprojects,called

compartments,describingthesubjectmatterofthe

information.Forexample,thealphaprojectmayusesecret

information,asmaythebetaproject,butstaffonalphadonot

needaccesstotheinformationonbeta.Inotherwords,both

projectsusesecretinformation,buteachisrestrictedtoonly

thesecretinformationneededforitsparticularproject.Inthis

way,compartmentshelpenforceneed-to-knowrestrictionsso

thatpeopleobtainaccessonlytoinformationthatisrelevantto

theirjobs.Acompartmentmayincludeinformationatonlyone

sensitivitylevel,oritmaycoverinformationatseveral

sensitivitylevels.Therelationshipbetweencompartmentsand

sensitivitylevelsisshowninFigure5-2.



Figure5-2.CompartmentsandSensitivityLevels.



Wecanassignnamestoidentifythecompartments,suchas

snowshoe,crypto,andSweden.Asinglepieceofinformation

canbecodedwithzero,one,two,ormorecompartmentnames,

dependingonthecategoriestowhichitrelates.Theassociation

ofinformationandcompartmentsisshowninFigure5-3.For

example,onepieceofinformationmaybealistofpublications

oncryptography,whereasanothermaydescribedevelopmentof

snowshoesinSweden.Thecompartmentofthisfirstpieceof

informationis{crypto};thesecondis{snowshoe,Sweden}.



Figure5-3.AssociationofInformationand

Compartments.



[Viewfullsizeimage]



Thecombinationiscalledtheclassor

classificationofapieceofinformation.Bydesignating

informationinthisway,wecanenforceneed-to-knowbothby

securitylevelandbytopic.

Apersonseekingaccesstosensitiveinformationmustbe

cleared.Aclearanceisanindicationthatapersonistrustedto

accessinformationuptoacertainlevelofsensitivityandthat

thepersonneedstoknowcertaincategoriesofsensitive

information.Theclearanceofasubjectisexpressedasa

combination.Thiscombinationhasthe

sameformastheclassificationofapieceofinformation.

Nowweintroducearelation ,calleddominance,onthesets

ofsensitiveobjectsandsubjects.Forasubjectsandanobject

o,



Wesaythatodominatess(orsisdominatedbyo)ifs o;

therelation istheopposite.Dominanceisusedtolimitthe

sensitivityandcontentofinformationasubjectcanaccess.A

subjectcanreadanobjectonlyif

theclearancelevelofthesubjectisatleastashighasthat

oftheinformationand

thesubjecthasaneedtoknowaboutallcompartmentsfor

whichtheinformationisclassified

Theseconditionsareequivalenttosayingthatthesubject

dominatestheobject.

Toseehowthedominancerelationworks,considerthe

concentriccirclesinFigure5-3.Accordingtotherelationships

depictedthere,informationclassifiedas

couldbereadbysomeoneclearedforaccessto
{Sweden}>or,butnotby

someonewithaclearanceorsomeone

clearedforor.

Militarysecurityenforcesbothsensitivityrequirementsand

need-to-knowrequirements.Sensitivityrequirementsare

knownashierarchicalrequirementsbecausetheyreflectthe

hierarchyofsensitivitylevels;need-to-knowrestrictionsare

nonhierarchicalbecausecompartmentsdonotnecessarily

reflectahierarchicalstructure.Thiscombinationalmodelis

appropriateforasettinginwhichaccessisrigidlycontrolledby

acentralauthority.Someone,oftencalledasecurityofficer,

controlsclearancesandclassifications,whicharenotgenerally

uptoindividualstoalter.



CommercialSecurityPolicies



Tài liệu bạn tìm kiếm đã sẵn sàng tải về

Chapter 5. Designing Trusted Operating Systems

Tải bản đầy đủ ngay(0 tr)

×