The TrustedBSD MAC Framework: Extensible Kernel Access Control forFreeBSD 5.0

�

RobertWatsonNetwork Associates Laboratories

Rockville, MDrwatson@nailabs.com

http://www.nailabs.com/

WayneMorrisonNetwork Associates Laboratories

Rockville, MDtewok@tislabs.com

ChrisVanceNetwork Associates Laboratories

Rockville, MDcvance@nailabs.com

http://www.nailabs.com/

Brian FeldmanFreeBSD Project

Rockville, MDgreen@FreeBSD.org

Abstract

We explore the requirements,design,and implemen-tation of the TrustedBSD MAC Framework. TheTrustedBSDMAC Framework, integratedinto FreeBSD5.0,providesaflexible framework for kernelaccesscon-trol extension,permitting extensionsto be introducedmoreeasily, andavoiding the needfor direct modifica-tion of distributedkernelsources.We alsoconsidertheperformanceimpactof theFramework on theFreeBSD5.0kernelin severaltestenvironments.

1 IntroductionAccesscontrolextensionshave proveda fertile field foroperatingsystemsecurityresearchover thepasttwentyyears:a varietyof methodshave beenemployedto ex-tendthesystemaccesscontrolpolicy at greatcostto thedevelopers,maintainers,andusersof the extendedsys-tems.Mostof approachesto securityextensionfall shorttwo vital areas:lack of supportby theoperatingsystemvendorfor variousprovidersof securityextensionsonthesystem,andthehighly redundantimplementationofsupportinfrastructurefor securityextensionproviders.

The TrustedBSD MAC Framework included inFreeBSD5.0 providesa generalfacility for extendingthe kernelaccesscontrol policy [8][18]. By providingcommonsecurityinfrastructureservices,suchaskernelobjectlabeling,andthe ability to instrumentkernelac-cesscontroldecisions,theFramework is capableof sup-porting a variety of policies implementedby differentvendors. This paperexploresthe design,implementa-tion andperformanceof the MAC Framework, aswellasits impacton policy designandthe FreeBSDkernelarchitecture.

�

First publishedin theProceedingsof theFREENIX Track: 2003USENIX AnnualTechnicalConference(FREENIX ’03)

2 The Desire For Access Control Exten-sions

FreeBSDservestwo primarymarkets: it is botha con-sumeroperatingsystemand a technologysourceforthird party operatingsystemsor high-end embeddedproducts. FreeBSDis directly employed as a produc-tion server andworkstationoperatingsystemon main-streami386, Alpha, and SPARC64 hardware. In thehigh-endembeddedmarket, it is usedas the basisfornetwork andstorageappliancedevicessuchasfirewalls,network-attachedstorage,and VPN devices; it is alsousedas a technologysourcefor third party operatingsystem,includingApple’sMac OSX Darwin kernel,aswell asby otheroperatingsystemvendors.

In thesethreeroles,FreeBSDis deployed in a widevarietyof environments,rangingfrom electronicchequeprocessingandpoint of saledevicesto web clusterde-ployment, firewall, and routing appliances. Each oftheseenvironmentshasdifferentsecurityrequirements,often requiring flexibility beyond that provided for bythetraditionalUNIX securityprotections.Especiallyinembeddednetwork environments,the requirementscanrangefrom simpleoperatingsystemhardeningto thein-troductionof mandatoryandfine-grainedsecuritypoli-cies.

3 Access Control Extension MechanismsSecurityresearchanddevelopmentliteratureis rife withapproachesto achieving operatingsystemaccesscontrolextensionwith (andwithout) the help of the operatingsystemvendor. Traditionaltrustedvariantsof commer-cial UNIX operatingsystemshave beenwritten by thevendorin responseto the needsof specificconsumers(suchasUS DoD) [12][5][9][10]. Typical practicehasbeento maintainadistinctionbetweenthebaseOSprod-

uctandthetrustedvariantin termsof maintenance,prod-uct identification,andprice. In addition,therearethirdpartyvendorswhodevelopandmarket trustedoperatingsystemextensions,often in closecoordinationwith theOSvendor[2]. Finally, thereis a broadrangeof accesscontrolresearchacrossmany operatingsystemsandper-formed in many forms [7] [14] [16]—most frequently,thiswork isperformedonopensourceoperatingsystemsdueto readyaccessto operatingsystemsourcecode.

In orderto successfullymaintaina securityextensionproductfor anoperatingsystem,accessto theoperatingsystemcodeis typically required,be it an opensourcesystem,or licensedfrom theclosedsourcevendor. Prod-uctmaintenanceraisesanumberof challenges,not leastthechallengeof trackingtheoperatingsystemvendor’sprimary productlife cycle, which is frequentlyincom-patible with the developmentcycle required for highassuranceproducts. Many practical impedimentsalsopresentthemselves: securityextensionshave their fin-gersdeepin the heartof the operatingsystem,touch-ing almostall elementsof the kernelsourcecode. Lo-cal securityextensionsinvariably conflict with vendor-provided securitypatches,as well as vendor-providedfeatureimprovementsover the OS developmentcycle.In addition,securityextensionsfrequentlyconflict withoneanotherif deployed in parallel, leadingnot only topotentiallyinconsistentpolicy behavior, but alsopossi-blebypassof protectionsprovidedbyoneof thepolicies.Direct sourcecodemodificationof thevendoroperatingsystempresentsmany challengesto securityextensionauthors.

In the past, researchhas been performedon howto most easily extend operatingsystemsecurity poli-cies, including into system-callinterpositiontechnolo-gies such as LOMAC [6], Generic Software Wrap-pers[7], andsystrace[13], extensiblesecuritymecha-nismssuchasthe GeneralFramework for AccessCon-trol [1] andFLASK [16]. Many of theseextensiontech-nologies,especiallytheseusing systemcall wrappingtechniques,fall down in the faceof modernUNIX op-erating systemkernelswhich support true kernel anduserprocessparallelismin SMPenvironments,andfine-grainedthreadingof userprocesses.Preventingracesin-herentto systemcall wrappingis difficult, andmostsys-tem call wrappersecuritytechnologiesare susceptibleto at leastoneof a classof relatedvulnerabilities.Anysuccessfulextensiontechnologyfor contemporaryoper-atingsystemsmustbedesignedwith thenotionthatSMPandthreadingarerealities,andmustbe well-integratedinto thekernellockingmechanisms.

4 Motivations for MACMandatoryAccessControl (MAC) describesa broadclassof accesscontrolpolicies;in this context “manda-

tory” refersto the mandatoryimposition of the policyon non-administrative users. Popularmandatorypoli-cies including Multi-Level Security(MLS), which en-forces mandatoryprotectionsbasedon administrator-definedconfidentialitylabels,Biba integrity, which en-forces systemand user data integrity properties,andType Enforcement,which permitsthe administratortodefinesubjectdomains,object types,and usea policylanguageto controlaccessesto objectsandothersystemproperties.

Trustedoperatingsystemstypically provide two ormore mandatorysystempolicies: almost all provideMLS for userdataprotection,but many alsomake useof theBiba policy to protecttheintegrity of theTrustedCodeBase(TCB). TheTrustedBSDProject,in seekingto provide accessto trustedoperatingsystemfeatures,providesseveral MAC policies for usewith FreeBSD;the challengesassociatedwith this work include intro-ducing the servicessecurely, andwithout substantiallyimpactingthe performanceand reliability of FreeBSDinstallationsnot takingadvantageof thesenew features.

5 Framework Design and ImplementationTheTrustedBSDMAC Framework permitsaccesscon-trol policy modulesto be loadedinto theFreeBSDker-nel,providing a tightly integratedsecurityextensionve-hicle. In orderto addresstheproblemsidentifiedin Sec-tion 3 thereareseveralhigh-level goalsfor thedesign:

� Permitdynamicextensionof thekernelaccesscon-trol policy.

� Isolatethelogic of accesscontrolpoliciesfrom theimplementationof kernel services,permitting theimplementationsof servicesto be moremobile inthe faceof extensions,andreducingOS life cycleissuesfor policy developers.

� Permit multiple policies to be loadedsimultane-ouslywith someusefulnotionof composition.

� Reducethe redundantinfrastructureimplementa-tion efforts of policy writers by providing supportfor commonpolicy infrastructurerequirements.

� Integratetightly with thekernellockingandthread-ing mechanismsto provide correctnessand highperformancein modernkerneldesigns.

5.1 High Level DesignThe MAC Framework is madeup of a numberof ker-nel anduser-spaceelements.In thekernel,existing ker-nel servicesare modified to add datastructureexten-sionsandentrypointsto theMAC Framework, central-izedmanagementof labelstorage,registrationandman-agementof securitymodules,a seriesof systemcallsand sysctlsto permit applicationsto interact with la-belsandmanagethe framework, anda seriesof accesspolicy modulesthatmaybecompiledinto thekernelor

loadedvia loadablekernelmodules.In user-space,sev-eral new C library interfacesprovide accessto central-izedlabelconfigurationvia mac.conf, andchangestothelibutil userclassandsecuritycontext manage-mentcode. Commandline tools permit usermanipula-tion of file andprocesslabels,andmodificationsto stan-dardadministrative toolsmanagesystemlabels.

Figure1: High Level KernelDesign

TheMAC Framework addressesanumberof needsinaccesscontrolandextensionimplementation:

� Policiesareencapsulatedin kernelmodules,whichmaybelinkedinto thekernel,loadedaspartof theboot process,or loadedat run-timein responsetoenvironmentalrequirements.

� Policies are permitted to augmentkernel accesscontrol decision;sufficient locks to accessimpor-tant elementsof checkarguments,suchas objectreferences,areguaranteedto beheld.

� The MAC Framework provides a policy-agnosticlabelingservicepermittingpoliciesto maintainad-ditional meta-dataon a variety of systemobjects.Well-defined locking semanticsare provided forobject labels,andexisting locks on kernelobjectstypically alsoprotectany labelsin the object,per-mitting atomicchecksof both labelsandexistingobject propertieswithout additionallocking over-head.

� Policiesmay back labelsinto persistentextendedattributesprovided by UFS andUFS2,permittinglabelsonfile systemobjectsto bemaintainedwhilethey arenot in thein-memoryworkingset.

� When multiple policies are loaded, their accesscontrol decisionsare usefully composed,wherethe definition of “useful” is that resultsare well-defined,may be reasonedabout,andaredesirablein thecontext of a numberof relevantpolicies.

� Policiesmay make useof a policy-agnosticlabelmanagementAPI to export accessto label datatouserprocesses,aswell aspermit the managementof thoselabels.

5.2 Kernel Services and ObjectsTheMAC Framework enforcespolicy over a varietyofkernelsubsystemsandobjects,includingsystemconfig-urationinterfaces,processes,thefile system,IPC prim-itives, and the network stack. In general,two classesof modificationswere madeto existing kernel serviceproviders. First, servicesaremodifiedto invoke MACFrameworkentrypointsduringobjectmanagement,overthecourseof objectlife cycles,andwhenimportantac-cesscontrol events occur. Second,a numberof ker-neldatastructuresrepresentingsecurity-relevantobjectswere modified to include a label structureintendedtoholdextensiblesecurityinformation.

Figure 2: MAC Framework: Integration into KernelComponents

5.3 Entry PointsMAC Framework entrypoint invocationsarecondition-ally compiledinto kernelsubsystemsbasedon thecon-figuration parameteroptions MAC. Several classesof entry points exist, including label management,event notification, decisionfunctions,and accesscon-trol checks.All entrypointsacceptcontextual informa-tion; typically this includesa subjectprocesscredentialandaseriesof asobjects,objectlabelpointers,andcall-specificargumentssuchassignalnumbersor blockingdisposition.

Someentrypoints,suchasaccesscontrolchecks,re-turn error values;othernotificationentry pointsareas-sumedalways to succeed.Frequently, a set of relatedentry point invocationswill be madearoundcomplexoperations:for example,accesscontrol checksare re-quiredto createa new object in the file systemnames-pace.Likewise,whenlabelmodificationsoccur, a two-phasecommitisperformedby theFramework to confirmthatall policieswill permittherelabel,andthento notifyall policiesto performtheactualoperation.

Entry pointsarecurrentlyfoundin thecross-filesys-temVFS code,device file system,mount/umountcode,protocol-independentsocket calls, pipe IPC code,BPF

packet sniffing code,IP fragmentreassembly, IP socketsendand receive code,network interfacetransmissionanddelivery, credentialandprocessmanagementcode(including debugging,scheduling,signaling,andmon-itoring interfaces),kernelenvironmentalvariableman-agement,kernel modulemanagement,per-architecturesystemcalls,swap spacemanagement,anda varietyofadministrativeinterfacessuchastimemanagement,NFSservice,sysctl(), andsystemaccounting.Theseen-try pointspermitpoliciesto augmentsecuritydecisionsin a varietyof forms.

5.4 LabelsWhile somesystemhardeningmodelsemploy existingsubjectand object information (UNIX credentialdata,file permissions,...) a numberof importantmandatorypolicies requireadditionalsubjectand object labeling.For example,theMLS confidentialitypolicy makesde-cisionsbasedon subjectand object sensitivity labels:subjectsare assignedclearances,and objects are as-signedclassifications.Whenpoliciesrequireadditionallabels, the MAC Framework supportsthem throughapolicy-agnosticlabeling primitive, which permitspoli-ciesto tag kernelobjectswith informationrequiredforpolicy decision-making.

Figure 3: MAC Framework: Policy-Agnostic LabelStorage

The label structurestoredin kerneldatastructuresismaintainedby the MAC Framework: basedon the lifecycleof thedatastructure,theFramework providesper-objectentrypointsfor memoryinitialization, objectal-location,andobjectdestruction.Thelabelstructurecon-sistsanarrayof slots,eachproviding aunionof avoid* pointerandalong; slotsareallocatedto policiesre-

quiring labelstoragefor usein apolicy-specificmanner.Policy writers might chooseto storean integer value,allocateper-label memory, or make useof referencedstructuresrelying on the initialization and destructioncalls to maintain referencecounts. Initialization callswill often be usedfor memoryallocation,and in somecasesa blocking dispositionwill be passedasan argu-mentto the call indicatingwhetherblocking allocationis permitted;in thesecasesthe initialization call is per-mittedto returna memoryallocationfailure,which willaborttheallocationof theobject.

Label storageis currently provided in the followingkernelobjects:BPFdescriptors,processcredentials,de-vfs directoryentries,network interfaces,IP fragmentre-assemblyqueues(IPQ), sockets,pipes,mbufs, file sys-tem mountpoints,processes,andvnodes. A blockingdispositionis provided for mbuf, socket, and IPQ ini-tialization;if a failureoccursduringlabelallocation,thembuf andsocketallocatorcodewill returnamemoryex-haustionfailureto theconsumer. Unlikemostotherker-nel objects,memoryto hold thembuf label is not storedwithin the mbuf structureitself: instead,it is storedinan m tag hungoff the mbuf headerm tag chain. Tagsto hold MAC datawill be allocatedonly whenpoliciesrequiringMAC labelson mbufs arepresentin the sys-tem.Thispermitsimprovednetwork performanceof theMACFramework in scenarioswhereflexibleaccesscon-trol is required,but wherembuf labelingis not.

Additional supportfor persistentlabelstorageis pro-videdby any file systemsupportingextendedattributes,including UFS1 and UFS2; while policies can deter-minewhetherandhow theattributesareboundto policy-specificlabels,theFramework constructstransactionstoread,write, and cachevnodelabelson supportingfilesystems.

This flexibility supportsa wide variety of behaviorsrequiredfor many interestingandusefulaccesscontrolpolicies.

5.5 CompositionHardenedor trustedsystemsarefrequentlyshippedwitha numberof active (andhencecomposed)securitypoli-cies.For example,many traditional“trusted”UNIX sys-temsincludethe standardUNIX accesscontrol model,local discretionaryextensionsto that model (such asACLs), the Multi-Level Security (MLS) confidential-ity model protectinguserdata,and the Biba integritymodelprotectingtheintegrity of theTrustedCodeBase(TCB) [3] [4]. Likewise, locally maintainedsecurityextensionsarefrequentlydeployedin combinationwithexistingsystemsecuritypolicies,formingcohesive(andideally stronger)protection.As theMAC Framework isintendedto assistvendorsin combiningsecuritycompo-nentsto be deployed in a variety of environments,the

MAC Framework supportsthe simultaneousloadingofseveralmodules.While it maynot bepossibleto coher-ently (or even safely)composeall accesscontrol poli-cies, the MAC Framework providesa simplecomposi-tion model that hasproven useful in existing shippedsystems:rights intersection. This compositionlargelymaintainsandassumesindependencebetweentheactivepolicies,composingtheir behaviorsonly for two classesof operations:

� Access control checks. A precedenceoperatorcom-posestheresultsof anaccesscontroldecision;thepracticalimpactof this approachis that if any pol-icy deniesaccessto anobjector operation,thentheMAC Framework will returnanaccessdenialto thekernelservice. However, the precedenceoperatoralsohastheeffectof sorting“Objectnot found” er-rorsbefore“Accessdenied”errors,providing someusefulprecedencebehavior wheninformationflowpoliciesarepresent.

� User label requests. Policiesarepermittedto denyaccessto relabelobjectseven if the label changerequestpertainsonly to label elementsmaintainedby otherpolicies. This hasutility in a numberofsituations,including in thefollowing example: theBiba integrity policy mayforbid thechangingof anMLS sensitivity labelon a high integrity objectbya low integrity subject,sincethechangingof a la-bel might constitutean informationflow operationfrom theperspectiveof theBiba policy.

The samecompositionmodel is employed to com-bineresultsfrom thenative UNIX accesscontrolmodelandany modelsaddedusingtheMAC Framework. Cur-rently, thetaskof determiningwhethertwo policiesmaybesafelycomposedis left to thesystemdesigneror ad-ministrator, a reasonablerequirementfor many of thedeployedenvironmentsof interest.

5.6 Policy Modules

Policiesare typically encapsulatedin a kernelmodule,althoughthey mayalsobedirectly linkedto thekernel.Policy modulesconsistof several elements(someop-tional):

� Configuration. Optional configurationparametersfor thepolicy.

� Policy logic. Optional abstractedand centralizedimplementationof thepolicy’saccesscontrollogic.

� Labeling. Optionalsupportfor initializing, main-taining,anddestroying labelsonselectedobjects.

� Label APIs. Optionalsupportfor userprocessin-spectionandmodificationof labelson selectedob-jects.

� Accesscontrol. Implementationof selectedaccesscontroleventsthatareof interestto thepolicy.

� Policy events. Optional implementationof policyinitialization anddestructionevents.

� Declaration.Declarationof policy moduleidentity,policy moduleproperties,andregistrationof rele-vantpolicy operations.

5.7 Application InterfacesTheMAC Framework providessupportfor a numberofclassesof security-awareapplications,includingpolicy-agnostic or policy-aware labeling tools, and the lo-gin/usercontext managementcontext routines. This ispossibledue to the policy-agnosticlabel managementlibrary and systemcalls, which allow applicationstodealwith MAC labelsandelementsin anabstractman-ner. The following functionsare available to applica-tionslinkedagainsttheC library:

Retrieve the label of current or arbitrary process;set the current process label. mac get pid(),mac get proc(), mac set proc().

Get and set file or pipe label by file descriptor.mac get fd(), mac set fd().

Getandsetfile labelby path;optionally follow sym-bolic links. mac get file(), mac set file(),mac get link(), mac set link().

Executea commandandatomicallymodify the pro-cesslabel.mac execve().

Policy-specific system call multiplexormac syscall().

Testfor thepresenceof theMAC Framework or aspe-cific policy mac is present().

Convert labels to and from human-readabletextmac from text(), mac to text().

Allocate storage for a label appropriate to holdthe specified label elements, or for a specificobject based on system default label elementsmac prepare(), mac prepare file label(),mac prepare ifnet label(),mac prepare process label().

Release storage associated with a labelmac free().

To support atomic changeof label with executionevents,mac execve() provides an extensionto theexisting execve() systemcall acceptinga requestedtarget label. This is required to support the ex-ecve secure() functionality used by the SEBSDport of FLASK/TE to FreeBSDfrom SELinux[11].

In addition, a generalsecurity policy entry point,mac security() is providedsothatpoliciesmayex-tend the setof systemserviceswithout allocatingnewsystemcall numbers.

6 Login Context ManagementMany labeledaccesscontrol policies assignuserpro-cesslabelson the basisof the identity of the userand

propertiesof the useraccount. Frequentlythis is per-formedin a role-basedmanner, wherea setof availablerolesis assignedto a user, andthentheusermayselecttheir active role from amongthe available roles. Thisassumesthe ability to assignan initial label during thelogin processor whenactingon behalfof theuser, andthen the ability to supportconstrainedmodificationofthe label basedon the initial login configuration. TheMAC Framework userprocesslabelingAPIs aresuffi-ciently flexible to supportthis behavior.

For an initial passat supportingautomaticlabelingat login, we extended the existing BSD login classdatabase.Themaster.passwd(5) assignsoneclassto eachuser;a classmaybesharedby many users,andincludesinformationsuchastheresourcerestrictionsfortheuser, login andaccountingproperties,etc. We intro-ducedtwo new fields:

Identifier Description

label Thetext form of thelabelto beassignedtouserprocessesaspartof thecontext managementprocess.

ttylabel Thelabelto assigntotheuser’s tty

Theexistingsetusercontext(3) interfaceis ex-tendedto supporta new flag LOGIN SETMAC, indicat-ing that the MAC label should be set as part of thelogin process. This flag is also implied by the LO-GIN SETALL flag usedwidely acrossprogramssettingusercontexts. Processlabeling tools, describedin thenext section,may then be usedto updatethe processlabel subjectto policy constraints. By instrumentingthis one function and its relevant consumers,we wereableto easilymodify mostkey systemdaemonsandap-plicationsto recognizethe new processproperties,in-cludingsendmail(8),cron(8),login(1),su(8),ftpd(8),in-etd(8)andothers,makingthechangesrelatively low im-pact. In the future, we may divorcethe label selectiondatabasefrom theclassdatabasefor thepurposeof im-provedmanagement,but this wouldnot requirechangesto theusercontext API.

7 Application IntegrationAs mostof theextensionspoliciesof interestaremanda-tory policies,many applicationsthathavespecificadap-tation to the systemdiscretionarypolicy do not requirechangesfor MAC. This occursbecauseobjectscreatedby processeswill have labelsautomaticallydeterminedbasedon the processlabel or other processproper-ties,ratherthanasapplication-providedarguments.TheTrustedBSDMAC implementationships with severaltools to permit usersto inspectandmaintainlabelson

objects,including:

Program Description

getpmac InspectprocessMAC labelssetpmac SetprocessMAC labelsgetfmac Inspectfile MAC labelssetfmac Setfile MAC labelssetfsmac Setfile MAC labelsbased

on aspecificationfile

In addition,thefollowing utilities werealsomodifiedto inspectandsetMAC labels:

Program Description

ifconfig Inspectandsetinterfacelabels

ps Inspectprocesslabelsls Inspectfile labels

Furtherextensionscould easily be madeto applica-tions suchasthe KDE file systembrowser, Konqueror,to displayandmanagelabelson file systemobjects.

8 Sample Policies

FreeBSD5.0 shipswith a numberof samplepolicies—many appropriatefor deploymentin productionsystems.Thesedemonstratesomeof the scopeof the capabili-ties of the MAC Framework, rangingfrom very simpleun-labeledinter-processvisibility protectionsto fully la-beledpolicy environmentssuchasTypeEnforcement.

� mac biba. Fixed-labelhierarchalBiba integritypolicy with compartments:assignsintegrity labelsto all systemsubjectsand objects, then enforcesan informationflow policy basedon limiting read-down andwrite-upoperations.

� mac bsdextended. File systemfirewall, main-tainsan accesscontrol rule list expressedin termsof UNIX credentials,file owners, and operationmasks.

� mac ifoff. Interfacesilencingpolicy, prohibit-ing unauthorizedoutput on network interfaces—appropriatefor use in environmentswhere silentmonitoringis required.

� mac lomac. Floating label hierarchalBiba in-tegrity policy based on the “Low watermark”scheme[7]: assignsintegrity labelsto all systemsubjectsandobjects,preventingwrite-upandforc-ing a subjectdowngradeon read-down.

� mac mls. Fixed-labelhierarchalMulti-Level Se-curity confidentiality policy with compartments:assignssensitivity labelsto all systemsubjectsandobjects,then enforcesan information flow policybasedon limiting write-down and read-upopera-tions.

� mac none. Stubpolicy providing prototypesforall policy entry points—astarting point for newpolicies.Also usefulfor raw performancemeasure-mentswithout thecostof labelingandaccesscon-trol events.

� mac partition. Simple labeledsystemparti-tioning policy, in which processesareassignedtosystempartitionsandvisibility of processesis lim-itedbasedon thelabelof a process.

� mac portacl. Add accesscontrollists to controlexplicit IPv4 andIPv6 socket bindingby protocol,port,anduid or gid.

� mac seeotheruids. Simple systempartition-ing policy, in which processvisibility is limitedbasedon theUNIX credentialof a process.

� mac test. Policy to exercisethe MAC Frame-work aswell astestits invariants.Checksto makesure the MAC Framework is correctly managingthe labelson objects,and instrumentingappropri-ateaccesscontrolchecks.

� sebsd. Port of the SELinux FLASK andTE im-plementationsto FreeBSD,providing accessto theFLASK security abstractions,Type Enforcementimplementation,andadaptationsof a maturesys-tempolicy.

A broadscopeof policies may be implementedus-ing the MAC Framework; the Framework is structuredsothatpolicy authorsmayselectwhatperformance,se-curity, and functionality trade-offs they wish to makein policy design,augmentingthesystempolicy in waysthatreflectlocalrequirements.Thisflexibility makestheMAC Framework ausefultool in abroadvarietyof envi-ronments,reflectingthevarietyof deploymentscenariosin which FreeBSDis used.

9 Performance ResultsThreeimportantperformancegoalswere kept in mindduring the designand implementationprocessfor theTrustedBSDMAC Framework:

� Minimize performanceimpactof theMAC Frame-work onsystemswhereit is disabled.

� Minimize theoverheadof theMAC Framework onsystemswhereit is enabledandpossiblyin use.

� Permit policy authors to make perfor-mance/security/complexity trade-offs local totheir policy basedon the requirementsfor thepolicy.

In this section, we explore someof the issuesas-sociatedwith performancemeasurementof the MACFramework. TheFramework is currentlyintegratedintothe FreeBSD5.0-CURRENTdevelopmentbranch—asa result,currentperformancemeasurementsareusedtoguide the developmentprocessand explore the even-

tual impact, ratherthanrepresentingfinal performanceresults. Substantialeffort hasnot yet beeninvestedinfine-grainedperformancetuning, althoughinitial mea-surementssuggestperformancewell within the boundsof acceptability.

For eachtest, we considerseveral kernel configura-tions:

� GENERIC:Base-linekernelwithoutMACsupport.� MAC: Kernelcompiledwith MAC support,but no

activesecuritypolicies.� MAC NONE: One active “stub” policy, imple-

menting all entry points but without additionallocking or logic.

� MAC BSDEXTENDED: One active “file systemfirewall” policy, implementingfile systemaccesscontrolentrypointsandmakinguseof alockedpol-icy.

� MAC BIBA: One active mandatoryintegrity pol-icy, implementingcomprehensive labelingandac-cesscontrolentrypointsfor all systemobjects.

TheGENERICkernelpermitsus to explorebaselineperformanceasa controlfor otherconfigurations;MACteststheoverheadto simply includeextensiblesecuritysupportin thesystemwith nopolicies.Thethreesamplepoliciesallow us to considertheoverheadof enteringapolicy modulefor eachentry point (MAC NONE), thecostof unlabeledfile systemprotectionsusinga lockedpolicy (MAC BSDEXTENDED),andthecostof a fullylabeledsystemintegrity policy touchingmostaspectsofsystemoperation(MAC BIBA).

Thesetestswere run on a FreeBSD5.0-CURRENTsystem from the trustedbsd mac developmentbranchfrom lateMarch,2003;testswererunonasingle-processor800MHz Intel PIII systemwith 128mb ofmemoryandATA 7200rpm20gbharddisk. For file sys-temrelatedbenchmarking,all writablefile systemswererecreatedusingthe samegeometrybetweentestssincefile systemagingeffectsarenotof interestfor thesetests;rebootsoccurbetweeneachtestto flushstorage-relatedcachesandresetslaballocatorandmbuf allocatorstate.All file systemsuseUFS2for high performancemeta-datastorage.

9.1 Kernel Compile Throughput

In thebuildkerneltest,we performa macro-benchmarkfocusedon systemthroughputrelying on effective CPUutilization, I/O performance,andfile systemmeta-dataperformance.In this test,a FreeBSDkernelsourcetreeis configuredandbuilt without modules(to reducetheI/O throughputdependency); time is measuredin wallclock duration from start to finish. Lower executiontimesarepreferred,indicatinghighersystemthroughputin completingthetask.

The resultsof this testdemonstratea small but mea-surableperformancechange(0.1%)with MAC support.A slight relative increasein cost for the BSD/extendedpolicy maybetheresultof acquiringapolicy lock in or-derto processanaccesscontroldecision;however, thereis no statisticallysignificantdifferencein performancebetweenthe variousMAC policiesandthebasecostofthe MAC Framework; UFS2 provides for high perfor-mancelabelaccessfor theBiba policy.

9.2 Network PerformanceThe MAC Framework introducessecurity label struc-tures into a variety of system data structures; ofthese,struct mbuf may be the most performance-sensitive. The mbuf structureprovides for optimizednetwork management,andhasbeenthe subjectof sub-stantial prior performancework, providing optimizedpacket constructionandparsing,copy-on-write seman-tics, zero-copy semantics,and fragmentationmanage-ment. From the perspective of MAC policy modules,only headermbufs areof interest,asthey representtheheaderfor a network packet or datagram. In our firstpassimplementation,we inserteda struct labeldirectly into them pkthdr datastructure;astheimple-mentationevolved,them tagmeta-dataservicebecameavailableon FreeBSD;this servicepermitschainingofarbitrarymeta-dataontombuf headerswithout modifi-cationof thebasestructure.

In them pkthdr approach,all kernelspayamemoryoverheadfor labelingsupport,althoughkernelswithoutoptions MAC do not pay the label life cycle costs.With them tag approach,only kernelswith optionsMAC pay the memory overhead,althoughwe presup-posedthat therewould be a highercost for using tagsfor labelstoragedueto greateradministrative overheadin maintaininglists andallocatingstorage.To optimizethe m tag approach,we implementedlazy tag alloca-tion: tagsareonly allocatedto hold label datawhenapolicy expressesinterestin labelingmbuf headers.

We consider two tests from the netperf suite:UDP RR andUDP STREAM, which respectively testtheper-transactioncostof a Request/ReceiveRPC,andrawnetwork throughput.Therequest/responsetestmeasuresthe throughputof the systemrelative to synchronousone-bytepacketsbetweenaclientandaserver, andis in-tendedto measurethe performanceimpactof a changein termsof numberof packets transfered.The streamtestusesalargerpacketsizeanddoesnotsynchronouslywait for aresponsebeforecontinuing,generallymeasur-ing theperformanceimpactof a changein termsof datatransferred.

In Figure5, theperformancecostper-packet is illus-trated:theintroductionof MACsupportproducesamea-surablechange;dependingon the strategy for labeling

mbufs, that changevariessubstantially. With inclusionof thelabeldirectly in thembuf header, an11.5%perfor-manceoverheadis acceptedfor enablingMAC support.Adding the stub policy increasesthat cost to 12.2%;addinga complex labeledpolicy performingper-labelmemoryallocation,suchasBiba, increasesthatdropto14.9%of theGENERICpacket throughput.

With lazym taglabeling,theperformancetrade-off ischanged:thecostof introducingMAC is 4.8%(substan-tially lessthanusingmbuf headers);with a stubpolicyimplementingmbuf labelentrypointsbut not allocatinglabels,that cost increasesto 8.5%(alsolessthanmbufheaders). However, performancewith a Biba perfor-manceis reducedby 17.1%,showing an increasedcostfor heavily labeledpoliciessuchasBiba.

The secondset of trade-offs best fits the needsofthe TrustedBSDProject: minimizeoverheadfor MAC-disabledsystems,andpermita performance/complexitycostdecisionby policy authors.

In Figure6, a similar patternemerges,where-intheintroductionof MAC supportresultsin a 6.1%through-put penalty. Useof a stubpolicy increasesthat costto7.7%;Biba labelingincreasesthecostto 10.3%. How-ever, with lazy m tag labeling, the basecost of MACsupportis reducedto 3.7%;thestubpolicy increasesthiscostto 4.4%,andwith Bibato 9.7%.Theproportionallylower performancecostwith this testderivesfrom thereducedrelativeoverheadresultingfrom reducedpacketcountsrelative to datatransfered.

Again, lazym tagallocationbettermeetsour require-mentsby permittingbetternon-MAC performancewitha moreclearperformancetrade-off for complexity. Un-like the packet count testing,performancefor the Bibapolicy actually increaseswith lazy m tags relative tombuf headers,a result that we attribute to differencesin thecachingandallocationpoliciesfor theUMA SlabAllocatorversusthembuf allocatorin handlingmemoryclearingfor new allocations.

629

629.5

630

630.5

631

631.5

632

632.5

633

generic mac mac_none mac_bsdextended mac_biba

Sec

onds

per

bui

ld

Kernel configuration

Figure4: Time to make buildkernel with variouskernelconfigurations(lower is better).

14500

15000

15500

16000

16500

17000

17500

18000

generic mac mac_none mac_bsdextended mac_biba

Tra

nsac

tions

/sec

�

Kernel configuration

m_pkthdr.labelm_tag always alloc

m_tag lazy alloc

Figure5: UDP request/responsethroughputover loopbackwith variousmbuf labelallocationapproaches(higherisbetter).

980

1000

1020

1040

1060

1080

1100

1120

1140

generic mac mac_none mac_bsdextended mac_biba

Mb/

s

�

Kernel configuration

m_pkthdr.labelm_tag always alloc

m_tag lazy alloc

Figure6: UDP streamthroughputover loopbackwith variousmbuf labelallocationapproaches(higheris better).

10 Related WorkSubstantialprior andcurrentwork existsrelatingto ker-nelaccesskernelandextensibility research.

In theareaof prior deployedsystems,“Trusted”vari-antsof mostcommercialUNIX platformsexist, includ-ing TrustedSolaris,andTrustedIRIX [15]. In addition,thereareanumberof thirdpartysecurityextensionprod-uctsthatexist for thesesystems,includingArgus’s Pit-Bull product,which providesa productalternative withmany of the samefeatures[2]. Theseproductslargelyrely on Multi-Level Security (MLS) [3] and Biba in-tegrity [4] to providemandatorydataconfidentialityandTCB integrity; earlier TrustedBSDwork has focusedon implementingsupport in FreeBSDfor thesemod-els using similar integration approaches[18][19][20].TrustedBSDMAC policy modulesexist expressingbothMLS andBiba in functionallysimilar forms.

In theareaof accesscontrolextensibility, earlyworkincludedtheGeneralizedFramework for AccessControl(GFAC), which proposesa separationof policy anden-forcement[1]; this model is implementedin Linux inRSBAC [14].

The FLASK framework provides for similar typesof separationof policy andenforcement,althoughwithhigher level labelingabstractionin the form of a secu-rity ID (SID) and a focus on Linux SecurityModules(LSM) providesa setof kernelextensionhooksto fa-cilitate integration of systemssuch as SELinux with-out committingthe Linux operatingsystemto a partic-ular model[17]. LSM providesa void pointerfor labelstoragein eachsupportedkernelobject,andhasaccesscontrolnotionssimilar to theTrustedBSDMAC Frame-work. However, thesemanticsof thehooksareweaker,and the LSM framework doesnot provide for policycompositionand persistentlabeling, relying on policymodulesto implementtheseservices.TypeEnforcementfor policy representation[16][11]. A prototypeport oftheSELinuxFLASK andTE implementationshasbeenmadeto layer on top of the TrustedBSDMAC Frame-work via theSEBSDpolicy module.

11 Future WorkFuturework ontheMAC Framework will likely fall intoa numberof areas:

� Improve the completenessand expressivenessoftheMAC Framework; increasethenumberof ker-nel objectsandmethodsthat areprotectedby theFramework to permitbroaderprotections.

� Maturetheexperimentalpolicy modules.� Continueto adaptand merge the SEBSD policy

module to run properly with FreeBSD:in partic-ular, determinehow bestto satisfythediffering re-quirementsof SEBSDandmostotherpoliciesre-

gardingprocesslabeltransitions.� ContinueportingtheMAC Framework andits poli-

ciesto Darwin andMacOSX.

12 ConclusionThe TrustedBSDMAC Framework providesa general-ized mechanismby which the FreeBSDkernelsecuritymodel can be augmentedat run-time. Along with theframework, we have alsoimplementeda numberof se-curity extensionmodulesthat rely solely on the frame-work to interfacewith existing kernelabstractions.Thisseparationof security extensionsfrom the actual ker-nel implementationof servicesimprovesthecapacityforthird partyprovidersto developandshipsystemsecurityextensionsby loweringthecostto developandmaintaintheextensions.Througha simplecompositionmodel,itis possibleto performa limited setof “useful” compo-sitionsof securityextensions.Preliminaryperformancemeasurementillustratesa measurablebut small perfor-mancecost for the framework and many policy mod-ules. the Framework permitspolicy authorsto selectcomplexity and performancetrade-offs basedon localrequirements,supportingbothsimplehardeningpoliciesandcomplex informationflow policies.

13 AcknowledgmentsThis researchwas supportedunder DARPA/SPAWARcontractN66001-01-C-8035(“CBOSS”).

The authorswould like alsoto thankthe anonymousreviewersof this paper, aswell asothercontributorstothe TrustedBSDProject,including Chris Faulhaber, Il-marHabibulin, AdamMigus, andThomasMoestl. Theauthorswouldalsolike to thankAngelosKeromytisandErezZadokfor their shepherdingof thispaper.

14 AvailabilityTheTrustedBSDMAC Framework is availableunderatwo-clauseBSD license,makingit appropriatefor openandclosed-source,research,educationalor commercialusewithout restriction. It is includedin FreeBSD5.0,as an experimentalfeature,and will matureover theFreeBSD5.x life time. More informationmaybefoundat:http://www.FreeBSD.org/http://www.TrustedBSD.org/

15 Bibliography

References[1] M. D. Abrams,K. W. Eggers,L. J. L. Padula,and

I. M. Olson. A generalizedframework for accesscontrol: An informal description. In Proc. 13thNIST-NCSC National Computer Security Confer-ence, pages135–143,1990.

[2] Argus products overview: Pitbull.http://www.argussystems.com/product/overview/pitbull/.

[3] D. E. Bell and L. J. LaPadula. Securecomputersystems: Mathematicalfoundationsand model.Technical Report M74-244, The MITRE Corp.,BedfordMA, May 1973.

[4] K. Biba. Integrity constraintsfor securecomputersystems,1977.

[5] N. C. C. I. Board. Commoncriteria version2.1(ISOIS 15408),2000.

[6] Fraser. LOMAC: Low water-markintegrity protec-tion for COTS environments. In RSP: 21th IEEEComputer Society Symposium on Research in Se-curity and Privacy, 2000.

[7] T. Fraser, L. Badger, andM. Feldman.HardeningCOTSsoftwarewith genericsoftwarewrappers.InIEEE Symposium on Security and Privacy, pages2–16,1999.

[8] FreeBSD Project. FreeBSD home page.http://www.FreeBSD.org/.

[9] N. S. A. InformationSystemsSecurityOrganiza-tion. Controlledaccessprotectionprofile version1.d,October1999.

[10] N. S. A. InformationSystemsSecurityOrganiza-tion. Labeledsecurityprotectionprofile version1.b,October1999.

[11] P. Loscoccoand S. Smalley. Integratingflexiblesupportfor securitypoliciesinto theLinux operat-ing system.Technicalreport,U.S.NationalSecu-rity Agency (NSA), Oct.2000.

[12] U. S. D. of Defense. Trusted Computer SystemEvaluation Criteria. Departmentof Defense,De-cember1985.

[13] N. Provos. Improving host se-curity with system call policies.http://www.citi.umich.edu/u/provos/systrace/.

[14] Rule setbasedaccesscontrol (RSBAC) for linux.http://www.rsbac.org/.

[15] SGI. B1 sample source code.http://oss.sgi.com/projects/ob1/.

[16] R. Spencer, S. Smalley, P. Loscocco,M. Hibler,D. Andersen,and J. Lepreau. The Flask secu-rity architecture:Systemsupportfor diversese-curity policies. In 8th USENIX Security Sympo-sium, pages123–139,Washington,D.C., USA,Aug. 1999.USENIX.

[17] G. S.Support.Linux securitymodules:.

[18] TrustedBSDProject. TrustedBSDhome page.http://www.TrustedBSD.org/.

[19] R. Watson. Introducingsupportinginfrastructurefor trustedoperatingsystemsupportin FreeBSD.In BSD Conference, Monterey, CA, USA, October2000.

[20] R. Watson. TrustedBSD:Adding TrustedOperat-ing SystemFeaturesto FreeBSD. In Proceedingsof the USENIX Annual Technical Conference, June2001.