Integrating Flexible Support for Security Policies into the Linux Operating System · 2018. 9. 11. · the design and implementation for integrating the secu-rity mechanisms of the

Integrating Flexible Supportfor Security Policies into theLinuxOperating System

PeterLoscocco,NSA, [email protected], NAI Labs,[email protected]

February2001

Contents

1 Intr oduction 2

2 Overview 3

2.1 Encapsulation of SecurityPolicy . . . . . 3

2.2 Flexibility in LabelingDecisions . . . . . 4

2.3 Flexibility in AccessDecisions. . . . . . 4

2.4 Support for Policy Changes. . . . . . . . 4

2.5 ProcessControls . . . . . . . . . . . . . 5

2.6 File Controls . . . . . . . . . . . . . . . 5

2.7 SocketControls . . . . . . . . . . . . . . 6

3 Security Server 7

3.1 ArchitectureTypesandConstants . . . . 7

3.2 Interfacesfor theKernel . . . . . . . . . 7

3.3 SystemCallsfor Applications . . . . . . 10

3.4 Policy ConfigurationLanguage . . . . . . 11

3.4.1 TE configuration . . . . . . . . . 12

3.4.2 RBAC configuration . . . . . . . 14

3.4.3 MLS configuration . . . . . . . . 15

3.4.4 Userconfiguration . . . . . . . . 15

3.4.5 Constraintsconfiguration . . . . . 16

3.4.6 Securitycontext configuration . . 16

3.5 Prototype Implementation . . . . . . . . 17

3.5.1 compute av . . . . . . . . . . . . 18

3.5.2 compute sid . . . . . . . . . . . . 18

3.5.3 sid to context . . . . . . . . . . . 19

3.5.4 context to sid . . . . . . . . . . . 19

3.5.5 load policy . . . . . . . . . . . . 19

3.5.6 Otherinterfaces. . . . . . . . . . 20

3.5.7 SystemCall Controls . . . . . . . 20

4 AccessVector Cache 20

4.1 Interfacesfor theKernel . . . . . . . . . 20

4.2 Interfacesfor theSecurityServer . . . . . 23

4.3 Implementation . . . . . . . . . . . . . . 24

5 ProcessManagement 25

5.1 Design. . . . . . . . . . . . . . . . . . . 25

5.1.1 ObjectClasses . . . . . . . . . . 25

5.1.2 Permissions. . . . . . . . . . . . 26

5.1.3 ControlRequirements . . . . . . 26

5.1.4 API extensions . . . . . . . . . . 29

5.2 Implementation . . . . . . . . . . . . . . 30

5.2.1 Labeling . . . . . . . . . . . . . 30

5.2.2 API Extensions . . . . . . . . . . 30


6 File System 32

6.1 Design. . . . . . . . . . . . . . . . . . . 32

6.1.1 ObjectClasses . . . . . . . . . . 32

6.1.2 Permissions. . . . . . . . . . . . 32


6.1.4 PersistentLabeling . . . . . . . . 36

6.1.5 API extensions . . . . . . . . . . 37

1 INTRODUCTION

6.2 Implementation . . . . . . . . . . . . . . 37

6.2.1 Labeling . . . . . . . . . . . . . 37

6.2.2 API extensions . . . . . . . . . . 38


7 Other File SystemTypes 417.1 Procfs . . . . . . . . . . . . . . . . . . . 41

7.1.1 ProcfsAnalysis . . . . . . . . . . 41

7.1.2 ProcfsLabelingDesign. . . . . . 42

7.1.3 ProcfsLabelingImplementation . 43

7.2 Devpts . . . . . . . . . . . . . . . . . . . 43

7.3 NFSclientsupport . . . . . . . . . . . . 44

8 Networking 448.1 Design. . . . . . . . . . . . . . . . . . . 44

8.1.1 ObjectClasses . . . . . . . . . . 44

8.1.2 Permissions. . . . . . . . . . . . 45


8.1.4 API extensions . . . . . . . . . . 48

8.2 Implementation . . . . . . . . . . . . . . 50

8.2.1 Labeling . . . . . . . . . . . . . 50

8.2.2 API extensions . . . . . . . . . . 52


9 SystemV IPC 559.1 Design. . . . . . . . . . . . . . . . . . . 55

9.1.1 ObjectClasses . . . . . . . . . . 55

9.1.2 Permissions. . . . . . . . . . . . 55


9.1.4 API extensions . . . . . . . . . . 57

9.2 Implementation . . . . . . . . . . . . . . 57

9.2.1 Labeling . . . . . . . . . . . . . 57

9.2.2 API Extensions . . . . . . . . . . 57


10 SystemCall Review 5810.1 ProcessManagement . . . . . . . . . . . 58

10.1.1 Scheduling . . . . . . . . . . . . 58

10.1.2 SessionsandProcessGroups . . . 58

10.1.3 UserandGroupIdentity . . . . . 59

10.1.4 Capabilities. . . . . . . . . . . . 59

10.1.5 Timers . . . . . . . . . . . . . . 59

10.1.6 ResourceLimits andUsage . . . 59

10.1.7 OtherProcessCalls . . . . . . . . 59

10.2 MemoryManagement . . . . . . . . . . . 60

10.3 File System . . . . . . . . . . . . . . . . 60

10.4 KernelModules . . . . . . . . . . . . . . 61

10.5 SystemOperations . . . . . . . . . . . . 61

11 To Do 62

Abstract

Theprotection mechanismsof current mainstreamop-eratingsystemsare inadequate to support confidential-ity andintegrity requirementsfor endsystems.To ad-dressthis problem,theNationalSecurityAgency (NSA)worked with SecureComputing Corporation (SCC) todevelop a strong, flexible mandatory accesscontrol ar-chitecturebasedonTypeEnforcement. Thearchitecture,now calledFlask,wasprototypedin theMachandFlukeresearchoperating systems.The NSA is now integrat-ing the Flaskarchitecture into the Linux operating sys-temto transferthe technology to a largerdeveloperandusercommunity. NAI Labs,SCC,andMITRE areas-sistingtheNSA in this integration. This paper presentsthe designandimplementationfor integrating the secu-rity mechanismsof theFlaskarchitecture into theLinuxkernel.

1 Intr oduction

End systemsmust be able to enforce the separationof informationbasedon confidentiality andintegrity re-quirementsto provide systemsecurity. Operating sys-temsecuritymechanismsarethefoundationfor ensuringsuchseparation.Unfortunately, existing mainstream op-eratingsystemslack thecritical securityfeature requiredfor enforcing separation: mandatory accesscontrol [4].As a consequence,applicationsecuritymechanismsarevulnerable to tampering and bypass,and maliciousorflawed applications can easily causefailures in systemsecurity.

Toaddressthisproblem,theNational SecurityAgency(NSA) worked with Secure Computing Corporation

2

2 OVERVIEW 2.1 Encapsulationof SecurityPolicy

(SCC) to researcha strong,flexible mandatory accesscontrol architecturebasedon Type Enforcement [1], amechanism first developed for the LOCK system[6].The NSA and SCC developed two Mach-basedproto-typesof the architecture: DTMach [2] andDTOS [5].The NSA andSCCthenworked with the University ofUtah’sFlux researchgroupto transferthearchitecturetotheFlukeresearchoperatingsystem.Duringthetransfer,the architecture wasenhancedto provide bettersupportfor dynamic securitypolicies[8]. This enhancedarchi-tecturewasnamedFlask. The NSA is now integratingthe Flask architecture into the Linux operating systemto transferthetechnology to a largerdeveloperandusercommunity.

Researchersin theNSA’s InformationAssuranceRe-searchOffice have implementedthe architecture in themajorsubsystemsof theLinux kernel, including manda-tory accesscontrols for operations on processes,files,andsockets.TheSecureExecution Environments (SEE)group at NAI Labsis working with the NSA in furtherdevelopingandconfiguring thissecurity-enhancedLinuxsystem.SCCandMITRE areassistingtheNSA in devel-opingapplicationsecuritypoliciesandenhancedutilityprograms.

This paperdescribeswork by theNSA andNAI Labsin integrating the securitymechanismsof the Flask ar-chitecture into the Linux kernel. The paperbegins byproviding an overview of the Flaskarchitecture anditsLinux kernel implementationin Section2. The designandimplementation of two new operating systemcom-ponents, thesecurityserver andtheaccessvector cache(AVC), arethendescribedin detailin Section3 andSec-tion 4. Then, the designand implementation of secu-rity enhancementsto eachof theexisting Linux operat-ing systemcomponentsaredescribedin detail.

2 Overview

This sectionprovidesanoverview of theFlaskarchi-tectureand its Linux kernel implementation. It beginswith a discussionof how the securitypolicy is encap-sulatedin Flask. The sectionthendiscusseshow Flasksupports flexibility in labelingandaccessdecisions.Theability of Flask to support policy changes is then de-scribed.It thendescribesthemandatory accesscontrolsprovidedfor processes,files,andsockets.

2.1 Encapsulationof Security Policy

In the Flask architecture,the securitypolicy logic isencapsulatedwithin a separatecomponentof theoperat-ing systemwith ageneralinterfacefor obtaining securitypolicy decisions.This separatecomponentis referredtoas the securityserverdueto its origins asa user-spaceserver running on a microkernel. In the Linux imple-mentation, thesecurityserver is merelya kernelsubsys-tem. Theotherkernel subsystemsarereferredto asob-ject managers in thearchitecture.

The Flask architecture specifiesthe interfacespro-vided by the securityserver to object managers. Theimplementationof thesecurityserver, includingany pol-icy languageit maysupport, arenot specifiedby thear-chitecture. The Linux implementationof the Flaskse-curity server defines a securitypolicy that is a combina-tionof TypeEnforcement(TE),role-basedaccesscontrol(RBAC), andoptionally multi-level security(MLS). TheLinux securityserver hasanassociatedpolicy language.A configurationwritten in this languageis compiledbya separateprogramcalledcheckpoli cy into a binaryrepresentationreadby thesecurityserveratboottime.

Sincethecontentandformatof securitylabelsarede-pendentontheparticularsecuritypolicy, theFlaskarchi-tecturedefinestwo policy-independentdatatypesfor se-curity labels: thesecuritycontext andthesecurityiden-tifier. A securitycontext is a variable-lengthstringrep-resentationof thesecuritylabel. Internally, thesecurityserverstoresasecuritycontext asastructure usingapri-vatedatatype. A securityidentifier (SID) is an integerthat is mappedby the securityserver to a securitycon-text. Flaskobject managersareresponsible for bindingsecuritylabelsto their objects,so they bind SIDs to ac-tivekernelobjects.Thefile systemobjectmanagermustalsomaintaina persistentbindingbetweenfiles andse-curity contexts. SincetheobjectmanagershandleSIDsandsecuritycontextsopaquely, achangein theformatorcontent of securitylabelsdoesnotrequire any changestotheobjectmanagers.

In the Linux implementation, a securitycontext con-sistsof a useridentity, a role, a type, andoptionally aMLS level or range. Rolesare only relevant for pro-cesses,so file securitycontexts have a genericobject rrole. Thesecurityserveronly providesSIDsfor securitycontexts with legal combinationsof user, role, type,and

3

2 OVERVIEW 2.4 Support for Policy Changes

level or range. The individual attributesof the securitycontext arenotmanipulatedby theobjectmanagers.

2.2 Flexibility in Labeling DecisionsWhen a Flask object managerrequires a label for a

new object, it consultsthesecurityserver to obtaina la-belingdecisionbasedonthelabelof thecreatingsubject,thelabelof a relatedobject, andtheclassof thenew ob-ject. For programexecution, theFlaskprocessmanagerobtainsthelabelfor thetransformedprocessbasedonthecurrent labelof theprocessandthelabelof theprogramexecutable.For file creation,theFlaskfile systemobjectmanager obtainsthe label for the new file basedon thelabel of the creatingprocess,the label of the parentdi-rectory, andthekind of file beingcreated. Thesecurityserver maycomputethenew labelbasedon theseinputsandmayalsouseotherexternal information.

In theLinux implementation, thesecurityserver maybeconfiguredto automatically causechangesin theroleor domainattributesof a processbasedon the role anddomain of theprocessandthe typeof theprogram. Bydefault, therole anddomainof a processis not changedby program execution. The Linux securityserver mayalso be configured to usespecifiedtypesfor new filesbasedon thedomain of theprocess,thetypeof thepar-entdirectory, andthekind of file. A new file inheritsthesametypeasits parent directory by default. For objectswherethereis only onerelevant SID, objectmanagerstypically donotconsultthesecurityserver. Instead,theymerelyusethisSID astheSID for thenew object.Pipes,file descriptions,andsocketsinherit theSID of thecreat-ing process,andoutputmessagesinherit theSID of thesendingsocket.

2.3 Flexibility in AccessDecisionsObjectmanagers consultthe Flasksecurityserver to

obtainaccessdecisionsbasedon a pair of labelsandanobjectclass.Thelabelpair is usuallythelabelof a sub-jectandthelabelof anobject,but someaccessdecisionsmaycontrol relationships amongobjectpairs. Eachob-ject classhasa setof associatedpermissions.Theseper-missionsetsare representedby a bitmapcalledan ac-cessvector. Flaskdefines a distinctpermissionfor eachservice,and when a serviceaccessesmultiple objects,Flaskdefinesa separatepermissionto control accessto

eachobject.For example,whena file is unlinked,Flaskchecksremove namepermissionto thedirectory andun-link permissionto thefile.

Theuseof objectclassesin accessrequestsallowsdis-tinct permissionsetsto bedefinedfor eachkind of objectbasedontheparticular servicesthataresupportedby theobject. It also allows the securitypolicy to make dis-tinctionsbasedon thekind of object,sothataccessto adevice specialfile canbedistinguishedfrom accessto aregular file andaccessto a raw IP socket canbe distin-guishedfrom accessto a UDP or TCPsocket.

2.4 Support for Policy ChangesTheFlaskarchitectureincludesanaccessvectorcache

(AVC) componentthatstorestheaccessdecisioncompu-tationsprovidedby thesecurityserverfor subsequentuseby theobjectmanagers. An object manager mayfurtherreduce the costof a permissioncheckby storingrefer-encesto theappropriateentryin theAVC with its objects.As a result,mostpermissioncheckscanoccur withoutevenincurring thecostof anextra functioncall.

The Flask AVC provides an interface to the secu-rity server for managing the cacheasneededfor policychanges. Sequencenumbersareusedto addressthepo-tential interleaving of accessdecisioncomputationsandpolicy changenotifications. Whenthe AVC receivesapolicy changenotification, it updatesits own stateandtheninvokescallbackfunctions registeredby theobjectmanagersto updateany permissionsretainedin thestateof the object managers.For example, permissionsmaybe retainedin the accessrights in pagetablesor in theflagsonanopenfile description. After updating thestateof theobjectmanagers andthestateof theAVC to con-form to thepolicy change, theAVC notifiesthesecurityserverthatthetransitionto thenew policy hasbeencom-pleted.

In the Linux implementationof Flask,many permis-sions are revalidated on use, such as permissionsforreading andwriting files andpermissionsfor communi-catingon anestablishedconnection.Consequently, pol-icy changesfor thesepermissions areautomatically rec-ognized andenforcedwithout the needfor objectman-ager callbacks. Permissionscan be efficiently revali-datedby objectmanagersusingreferencesto entriesinthe AVC. However, the revalidation of permissions on

4

2 OVERVIEW 2.6 File Controls

useis not adequatefor revoking accessto mapped filepagesin the Linux page cache.Thecurrent implemen-tationdoesinvalidatetheappropriatepagecacheentrieswhena file is relabeled, but a callbackhasnot yet beendefinedto invalidatethe appropriatepage cacheentrieswhenapolicy changenotificationis received.

TheLinux implementationof theFlasksecurityserverprovides an interface for changing the security policyconfiguration at runtime. The securityload policy callmay be usedto reada new policy configuration from afile. After loading thenew policy configuration, these-curity server updatesits SID mapping, invalidating anySIDs thatareno longer authorized,andresetstheAVC.Subsequentpermissionchecks on processesandobjectswith invalid SIDsalwaysfail, preventing any furtherac-cessesbysuchprocessesandany furtheraccessesto suchobjects.Support for automatically relabelingthesepro-cessesandobjectsto a labelthat is accessibleto admin-istratorshasnotyetbeenimplemented.

2.5 ProcessControls

Flask provides several controls over the ability tochange the label of a process. The security label of aprocessis only allowedto change upon programexecu-tion so that the inheritance of stateandtheinitializationof theprocessin thenew labelcanbecontrolled. Flaskcontrols the ability of a processto transitionto a newsecuritylabelupon programexecution through the tran-sition permission,andit controls whatprogramsmaybeusedto perform suchtransitionsthrough the entrypointpermission. It also controls the ability of a processtoinheritopen file descriptionsacrossa transition.

Flaskprovidesstrongcontrolsoverthefull setof codethatcanbeexecutedby aprocessthrough theprocessex-ecutepermission. This permissionis checked betweenthe label of the transformed processand the label ofthe executableon every program execution. It is alsochecked whenan ELF or script interpreter is executed,andwhena file is memory-mappedwith execute access(i.e. a sharedlibrary). This processexecutepermissiondiffers from the separateentrypointpermission,whichonly controls what programs may be usedto enter anew label. It alsodiffers from the file executepermis-sion, which only controls what programsmay be initi-atedby aprocess,regardlessof whethertheprocesslabel

is changedby theexecution.

Flask controls the sendingof signals, including theability to indirectly senda signalvia asynchronous I/O.It alsocontrols the ability to traceanother process,in-cludingtheability to continue tracinga processwhenatransitionoccurs. Flaskcontrols severaladditional pro-cessmanagementservices,suchas fork, wait, setpgid,getpgid, getsid, setpriority, getpriority, and the schedcalls.Thesecontrols aredescribedfurther in Section5.1.

Flask provides an equivalent permission for eachLinux capability . This allows thesecuritypolicy to con-trol the useof capabilities. Flaskcould be extendedtoprovide a finer-grainedreplacementmechanism for ca-pabilities. Sucha mechanism wasdevelopedfor oneofFlask’s predecessors,the DTOS system. This mecha-nismpermittedprivilegesto begrantedbasedonboththeattributesof theprocessandtheattributesof therelevantobject,e.g. discretionary readoverride couldbegrantedto aparticularsetof files. Sincethemechanismobtainedprivilege decisionsfrom theFlasksecurityserver, man-agement of privileges was centralized and verificationthat privilegesweregrantedappropriately wasstraight-forward.

2.6 File ControlsSinceopenfile descriptions may be inherited across

execveor transferredthrough UNIX socket IPC, Flasklabelsandcontrols openfile descriptions. An openfiledescription is labeledwith theSIDof its creatingprocess,sinceits stateis usuallytreatedaspartof theprivatestateof theprocess.It is importantto distinguish betweenthelabelof anopen file descriptionandthe labelof thefileit references.A readoperation on a file changes thefileoffsetin theopenfile description, soit maybenecessaryto prevent a processfrom readinga file usingan openfile description received or inherited from another pro-cesseventhough theprocessis allowedto directly openandreadthefile.

Flasklabelsfile systemsandcontrolsservicesthatma-nipulatefile systems,including calls for mounting andunmountingfile systems,thestatfscall andthefile cre-ation calls. Flaskcontrols the mounting of file systemsthrough several permissionchecks. It requiresthat theprocesshave mounton permissionto themount point di-rectoryandmount permissionto thefile system.It also

5

2 OVERVIEW 2.7 SocketControls

requires that the mountassociatepermissionbe grantedbetweenthe root directory of the file systemand themount point directory. Flaskdoesnot yet perform anycheck betweenthe device special file and the mountpoint.

Flaskbinds securitylabelsto files anddirectoriesandcontrols accessto them.Flaskstoresapersistentlabelingtablein eachfile systemthatspecifiesthesecuritylabelfor eachfile anddirectory in thatfile system.Forefficientstorage,Flask assignsan integer value referred to asapersistentSID (PSID) to eachsecuritylabelusedby anobject in a file system. The persistentlabelingtable ispartitioned into a mapping betweeneachPSID and itssecuritylabel and a mapping betweeneachobjectandits PSID. Sincethe table is storedin eachfile system,file labelsarepreserved if thefile systemis mountedata different locationor if the file systemis moved to adifferentsystem.

In the Linux implementation, the mapping betweeneachPSID and its securitylabel is implemented usingregular files in a fixedsubdirectory of theroot directoryof eachfile system.This mapping is loadedinto mem-ory whenthefile systemis mounted,andis updatedbothin memory andon thedisk whena new securitylabel isusedfor an object in the file system.The mapping be-tweeneachobjectandits PSID is implementedby stor-ing the PSID in an unusedfield of the on-disk inode.SincethePSID is availablein theon-disk inode,no ex-traoverheadis incurredeitherto obtainthePSIDwhenafile is accessedor to setthePSIDwhena file is created.Additionally, sincethemapping betweeneachobjectandits PSIDis inode-based,changesto thefile systemnamespacedonotaffect themapping.

Whenanunlabeled file systemis first mounted,a per-sistentlabeling table is createdfor the file system,us-ing a default labelfor all files obtained from thesecurityserver. Subsequently, existing files mayberelabeled us-ing new systemcalls. A program calledsetfiles isusedto initially setfile labelsfrom a configuration filethat specifieslabelsbasedon pathname regular expres-sions. This program andconfiguration file may alsobeusedto resetfile labelsto a well-definedstate.However,unlesstheconfigurationfile is updatedto reflectruntimechanges in file labels,thesechanges will be lost whentheprogramis executed.Runtimechangesmayoccuras

a result of new files being created,existing files beingrelabeled, or changesto thenamespace.

Flaskprovidesa separatepermissionfor eachfile anddirectory service.For example,Flaskdefinesanappendpermissionfor files in addition to the write permission,andit definesseparateadd nameandremove name per-missionsfor directories to support append-only files anddirectories. Flaskalsodefinesa reparentpermissionfordirectoriesthatcontrols whethertheparentdirectory linkcanbechangedby a rename.

Flask provides control over eachobject affectedbya file or directory service. For example, in addition tocheckingaccessto theparent directory, Flaskdefinesper-missionsfor controlling accessto the individual file it-self for operationssuchasstat, link, rename, unlink, andrmdir.

2.7 Socket ControlsFlaskprovidescontrol over socketIPCthroughasetof

layeredcontrolsoversockets,messages,nodes,andnet-work interfaces. At the socket layer, Flaskcontrols theability of processesto perform operationsonsockets.Atthetransport layer, Flaskcontrols theability of socketstocommunicatewith othersockets. At the network layer,Flaskcontrols the ability to sendandreceive messageson network interfaces,andit controls theability to sendmessagesto nodesandto receive messagesfrom nodes.Flaskalsocontrols the ability of processesto configurenetwork interfacesandto manipulatethe kernel routingtable.

Sockets effectively serve as communication proxiesfor processesin theFlaskcontrolmodel. Consequently,socketsarelabeledwith thelabelof thecreatingprocessby default. A processmaycreateandusea socket witha different label to perform socket IPC with a differentsourcesecuritylabel. A processmay setup a listeningsocket so thatserver socketscreatedby connectionsarelabeledwith eithera specifiedlabelor with the labeloftheconnectingclientsocketto actasaserverfor multiplelabels.

Flaskallowsthesecuritypolicy to distinguishbetweenclientsandserversfor streamsocketconnectionsthroughtheconnectto andacceptfrom permissions.Flaskallowsthesecuritypolicy tobasedecisionsonthekindof socketthrough the useof object classes,and it allows the se-

6

3 SECURITYSERVER 3.1 Architecture TypesandConstants

curity policy to basedecisionson the messageprotocolthroughtheper-protocol nodeandnetwork interfaceper-missions.

Flask provides control over the associationbetweenINET domainsocketsandportnumbers andtheassocia-tion betweenUNIX domainsocketsandfiles. Hence,thesecuritypolicy canrestrictthe useof port numbersandpathnamesfor useby particular processes.Flask alsoprovides control over openfile description transferviaUNIX domainsockets.

In Flask,messagesareassociatedwith both the labelof their sendingsocketanda separatemessagelabel.Bydefault, this messagelabel is the sameas the sendingsocket label. A process may explicitly label individualmessagesif the underlying protocol supports messageboundaries,i.e. datagram sockets. Messagessenton astreamsocket all have thesamelabel,which is thelabelof thestreamsocket.

Support for communicatingmessagelabelsacrossthenetwork hasnot yet beenimplementedin theLinux im-plementation of Flask. The Fluke implementation ofFlask usedIPSEC/ISAKMP both to label and protectmessages,storingthelabelinginformationin theIPSECsecurityassociation. During an ISAKMP negotiation,theappropriatesecuritycontexts aresentacrossthenet-work andthe peerobtainsSIDs for thesesecuritycon-texts andstoresthemin its IPSECsecurityassociation.Whenmessagesaresubsequently received that usetheIPSECsecurityassociation,the messagesarevalidatedandthenlabeledwith theSIDsfrom theassociation.

3 Security Server

The securityserver is a new operating systemcom-ponent thatprovidessecuritypolicy decisionsto theob-ject managers,permitting theobject managers to remainindependentof the specificsecuritypolicy that is used.This sectiondescribesthe setof interfaces provided bythe securityserver for kernel object managers and theset of systemcalls provided by the securityserver forsecurity-awareapplications. This sectionthendescribesthe policy configuration language andthe implementa-tion of thecurrent Linux securityserverprototype.

3.1 Ar chitecture Typesand ConstantsThe basic Flask types and constantsare definedin

the headerfile include/linux/flask/flask types.h. The se-curity context type (securitycontext t) is definedas astring. The security identifier type (securityid t) isdefinedas an unsigned32-bit integer value. A nullSID, SECSIDNULL, is definedto usewhenno partic-ular SID is specified.A wildcardSID, SECSIDWILD,is definedthat matchesany other SID when usedforcertainaccessvectorcache(AVC) operations. CertainSIDs (specifiedin flask/initial sids) are predefined forsysteminitialization. The correspondingconstantsaredefinedin the automaticallygenerated headerfile in-clude/linux/flask/flask.h.

The accessvector type (accessvector t) is definedas an unsigned 32-bit integer value. Each ob-ject class is identified by an unsigned 16-bit inte-ger value, with the securityclasst type. The set ofsecurity classesis specified in flask/securityclasses,with the corresponding constantsin the automaticallygenerated headerfile include/linux/flask/flask.h. Thepermissions for each security class are specified inflask/accessvectors, andthecorrespondingconstantsaredefinedin the automaticallygenerated headerfile in-clude/linux/flask/avpermissions.h.

3.2 Interfacesfor the KernelThe function prototypesfor the securityserver inter-

facesprovidedfor thekernel object managersarein theinclude/linux/flask/security.hheaderfile. Thissubsectiondescribeseachof theseinterfaces.For eachinterface,thefunction prototypeis listed followedby a description oftheinterfaceandadiscussionof how theinterfaceis cur-rentlyusedby thekernelobjectmanagers.

int security_in it(void);

The securityinit function initializes the securityserver. The kernelcalls this function after the root filesystemis mounted(fs/super.c:mount root) sothatthese-curity server may readconfiguration datafrom the rootfile system.

int security_co mpute_av(securit y_id_t ssid,securit y_id_t tsid,

7

3 SECURITYSERVER 3.2 Interfacesfor theKernel

securit y_class_t tclass,access_ vector_t requested ,access_ vector_t *allowed,access_ vector_t *decided,

#ifdef CONFIG_FLASK_AUDITaccess_ vector_t *auditall ow,access_ vector_t *auditden y,

#endif#ifdef CONFIG_FLASK_NOTIFY

access_ vector_t *notify,#endif

__u32 *seqno) ;

The securitycomputeav function computes accessvectors basedon a SID pair for the permissions ina particular class. The accessvector cache (AVC)componentcalls this function when no valid entry ex-ists for the requestedpermissionsin the cache (in-clude/linux/flask/avc.h:avc haspermref audit). Thefirst SID parameter, ssid, is referredto asthesourceSIDandthesecondSID parameter, tsid, is referred to asthetargetSID. Thereturned accessvectorsmustcontainde-cisionsfor every permissionspecifiedin the requestedaccessvector.

Thesecurityservermayoptionally returndecisionsforotherpermissions in thesameclass.Thedecidedaccessvectorcontains thesetof permissionsfor which a deci-sionwasreturned.Theotherreturnedaccessvectorsmayonly be usedfor permissionsin this set. The securityserver maychooseto defercomputationof permissionsuntil they areexplicitly requested.

Theallowedaccessvector contains thesetof grantedpermissions. The seqnoparameter contains a sequencenumber associatedwith the accessgranting. If the se-quence number provided by the latestpolicy change isgreaterthanthis value,thentheaccessgrantingmaybeinvalid andmustbediscarded. Thesequencenumberad-dressestheissueof aninterleaving of anaccessgrantingandapolicy change.

Two additional accessvectors are returned if audit-ing support is enabled in the kernelconfiguration. Theauditallow andauditdenyaccessvectors containthe setof permissionsthat shouldbe auditedwhengranted orwhendenied, respectively. Thesevectors enablethese-curity server to preciselycontrol the auditing of per-missionchecks. The AVC componentensures that au-

diting is performed in accordancewith thesevectors(avc haspermref audit).

One additional accessvector is returned if notifica-tion support is enabledin thekernel configuration. Thenotify accessvector containsthe setof permissionsforwhichthesecuritynotify permfunctionshouldbecalledwhen the operation associatedwith the permissionhassuccessfullycompleted. This vectorpermits thesecurityserver to requestthat theAVC componentnotify these-curity server of thesuccessfulcompletion of operationsso that thesecurityserver maybaseits decisionson thehistory of operationsin the system. This differs frommerelybasingdecisions on the history of grantedper-missions,sincean operation may still fail dueto otherconditions even if permissionis grantedfor that oper-ation. To support this functionality, the kernel objectmanagers must be changed to notify the AVC compo-nentof thesuccessfulcompletion of operationsby call-ing the include/linux/flask/avc.h:avc notify permref in-line function. TheAVC componentmaythennotify thesecurityserver if any of therequestedpermissions areinthecorresponding notify vector. Thenecessarychangesto thekernelobjectmanagersto notify theAVC compo-nenthavenotyetbeenimplemented.

int security_no tify_perm(securit y_id_t ssid,securit y_id_t tsid,securit y_class_t tclass,access_ vector_t requested );

Thesecuritynotify permfunctionnotifiesthesecurityserver thatanoperation associatedwith thepermissionsin the requestedaccessvector hascompleted success-fully. The AVC componentcalls this function when itis calledby anobjectmanager to indicatethat theoper-ationhascompletedsuccessfullyif any of the requestedpermissions are in the corresponding notify vector (in-clude/linux/flask/avc.h:avc notify permref). Since thekernelobjectmanagershavenotyetbeenchangedto no-tify the AVC of operation completion, this function iscurrently nevercalled.

int security_tr ansition_sid (securit y_id_t ssid,securit y_id_t tsid,securit y_class_t tclass,

8

3 SECURITYSERVER 3.2 Interfacesfor theKernel

securit y_id_t *out_sid);

The securitytransitionsid function computesa SIDfor a new objectbasedon a SID pair anda class. Thekernelobjectmanagers call this function whenobjectsarecreatedif a SID wasnot specifiedfor theobjectandthereis morethanonerelevant SID thatmight beusedasinput in determining theSID of thenew object. In par-ticular, thefile systemcodecalls this functionto obtainthe SID of a new file basedon the SID of the creatingprocessandtheSID of theparentdirectory, andthepro-cessmanagement codecalls this function to obtain theSID of a processtransformedby anexecvebasedon thecurrent SID of theprocessandtheSID of theexecutableprogram.

int security_me mber_sid(securit y_id_t ssid,securit y_id_t tsid,securit y_class_t tclass,securit y_id_t *out_sid);

Thesecuritymembersid function computesa SID tousewhenselectinga memberof a polyinstantiatedob-ject basedon a SID pair anda class. Certainfixed re-sources,suchasthe /tmpdirectoryor theTCP/UDPportnumber spaces,needbepolyinstantiatedto restrictshar-ing amongprocesses.Eachinstantiationis referredto asa member. Thekernelobjectmanagers call this functionwhenapolyinstantiatedobjectisaccessedandthentrans-parently redirect theprocessto theappropriatemember.The necessarychanges to the file systemcodeand thenetworking code to support polyinstantiateddirectoriesandport numberspacesarenot yet implemented,sothisfunction is currentlynever called.

int security_ch ange_sid(securit y_id_t ssid,securit y_id_t tsid,securit y_class_t tclass,securit y_id_t *out_sid);

The securitychange sid function computesa SID tousewhenrelabeling anobjectbasedon a SID pair andaclass.The login programwill bemodified to call thisinterfacetoobtaintheSID tousewhenrelabelingdevicesfor a usersession,basedon theSID for theusersession

andthecurrent SID of thedevice. This modification tologin hasnotyetbeenimplemented.

int security_si d_to_context (securit y_id_t sid,securit y_context_t *scontext,__u32 *scontext_l en);

Thesecuritysid to context function returns thesecu-rity context associatedwith a particular SID. The AVCcomponentcallsthisfunctiontoobtainbothsecuritycon-textsfor aSID pairwhenwriting anauditrecord. Thefilesystemcodecalls this function to obtaina securitycon-text to usewhenadding an entry to the persistentlabelmapping. Theprocfscodecallsthisfunction toobtainthesecuritycontext of a processto includein its statusfile.Thescontext parameteris setto point to a dynamically-allocatedstringof thecorrectsize. Thescontext len pa-rameteris setto thelengthof thesecuritycontext string,including theterminating NULL character. Thestring isallocatedusingkmallocandmustbefreedwith kfreebythecaller.

int security_co ntext_to_sid (securit y_context_t scontext,__u32 scontext_le n,securit y_id_t *out_sid);

Thesecuritycontext to sid function returns a SID as-sociatedwith a particular securitycontext. Thefile sys-temcodecallsthis functionto obtaintheSID thatcorre-sponds to a securitycontext storedin thepersistentlabelmapping. Thescontext lenparameterspecifiesthelengthof the securitycontext string, including the terminatingNULL character.

int security_fs _sid(char *dev,securit y_id_t *fs_sid,securit y_id_t *file_sid);

Thesecurityfs sid function returnsSIDsto usefor anunlabeledfile systemmountedfrom thedevice specifiedby dev. Thefile systemcodecalls this function whenaprocessattemptsto mount anunlabeledfile system.Thevaluefor thedev parameteris a stringof the form “ma-jor:minor” whereboththemajorandminor number are

9

3 SECURITYSERVER 3.3 SystemCallsfor Applications

in hexadecimalandareright justifiedin a two characterfield, asreturnedby thekdevnamefunctiononthedevicenumber. The fs sid parameteris setto theSID to useforthefile system,andthefile sidparameteris setto theSIDto usefor any existingfiles in thefile system.

int security_po rt_sid(__u16 domain,__u16 type,__u8 protocol ,__u16 port,securit y_id_t *out_sid);

The securityport sid function returnsthe SID to usefor theport number port in theprotocol specifiedby thetriple (domain, type, protocol). The networking codecallsthis functionwhenaprocessattemptsto bindaportoutsideof therange usedto automatically bindsockets.

int security_ne tif_sid(char *name,securit y_id_t *if_sid,securit y_id_t *msg_sid);

Thesecuritynetif sid function returnsSIDsto useforanetwork interface. Thenetworking codecallsthisfunc-tion whenaprocessfirst attemptsto configureanetworkinterface.Thevaluefor thenameparameteris typicallythe driver name followed by the unit number, e.g. thenameeth0would beusedfor thefirst Ethernet interface.Theif sid parameter is setto theSID to usefor theinter-face,andthemsgsid parameter is setto theSID to usefor any unlabeledmessagesreceived on theinterface.

int security_no de_sid(__u16 domain,void *addr,__u32 addrlen ,securit y_id_t *out_sid);

Thesecuritynodesid function returnstheSID to usefor the nodewhoseaddressis specifiedby addr. Theaddrlenparameterspecifiesthe lengthof theaddressinbytes,andthedomain parameterspecifiesthecommuni-cationsdomainor addressfamily in which the addressshouldbe interpreted. The networking codecalls thisfunctionwhenpacketsaresenttoanodeor receivedfroma node.

int security_nf s_sid(__u16 domain,void *addr,__u32 addrlen ,securit y_id_t *fs_sid,securit y_id_t *file_sid);

The securitynfs sid function returns the SIDs to usefor thefile systemsandfiles providedby theNFSserverwhoseaddressis specifiedby addr. Theaddrlen param-eterspecifiesthe lengthof theaddressin bytes,andthedomain parameterspecifiesthecommunicationsdomainor addressfamily in which the addressshould be inter-preted. The NFS client code calls this function whenaNFSfile systemis mounted.

3.3 SystemCalls for ApplicationsSecurity-awareapplications in thesystemrequirethe

ability to convert betweenSIDsandsecuritycontexts inorderto usethe extended systemcalls provided by thekernel object managers. Furthermore, somesecurity-awareapplicationsactasobjectmanagersfor theabstrac-tionsmanagedby theapplication, e.g. a windowing sys-tem actsasthe objectmanagerfor its windows. Theseapplicationsrequire accessto mostof thesecurityserverinterfaces.Consequently, the securityserver providesasetof systemcallsfor security-awareapplications.

Thefunctionprototypesfor thesecurityserversystemcalls usedby applicationsarein the include/ss.hheaderfile in thesyscallspackage. Currently, thesecurityserversystemcallsareimplementedusingaseparateentrypointfor eachcall. All of thecallscouldalternatively be im-plementedusingasingleentrypoint,asis donefor sock-ets with the socketcall systemcall. Sincethe securityserver systemcalls arederived from the interfacespro-vided to the kernel, this subsectioncomparesandcon-traststhesystemcall interfacewith the interfacefor thekernel.

Several of the system calls are identical to thecorresponding interface: securitynotify perm, se-curity transitionsid, securitymembersid, secu-rity change sid and securitycontext to sid. Thesecalls are not discussedfurther in this subsection.There are currently no system calls that correspondto the interfacesthat provide SIDs for kernel objects:securityfs sid, securityport sid, securitynetif sid,

10

3 SECURITYSERVER 3.4 Policy ConfigurationLanguage

and securitynode sid. Calls could be added for theseinterfacesif applications require thesameinformation.

Two of thesystemcalls,securitycomputeav andse-curity sid to context, differ from the corresponding in-terfaceonly in the way in which their parametersarepassed.For eachof thesesystemcalls,thefunction pro-totype is listed below followed by a descriptionof thecall anda discussionof how thecall shouldbe usedbyapplications.

struct security _query {securit y_id_t ssid;securit y_id_t tsid;securit y_class_t tclass;access_ vector_t requested ;

};

struct security _response {access_ vector_t allowed;access_ vector_t decided;access_ vector_t auditallo w;access_ vector_t auditdeny ;access_ vector_t notify;__u32 seqno;

};

int security_co mpute_av(struct security_q uery *query,struct security_r esponse *response) ;

Theinput parameters to thesecuritycomputeav sys-tem call are provided in a struct securityquery struc-ture, andthe output parametersarereturned in a structsecurityresponsestructure. Like thekernelobject man-agers,application objectmanagers should usean AVCcomponentto cachetheresultsof a securitycomputeavcall. Like the kernelAVC component,the applicationAVC componentmustprovide an interfaceto the secu-rity server for managing the cacheasneededfor policychanges.An applicationAVC componentlibrary hasnotyetbeenimplemented.

int security_si d_to_context (securit y_id_t sid,securit y_context_t scontext,__u32 *sconte xt_len);

Whereasthe securitysid to context interface for thekernelreturns adynamically-allocatedstring,thesystem

call interface requirestheapplication to provide a bufferfor scontext andto initialize the scontext len parameterwith the size of the buffer. If the buffer is not largeenough,thenthescontext lenparameter is setto thecor-rect length,-1 is returned,anderrnois setto ENOSPC.In this case,theapplicationmayallocatea buffer of thespecifiedlengthandinvoke the call againwith the newbuffer.

Two othersystemcalls,securityload policyandsecu-rity get sids, do nothave a corresponding interfaceusedby kernel object managers. For eachof thesesystemcalls, thefunctionprototypeis listedbelow followed bya description of thecall.

int security_lo ad_policy(char *path,__u32 pathlen );

Thesecurityload policy systemcall loadsa new pol-icy configuration from a file containing a binary rep-resentationof the configuration. The pathlenparame-ter specifiesthe lengthof path, including the terminat-ing NULL character. If pathlenis zero,thenthedefaultpolicy configurationfile is reloaded. After thenew pol-icy configurationhasbeenloaded, thesecurityserver in-vokestheavc ss resetinterfaceof theAVC component.

int security_ge t_sids(securit y_id_t *sids,__u32 *nel);

Thesecurityget sidssystemcall returnsthesetof ac-tive SIDs. Thenel parameteris initialized by theappli-cationto thenumber of elements in thearrayassociatedwith thesidsparameter, andmodified on return to indi-catethenumber of active SIDs. If thearrayis not largeenough, thennel is setto thenumberof active SIDs,-1is returned,anderrno is setto ENOSPC.

3.4 Policy Configuration LanguageThe current Linux security server prototype imple-

mentsasecuritypolicy thatis acombinationof threesub-policies: typeenforcement(TE), role-basedaccesscon-trol (RBAC), andmulti-level security(MLS). TheMLSpolicy is only includedif theCONFIG FLASKMLSker-nel configurationoption is enabled. TheTE andRBAC

11


policiesarealwaysincluded in the current implementa-tion. This subsectiondescribesthepolicy configurationlanguagethatmaybeusedto customizethesepolicies.

Thepolicy configurationfiles arelocatedin thepolicydirectory. The m4 macroprocessoris appliedto theseconfigurationfiles during thepolicy build, with theout-put written to policy.conf, and this output file is thencompiled by thecheckpolicy programinto a binaryrep-resentationstoredin policy. The policy file is installedas /ss policy, andthis file is readby the securityserverduring initialization.

3.4.1 TE configuration The all.te file contains theconfigurationinformationfor thetypeenforcement(TE)policy. This file is automaticallygeneratedfrom a col-lectionof files. Themacros.tefile containsglobalmacrosusedthroughout theconfigurationfor commongroupingsof classesandpermissionsandfor common setsof rules.Theassert.tefile contains assertionsthatarecheckedaf-terevaluatingtheentireTE configuration.

Thetypessubdirectorycontainsseveralfiles with dec-larationsfor general types(typesnot associatedwith aparticular domain) andsomerulesdefiningrelationshipsamong thosetypes. Relatedtypesaregroupedtogetherinto eachfile in this directory, e.g.all device typedecla-rationsarein thedevice.tefile.

The domains subdirectory contains several subdirec-torieswith aseparatefile containing thedeclarationsandrulesfor eachdomain. Relateddomainsaregroupedto-getherinto eachsubdirectory, e.g.all domaindefinitionsfor systemprocessesarein thedomains/systemsubdirec-tory. Thedomains/every.te file containsrulesthatapplyto everydomain.

In a traditional TE policy, eachsubjectis labeledwitha domain, and eachobject is labeledwith a type. Adomain definitiontable(DDT) specifiesthepermissionsgranted betweendomainsand types,anda domainin-teractiontable (DIT) specifiesthe permissionsgrantedbetweendomain pairs. In contrast, the securityserverprototypemergestheconcept of domains andtypesintoasingletypeabstraction, andmaintainsasingletablethatspecifiesthepermissions grantedbetweenpairsof types.To thesecurityserver, adomainis simplyatypethatcanbeassociatedwith a process.TheTE configurationcon-tainsseven kinds of statements:type declarations,type

type syslogd_t, domain;type syslogd_exec _t, file_type,

exec_type;type devlog_t, file_type ;

Figure1: Typedeclarations.

transitionrules, type memberrules, type change rules,accessvector rules,cloning rules,andaccessvectoras-sertions.

A typedeclaration specifiesaprimary namefor atype,anoptional setof aliasnames,andanoptional setof at-tributes.Theprimary nameis alwaysreturnedasthetypeby thesecuritysid to context call. Theprimary nameorany of thealiasnamesmaybeusedfor the typein a se-curity context to sid call. An attribute may be usedtoidentify a setof typeswith similar properties. Whenanattributenameis usedin a rule, it is expandedto thesetof types with thatattribute.Primarynames,aliasnames,andattributenamesall exist in thesamenamespace.

Although domainsarenotdistinguished from typesbythesecurityserver, they canbeoptionally distinguishedin thepolicy configurationusinga“domain” attribute.A“domain” attributehasno intrinsic meaning to thesecu-rity server, andis onlymeaningful to theextentthepolicyconfigurationusestheattributein rules.

Sampletypedeclarations for the syslogd daemonareshown in Figure1. Thesyslogd t type is thedomainofthedaemonprocess,so a domainattribute is associatedwith it. The syslogd exec t type is the type of the dae-monprogramexecutable, so it is associatedwith bothafile typeattributeanda exec typeattribute. Thedevlog ttypeis thetypeof the /dev/log socket file createdby thedaemon for receiving local log messages,soit is associ-atedwith a file typeattribute. Theseattributeshave nointrinsic meaningto thesecurityserver, but they canbeusedin rulesin theconfiguration.

A type transitionrule specifiesthe default type of atransformed processor the default type of a new filebasedon the type of the creatingsubjectand the typeof arelatedobject.For aprocess,therelatedobjectis theprogram executable. For a file, the relatedobjectis theparent directory. If no rule is specified,thenthedefaulttypeof atransformedprocessis thesameasits typeprior

12


type_transi tioninitrc_tsyslogd_exec _t:processsyslogd_t;

type_transi tionsyslogd_tdevice_t:soc k_filedevlog_t;

Figure2: Typetransition rules.

to theexecvecall, andthedefault typeof anew file is thesameasthetypeof its parent directory. Thedefault typeis returnedby thesecuritytransitionsid call.

Eachtype transitionrule hasa creatingsubjecttypefield, a relatedobjecttype field, a classfield, anda de-fault typefield. To permitconcisespecificationof multi-ple typetransitions, thetypefieldsotherthanthedefaulttypefield maycontain a setof types,andtheclassfieldmaycontaina setof classes.An attributenamemaybeusedto indicatethe set of typeswith that attribute. Atilde mayprecede a setof typesto indicatethecomple-mentof theset. An asteriskmaybeusedto indicatealltypes. If multiple type transitionrulesarespecifiedfora giventypepair andclass,thenwarningsareissuedbythepolicy compilerandthelastsuchrule is used.

Sampletype transitionrules for the syslogd daemonare shown in Figure 2. The first transitionrule speci-fies thatwhenanrc scriptexecutesthesyslogd programexecutable,the transformedprocessshouldbe assignedthesyslogd t typeby default. Thesecondtransitionrulespecifiesthatwhensyslogd createsa socket file in /dev,the socket file should be assignedthe devlog t type bydefault. Thedevice t typeis thetypeassignedto the/devdirectory, andthesock file classis thesecurityclassforsocketfiles.

A type memberrule specifiesthe type of the mem-berobjectin a polyinstantiatedobjectthatshouldbeac-cessedby defaultbasedon thetypeof theaccessingpro-cessand the type of the polyinstantiatedobject. If norule is specified,thenthetypeof thepolyinstantiatedob-ject is usedfor themember. A typemember rule hasthesamesyntaxasa type transitionrule except that it usesthetypememberkeyword.

allowdomain init_t:proces ssigchld;

allowsyslogd_t device_t:d ir{ read getattr access search

add_name remove_na me };

allowsyslogd_t devlog_t:s ock_filecreate;

Figure 3: Accessvector rules

A type change rule specifiesthe type to usefor rela-belinganobject basedon thetypeof theprocessandthecurrent type of the object. If no rule is specified,thenthe typeof theobjectis unchanged. A typechangerulehasthesamesyntaxasa typetransitionrule except thatit usesthetypechangekeyword.

An accessvector rule specifiesthe permissionsin anaccessvector basedon a source type,a target type,anda class.Therearefour kindsof accessvectorrules: al-low, auditallow, auditdeny, andnotify. Theserulesde-fine the corresponding accessvectors returned by secu-rity computeav. If no rule is specified,thenno permis-sionsarereturned in allowed, auditallow, or notify, andall permissionsare returned in auditdeny. All permis-sionsarealwaysreturned in the decidedaccessvector,sincethe TE policy does not defer the computationofany permissions.

Eachaccessvectorrule hasa sourcetypefield, a tar-get typefield, a classfield, anda permissionsfield. Aswith type transitionrules,setsof typesandclassesmaybespecifiedin thecorresponding fields,andtheasteriskandtilde charactersmaybeused.Asteriskandtilde mayalsobeusedin thepermissionfield. Thenameself maybe usedin the target type field to indicatethat the ruleshouldbeapplied betweeneachsourcetypeanditself. Ifmultipleaccessvectorrulesarespecifiedfor agiven typepair andclass,thentheunionof thepermissionfields isused.

Sampleallow accessvector rules are shown in Fig-ure 3. The first rule grantsevery domain the ability tosenda SIGCHLDsignalto init, so that init canreapev-

13


cloneuser_t sysadm_t;

neverallowsyslogd_t˜{ syslogd_ex ec_t ld_so_t shlib_t }:processexecute;

Figure4: Domaincloning andaccessvector assertions.

ery process. The secondrule grantssyslogd the abilityto access/dev to replace /dev/log. The third rule grantssyslogd theability to createthe/dev/log socketfile.

A cloning rule specifiesthat the type transitionandaccessvector rulesdefinedfor aspecifiedsourcedomainshouldbe cloned for a specifiedtarget domain. A typetransitionrule for a processis not clonedif the defaulttypein therule is equalto thesourceor targetdomain intheclonestatement.Hence,transitionsfrom thesourcedomain to itself or to thetargetdomainarenotclonedforthetarget domain. An accessvectorrule is not clonedifthetargettypein therule is equalto thesourceor targetdomain in the clonestatement.Hence,permissionsbe-tweenthesourcedomainanditself or betweenthesourcedomain andthetarget domain arenot cloned for thetar-getdomain.

An accessvectorassertionspecifiespermissionsthatshouldnotbein anaccessvectorbasedonasourcetype,a target type, and a class. If any of the specifiedper-missionsarein thecorresponding accessvector, thenthepolicy compilerwill rejectthepolicy configuration.Cur-rently, thereis only onekind of accessvector assertion,neverallow, but support for the other kinds of vectorscouldbeeasilyadded. Accessvector assertionsusethesamesyntaxasaccessvector rules.

A sampledomain cloning rule and a sampleaccessvectorassertionareshown in Figure 4. Thecloning ruleclonesthetypetransitionrulesandtheaccessvector rulesof the user t domainfor the sysadmt domain. The ac-cessvector assertionrule verifies that the syslogd dae-mon process may only execute codefrom its programexecutable, the dynamic loader, and the systemsharedlibraries.

role system_r types {init_t getty_t };

role user_r types user_t;role sysadm_r types sysadm_t;

Figure5: Roledeclarations

role_transi tion system_r login_exec_t login_r;role_transi tion sysadm_r untrusted_ex ec_t user_r;

Figure6: Roletransitionrules

3.4.2 RBAC configuration The rbac file containsthe configuration information for the role-basedaccesscontrol (RBAC) policy. Although roles could be im-plemented directly using TE domains, this policy pro-videsanadditional layerof abstractionfor groupingTEdomains into rolesand for expressinga role hierarchy.Rolesareonly relevant for processes.Files arelabeledwith a generic object r role.

TheRBAC configurationcontains four kindsof state-ments:role declarations,role transitionrules,role allowrules,androledominancedefinitions.A roledeclarationspecifiesa namefor therole anda setof typesthatmaybeassociatedwith that role. This limits thesetof typesthatmaybeenteredby aprocessin therole. Thegenericobject r role maybeassociatedwith any type,sinceob-ject rolesarenot relevant to thepolicy.

Samplerole declarations areshown in Figure5. Thefirst declarationdefinesa systemr role for systempro-cessessuchasinit andgetty. Theseconddeclaration de-finesa user r role for ordinary users.Thethird declara-tion definesa sysadmr role for systemadministrators.

A role transitionrule specifiesthe default role of atransformedprocessbasedon its prior role andthe typeof the programexecutable. If no rule is specified,thenthedefault role of a processis thesameasits role priorto theexecvecall. Sampleroletransitionrulesareshownin Figure6. The first rule specifiesthat whena systemprocessexecutesthelogin programexecutable,thetrans-formed processshouldbe assignedthe login r role bydefault. Thesecondrulespecifiesthatwhenasystemad-ministratorexecutes an untrustedexecutable, the trans-formedprocessshouldbeassignedtheuser r role.

14


allow system_r user_r;allow system_r sysadm_r;allow system_r secadm_r;

Figure7: Roleallow rules

sensitivity unclassified alias u;sensitivity top_secret alias ts;dominance { u ts }category nato;category usuk;level u;level ts:nato,usu k;

Figure8: MLS declarations

A role allow rule specifiesallowable transitions be-tweenrolesonanexecve. If norule is specified,thenthechangein roleswill notbepermitted. Additional controlsover roletransitionsbasedonthetypeof theprocessmaybespecifiedthrough theconstraintsfile, asdiscussedinSection3.4.5. Sampleroleallow rulesareshown in Fig-ure7. Thefirst rulegrantsprocessesin thesystemr rolethepermissionto transitionto theuser r role. Thesec-ond and third rules provide similar permissionsto thesysadmr andsecadmr roles.

A role dominance definition specifiesa hierarchyamong a setof roles. A role automaticallyinheritsanytypesthatcanbeassociatedwith any role it dominatesinthehierarchy. As discussedin Section3.4.5, this domi-nancerelationship mayalsobeusedto defineconstraintson specificpermissions.Roledominancedefinitions arenotcurrently usedin thesamplepolicy configuration.

3.4.3 MLS configuration The mls file contains theconfiguration information for the multi-level security(MLS) policy. This policy is an extension of the BellLaPadula (BLP) modelof multi-level securityin whicheachsubjectandobject arelabeledwith arangeof levels.If asubjectis multi-level, i.e. its low leveldiffersfrom itshigh level, thenit is trustedto handle dataat any level inits rangewhile maintaining proper separation among thedifferent levels. Multi-level objectsmaybeusedfor theprivate stateof multi-level subjectsandfor datasharingbetweenmulti-level subjects.

TheMLS configurationbeginsby declaring thesensi-

class tcp_socket {connectto : { read write }acceptfrom : { readby writeby }

}

Figure9: MLS basepermissions

tivities anddefining thedominanceordering for them.Itthendeclaresthecategories,anddefineslevelsby speci-fying whatcategoriesmaybeassociatedwith eachsensi-tivity. SampleMLS declarationsareshown in Figure8.

After the declarations, eachaccessvectorpermissionis mappedto asetof MLS basepermissions (read, write,readby, andwriteby). ThereadMLS basepermissionisonlygrantedif thehighlevelof thesourceSIDdominatesthehighlevel of thetarget SID.Thewrite MLS baseper-missionis only grantedif the target SID is single-levelandit dominatesthe low level of the source SID, or iftherangeof thetargetSID is asubsetof therangeof thesourceSID. Thelatterrestrictiononwritesto multi-leveltargets protectstheintegrity of suchobjects.

The readbyandwriteby MLS basepermissionshavethe samerequirementsasthe readandwrite MLS basepermissions, respectively, with the sourceand targetSIDs exchangedto reflect the target SID actingon thesourceSID. An accessvector permissionis only grantedif all of the MLS basepermissionsassociatedwith itaregranted.SampleMLS basepermissionmappingsareshown in Figure9.

The current policy configuration language doesnotsupport specificationof MLS rangetransitionrules. AMLS rangetransitionrule would specifythe range of anew objectbasedontherangeof thecreating subjectandtherange of a relatedobject. By default, theMLS rangeof a processdoesnot change acrossan execve, andtheMLS rangeof anobject is inheritedfrom its creator.

The current policy configuration languagealso doesnotsupport specificationof MLS rangememberrulesforpolyinstantiatedobjects.TheMLS range of thememberis currently alwaysinherited from theprocess.Hence,aseparatememberis createdfor eachdistinctMLS rangethataccessestheobject.

3.4.4 User configuration The users file, or theusers.mlsfile if theMLS policy is enabled, containsone

15


user system_u roles system_rranges u-ts;

user sds roles { secadm_r user_r }ranges { u s };

user pal roles user_rranges { u s-ts };

Figure10: Userdeclarations.

or more declarations for users,as shown in Figure10.Eachuserhasa corresponding setof allowedrolesthatmay be associatedwith that user. This limits the setofroles that may be enteredby a processwith that useridentity. If the MLS policy is enabled, theneachuseralsohasa corresponding setof allowedMLS rangesthatmay be associatedwith the user. This limits the setofMLS rangesthatmaybeenteredby theuserandthesetof MLS ranges that may be usedfor objectsownedbythe user. Any MLS rangethat is a subsetof oneof thespecifiedMLS rangesis allowed.

The current policy configuration language doesnotsupport specificationof user transitionrules. It is ex-pected that the user identity of a processwill onlychangethroughuserauthentication programsthatexplic-itly specifythenew identity. By default, theuseridentityof a processdoesnot change acrossan execve, andtheuserownerof afile is inheritedfromthecreatingprocess.Controlsover explicit useridentity transitions basedonthetypeof theprocessmaybespecifiedthrough thecon-straintsfile, asdiscussedin Section3.4.5.

The current policy configuration languagealso doesnot support specification of user member rules forpolyinstantiatedobjects. The userowner of the mem-ber is currently always inheritedfrom the polyinstanti-atedobject. Hence,separatemembersarenotcreatedfordifferentusersof processesthataccesstheobject.

3.4.5 Constraintsconfiguration Theconstraintsfiledefinesadditional constraintsonpermissionsin theformof booleanexpressionsthatmustbesatisfiedin order forspecifiedpermissionsto be granted. Theseconstraintsareusedto furtherrefinethetypeenforcementtablesandroleallow rules.Constraintsmaycompare theuseriden-tity, role, or type of the sourceand target SIDs. Con-straintsmayalsocomparetheuseridentity, role,or type

constrain process transition( u1 == u2 or

t1 == privuser );

constrain process transition( r1 == r2 or

t1 == privrole );

Figure11: Processtransition constraints.

sid kernel system_u:syst em_r:kernel_t :usid init system_u :system_r:init _t:usid kmod system_u :system_r:kmod _t:u

Figure12: Security contexts for initial SIDs.

of either SID against a set of specifiedusers,roles ortypes.Rolecomparisonsmayalsobebasedonany dom-inancehierarchiesdefinedin theRBAC configuration.

Sampleconstraints for changes in user identity androle for processesareshown in Figure11. Thefirst con-straint requiresthat the user identity remain the sameacrossanexecveunlesstheprocessis in a typewith the“privuser” attribute. u1 andu2 refer to the useridenti-tiesof thesourceandtarget SIDs,respectively. t1 refersto the type of the sourceSID. The “privuser” attributewould typically belimited to thedomain for login.

Thesecondconstraintrequiresthattheroleremainthesameacrossanexecveunlesstheprocessis in atypewiththe“privrole” attribute.r1 andr2 referto therolesof thesourceandtargetSIDs,respectively. Thisconstraintis inadditionto the requirement that any role changebe au-thorizedby a role allow rule in theRBAC configuration.The“privrole” attributewould typically belimited to thedomain for login. It might alsobe associatedwith thedomain for a newrole programto allow usersto changeroleswithin a session.

3.4.6 Security context configuration The ini-tial sid contexts file, or the initial sid contexts.mlsfileif the MLS policy is enabled, contains the securitycontext for eachSID that was predefined for systeminitialization. Eachsecuritycontext consistsof a user,a role, a typeand,if theMLS policy is enabled, a MLSrange, as shown in Figure 12. Since the initial SIDsdo not correspond to authenticated users, they use a

16

3 SECURITYSERVER 3.5 PrototypeImplementation

3 2 system_u:obje ct_r:public_t: usystem_u:obje ct_r:public_t: u

Figure13: Security contexts for unlabeled filesystems.

tcp 21 system_u:o bject_r:ftp_t: u

eth0 system_u:obj ect_r:netif_et h0_t:usystem_u:obj ect_r:netmsg_e th0_t:u

127.0.0.1 255.255 .255.255system_ u:object_r:nod e_lo_t:u

10.33.1.2 255.255 .255.255system_u:ob ject_r:nfs_cli pper_t:usystem_u:ob ject_r:nfs_cli pper_t:u

Figure14: Security contexts for network objects.

systemu useridentity.

The fs contexts file, or the fs contexts.mlsfile if theMLS policy is enabled, contains thesecuritycontexts tousewhenanunlabeledfile systemis mountedfrom ade-vice, asshown in Figure13. For eachfile system,themajorandminordevicenumbersof thedevicearespeci-fied,followedby thefile systemsecuritycontext andthesecuritycontext for existingfiles in thefile system.If noentryis specifiedfor a device, thenthesecuritycontextsassociatedwith theinitial SIDsfsandfileareused.Theseinitial SIDs arealsousedfor the root file systemif it isunlabeled,sincethesecurityserver is not yet initializedwhentheroot file systemis mounted.

Thenet contextsfile, or thenet contexts.mlsfile if theMLS policy is enabled, containsthe securitycontextsfor port numbers, network interfacesnodes, and NFSservers,asshown in Figure14. Thecurrent policy con-figuration languageonly supportsportsandaddressesintheAF INET addressfamily, althoughthesecurityserverinterfacesaremoregeneral. For eachport, theprotocol(tcpor udp) andport rangearespecifiedfollowedby theport securitycontext. If no entry is specifiedfor a port,thenthesecuritycontext associatedwith the initial SIDport is used.

For eachnetwork interface,theinterfacenameis spec-ified followed by the interfacesecuritycontext andthesecuritycontext for any unlabeledmessagesreceived on

theinterface. If noentryis specifiedfor a network inter-face,thenthesecuritycontextsassociatedwith theinitialSIDs netif andnetmsgareused. For eachnode,a net-work addressandanetwork maskarespecified,followedby thenodesecuritycontext. Themaskis appliedto thenodeaddress passedto the securitynode sid interface,andthe result is thencomparedto the network address.In the current implementation, the entriesare checkedfor a matchin the sameorderthat they arespecifiedintheconfiguration. If no matchingentryis specifiedfor anode, thenthesecuritycontext associatedwith theinitialSID node is used.

For eachNFSserver, anetwork addressandanetworkmaskarespecified,followedby thefile systemsecuritycontext andfile securitycontext. Themaskis applied tothenodeaddresspassedto thesecuritynfs sid interface,andthe result is thencomparedto the network address.In the current implementation, the entriesare checkedfor a matchin the sameorderthat they arespecifiedintheconfiguration. If no matchingentryis specifiedfor anode, thenthesecuritycontext associatedwith theinitialSID nfs is used.

3.5 Prototype Implementation

This sectiondescribes the implementationof thecur-rentLinux securityserverprototype.Thesecurityserversourcecodeis locatedin the securitysubdirectory. Inadditionto beingusedto build the securityserver, thiscodeis usedin combinationwith policy scan.landpol-icy parse.y to build thecheckpolicy program.Thecheck-policy program is usedto compile the policy configu-ration datainto a binary representation for the securityserver. The -d option to the checkpolicy programmaybeusedto interactively testthesecurityserver functionson a policy configuration.This optionpermits testingofa policy configuration prior to loadingit into a runningsecurityserveror prior to bootingakernelwith it.

The securityinit interface of the security serveris implemented in init.c. This function calls pol-icydb.c:policydb read to create an in-memory rep-resentation of the policy configuration data (poli-cydb.h:policydb t) from the /ss policy file. It thencalls policydb.c:policydb load isids to load the initialSIDs from the policy configuration into the SID ta-ble (sidtab.h:sidtab t). Finally, it sets a global flag,

17


ss initialized, to indicatethat thesecurityserver hasini-tialized.

All of theotherinterfacesof thesecurityserver areim-plemented in services.c, with the correspondingsystemcall functions in syscalls.c. Eachof the interfacefunc-tionsdisablesinterrupts locally andtakesa singleglobalspinlock (ss lock) on entryusingspin lock irqsave, andeachfunction usesspin unlock irqrestore before return-ing. This locking schemeis likely to change to onethatusesreader-writer spinlocks, sinceseveral of the secu-rity serverfunctionsonly requirereadaccessto its globaldatastructures.Severalof thesefunctions aresplit intoa small stub function that handleslocking anda sepa-ratefunction with the prefix unlocked that implementsthe interface functionality. Although this separationisnotcurrently used,it couldbeusedto permitthesecurityserverto call oneof theunlocked functionsfromanotherfunction withoutdoubly locking.

3.5.1 compute av The un-locked securitycompute av function setsthe sequencenumber to thevalueof latestgranting, a global counterthat is incrementedby thesecurityload policy functionwhena new policy configuration is loaded. Then, thefunction setsthe decidedvector to containall permis-sions, since none of the policies implemented by thesecurityserver prototypedefer the computationof anypermissions.

If the securityserver hasnot yet initialized, thentheunlocked securitycompute av function simply returnstherequestedpermissions in boththedecided vector andtheallowedvector. Hence,all requestedpermissionsaregranted until the initialization of thesecurityserver hascompleted. This is necessarybecausesomepermissionchecksoccurbefore the securityinit function is called,e.g. fork permissionfor kernel threadsandcreateper-missionfor the ICMP socket andthe TCP resetsocket.Additionally, asearch permissioncheckoccurswhenthesecurityinit functionopensthepolicy configurationfile.

A moresecuresolutionwould beto preloadthesecu-rity server stateor theaccessvector cachestatewith theexact set of permissionsthat are required to initialize.This initial statecould thenbe includedin the analysisof theoverall securitypolicy. However, sincethesystemis still under development,thefull initial stateis not yet

known.

If the security server has initialized, then the un-locked securitycompute av function looks up the se-curity contexts for the SID pair in the SID hash ta-ble (sidtab.h:sidtabt). These security contexts arestoredusing a structure that is private to the securityserver (context.h:context struct t). The function thenlooks up the attributesassociatedwith the class(poli-cydb.h:classdatumt).

The function setsthe valuesof the accessvectors totheirdefaultvalues.It thenlooksfor anaccessvector rulein the TE accessvector table (avtab.h:avtab t) for thetypepairandclass.If a ruleexists,thenthefunctionsetsthecorresponding accessvectors to thevectors specifiedby therule.

If the MLS policy is enabled,the function thencallsthe MLS policy (mls.c:mlscompute av) to remove anypermissions from theallowedvector thatareprohibitedby the MLS policy. The MLS policy removesany per-missionsfrom allowed that aremapped to a MLS basepermissionthatwouldbedenied.

The function thenchecksthe list of constraints asso-ciatedwith theclassfor any constraints thatapplyto thepermissions in allowed. Theconstraint expr eval func-tion is invokedon eachsuchconstraint. If theconstraintevaluates to false, then the function removes the con-strainedpermissionsfrom allowed.

If theprocesstransitionpermissionis beingcomputedand the role is changing, then the function looks for arole allow rule that authorizesthe role transition. If nosuchruleexists,thentheprocesstransitionpermissionisdenied.

3.5.2 compute sid The un-locked securitycompute sid function is used forthe securitytransitionsid, securitymembersid, andsecuritychange sid interfaces. It returns the currentprocess SID or the relatedobject SID if the securityserver is not yet initialized depending on the securityclass. Although therearecurrently no situationswherethefunction is calledprior to initialization, it is possiblethat future developmentwill introduce such cases. Ifsuchcasesdo arisein thefuture,a bettersolutionwouldbeto preloadthesecurityserver statewith theSIDsthatarerequiredto initialize.

18


If the security server has initialized, then the un-locked securitycompute sid functionlooksup thesecu-rity contexts for theSID pair in theSID hashtable.Thefunction thensetsthe useridentity for the new contextbasedon which interfaceis beingused,andit initializestherole andtypebasedon thesecurityclass.Thefunc-tion thenlooksfor atyperule in thepolicy configuration.If atyperuleexists,thenthetypeis changedaccordingly.

The function thenappliesclass-specificlogic. For aprocess, if a transitionis beingrequested,the functionchecksfor a role transition rule and changes the roleif a rule is found. If thereis no change in the processatributes,thenthefunctionsimply returns theSID of theprocess. For an object, if thereis no change in the ob-ject attributesfrom the relatedobject,thenthe functionsimply returns theSID of therelatedobject.

The function then sets the MLS attributesfrom the processcontext. It then calls the poli-cydb.c:policydb context isvalid function to verify thatthe securitycontext is valid. If the context is not valid,then the function returns an error. Otherwise,it callsthe sidtabcontext to sid function to obtain a SID thatcorrespondsto thecontext andreturns.

3.5.3 sid to context The un-locked securitysid to context function panics if itis calledbefore thesecurityserverhasinitialized,unlesstheSID is predefined. In this case,this function returnsa string containing the nameof the initial SID. Thispermits the AVC to call this function for a SID pairwhenwriting anauditrecordprior to theinitializationofthesecurityserver.

If the security server has initialized, then thisfunction looks up the security context for the SIDin the SID hash table. It then calls the ser-vices.c:context struct to string function. This functioncomputesthe lengthof the securitycontext string,call-ing mls.c:mlscompute context len to obtain the lengthof theMLS fieldsof thestring if theMLS policy is en-abled.It thenallocatesabufferof thatlengthusingkmal-loc, copiestheuser, role,andtypenamesinto thebuffer,andcalls mls.c:mlssid to context to write the MLS at-tributesinto thebuffer. Thefunction thenreturns.

3.5.4 context to sid The un-locked securitycontext to sid function panics if itis calledbefore thesecurityserverhasinitialized,unlessthecontext is simply thenameof an initial SID. In thiscase,this function returns thecorrespondinginitial SID.This is not necessary, but it is provided to parallel theunlocked securitysid to context function.

If the securityserver has initialized, then this func-tion createsa copy of the securitycontext string that itcanmodify as it parsesthe string. It thenlooks up theusername,role name,and type namefrom the stringand setsthe valuesin a securitycontext structure forthesefields. This function callsmls.c:mlscontext to sidto set the MLS fields in the security context struc-ture basedon the remainder of the string. Then, itcalls policydb context isvalid to verify that the contextis valid. If the context is valid, the function calls thesidtabcontext to sid function to obtainaSID thatcorre-sponds to the context andreturns. Otherwise,it returnsanerror.

3.5.5 load policy The securityload policy functioncalls policydb read to createan in-memory representa-tion of the new configuration. It then applies the ser-vices.c:validate classfunction to eachentryin theclasshashtableto verify thateachclassthat is definedundertheexistingpolicy is still definedwith thesameattributesin the new policy. Sincethe classandpermissionval-uesarecompiled into the objectmanagers, the securityserver cannotpermit its valuesfor existing classesandpermissions to change during systemoperation.

After checkingthe classes,the securityload policyfunction appliesthe services.c:convert context functionto eachentry in the SID hashtable to convert the val-uesof users,roles,types,sensitivities andcategories inthesecuritycontext structurefor eachSID to thecorre-sponding valuesin the new policy. This function callsmls.c:mlsconvert context to convert the MLS fields ofthestructure. After convertingall of thevalues,thisfunc-tion alsocallspolicydb context isvalid to verify that thecontext is still validunderthenew policy. If it is not,thentheSID is removedfrom theSID hashtable.

Thesecurityload policyfunctiontheninstallsthenewpolicy configurationastheactive policy, incrementsthelatestgranting counter, andcalls the avc ss resetinter-

19

4 ACCESSVECTORCACHE

PERMISSION(S) DESCRIPTIONcomputeav Compute accessvectorsnotify perm Notify about permissionstransition sid Compute new object SIDmembersid Compute memberSIDchangesid Compute relabel SIDsid to context Obtain contextcontext to sid Obtain SIDload policy Loadnew policyget sids Getactive SIDs

Table1: Permissionsfor thesecurity object class.

faceof theAVC componentto resettheAVC. Theglobalspin lock (ss lock) is releasedbeforecalling the AVC.This is necessarybecausetheAVC invokesany callbackfunctions registeredby the object managers for resets,and thesecallback functions may perform permissionchecksto revalidatepermissionsthatareretainedin thestateof theobjectmanagers.

3.5.6 Other interfaces Since none of the imple-mentedpolicies basetheir decisionson the history ofcompletedoperations, thesecuritynotify permfunctionsimply returns immediately whencalled. This functionis currently nevercalledsincethekernelobjectmanagershavenotyetbeenchangedto notify theAVC of operationcompletion.

The securityfs sid, securityport sid, secu-rity netif sid, securitynode sid, and securitynfs sidfunctions look for a matching entry from the policyconfiguration. If no entry is found, thenthesefunctionsreturntheappropriateinitial SIDs. If anentry is found,then thesefunctions checkto seeif a SID hasalreadybeenallocatedfor eachsecuritycontext in the entry. Ifnot, then thesefunctions call sidtabcontext to sid toobtaina SID for eachsecuritycontext in the entry andcachethe SID in the entry. ThesefunctionsthenreturnthecachedSIDs.

3.5.7 SystemCall Controls Thesecurityserverpro-totypedefinesa securityclasswith a setof permissionsto control the ability of applications to usethe securityserversystemcalls,asshown in Table1. Thepredefinedsecurity initial SID is usedas the target SID for mostof thesepermissionchecks.The load policy permission

CONTROL REQUIREMENT(S)CALL(S) CLASS PERM SSID TSIDcompute av security compute av current securitynotify perm security notify perm current securitytransition sid security transition sid current securitymembersid security membersid current securitychangesid security changesid current securitysid to context security sid to context current sidcontext to sid security context to sid current securityload policy security load policy current fileget sids security get sids current security

Table2: Control requirementsfor security calls.

checkusesthe SID of the configuration file as the tar-get SID to permit control over the files usedfor policyconfigurations.Thesid to context permissioncheckusestheSID parameterasthetarget SID to permitindividualcontrol overaccessto securitycontexts. Thepermissionscurrently required to invoke eachsystemcall areshownin Table2. Thesepermissionchecksareimplemented inthesystemcall functionsin syscalls.c.

Thecontext to sidpermissioncheckcouldbechangedto similarly usetheSID associatedwith thecontext pa-rameterasthetargetSID. However, this is not currentlyuseful,sincethe SID hasalready beenallocatedat thatpoint. If SID descriptors are implemented, then thischeckshouldbe changed to usethe SID descriptor. Inthatcase,theSID descriptor canbereleasedif thecheckfails.

4 AccessVector CacheTheaccessvector cache(AVC) is anew operatingsys-

temcomponentthatprovidescachingof accessdecisioncomputationsto minimize the performanceoverheadofthe Flask securitymechanisms. This sectiondescribesthe setof interfacesprovided by the AVC to the kernelobjectmanagers. It thendescribesthe setof interfacesprovidedby theAVC to thesecurityserver. Finally, thissectiondescribestheimplementationof theAVC.

4.1 Interfacesfor the KernelThe datatypesand function prototypesfor the AVC

interfacesprovided for the kernel object managers arein the include/linux/flask/avc.hheader file. Theseinter-facesareusedby thekernelobjectmanagersto perform

20

4 ACCESSVECTORCACHE 4.1 Interfacesfor theKernel

permissionchecksandto notify the AVC of completedoperations. This subsectiondescribeseachof the datatypesandinterfacesusedby thekernelobject managers.For eachdatatype and function prototype, the type orprototypedefinitionis listedfollowed by adescription ofthetypeor function.

void avc_init(v oid);

Theavc init function initializes the AVC. Thekernelcallsthis function afterthesupport for dynamicmemoryallocationhasbeeninitialized (init/main.c:start kernel)so that the AVC may allocatememoryusing kmalloc.Alternatively, theAVC couldbechanged to reserve lowmemory for its useduring thekernelinitialization.

typedef struct avc_entry_re f {avc_ent ry_t *ae;

} avc_ent ry_ref_t;

#define AVC_ENTRY_REF_INIT( h) \{ (h)->ae = NULL; }

#define AVC_ENTRY_REF_CPY(dst,src) \(dst)->ae = (src)->ae

The AVC entry reference type (avc entry ref t) con-sists of a pointer to an entry in the AVC. The AVCreturns a referenceto the entry usedfor a permissioncheck.An object manager maysave this referencewiththe corresponding object for subsequent use in otherpermissioncheckson the object. An object managermust initialize a reference before its first usewith theAVC ENTRY REF INIT macro.An object manager maycopy areferencewith theAVC ENTRY REF CPYmacro.AVC entryreferencesshouldonlybedereferencedby theAVC functions.

typedef struct avc_audit_da ta {char type;

#define AVC_AUDIT_DATA_FS 1#define AVC_AUDIT_DATA_NET 2

union {struct {

struct dentry *dentry ;struct inode *inode;

} fs;struct {

char *netif;struct sk_buff *skb;struct sock *sk;__u16 port;__u32 daddr;

} net;} u;

} avc_aud it_data_t;

#define AVC_AUDIT_DATA_INIT (_d,_t) \{ memset( (_d), 0, \

sizeof( struct avc_audit_d ata)); \(_d)->t ype = AVC_AUDIT_DATA_##_t; }

The AVC audit datatype (avc audit data t) consistsof object or parameterinformation provided by theobjectmanager for the AVC to usewhena permissioncheck is audited. This data supplements the auditinformation directly available to the AVC (i.e. theSID pair, the class, the requestedpermissions,andinformation about the current process). The type fieldindicateswhat type of data is being provided by theobject manager to the AVC. Currently, two typesare supported: file system (AVC AUDIT DATA FS)and networking (AVC AUDIT DATA NET). TheAVC AUDIT DATA INIT macromay be usedto initial-ize thedatawith a specifiedtype.

If thefile systemtypeis used,thentheobjectmanagermayseteitherof thefields in the fs structureto identifythe file involved in a permissioncheck. If a dentry forthe file is available,thenthe dentryfield shouldbe set.Otherwise,the inodefor thefile maybeset.

If thenetworking typeis used,thentheobjectmanagermay setany of the fields in the net structure. The netiffield maybesetto identify a network interface.Theskbfield may be set to identify a packet. The sk field maybesetto identify a socket. Theport field maybesettoidentify a port number. The daddr field may be set toidentify anIPv4address.

inline int avc_has_pe rm_ref_audit (securit y_id_t ssid,securit y_id_t tsid,securit y_class_t tclass,access_ vector_t requested ,avc_ent ry_ref_t *aeref,avc_aud it_data_t *auditda ta);

21

4 ACCESSVECTORCACHE 4.1 Interfacesfor theKernel

The avc haspermref audit inline function deter-mineswhether therequestedpermissionsaregrantedforthespecifiedSID pairandclass.If aeref refersto avalidAVC entryfor thispermissioncheck,thenthereferencedentryis used.Otherwise,this function obtainsavalid en-try andsetsaeref to referto this entry. To obtaina validentry, this function first searchesthecache.If this fails,thenthis functioncallsthesecuritycompute av interfaceof thesecurityserver to compute theaccessvectorsandaddsa new entry to the cache. If the appropriateauditaccessvector (auditallow or auditdeny) in theentryindi-catesthat the permissioncheckshouldbe audited,thenthis function auditsthe permissioncheck,usingtheau-ditdataparameter to supplementtheauditinformation.

This function returns 0 if permission is granted.If the security server returns an error upon a secu-rity computeav call, then this function returns that er-ror. If thesecurityserver returnsasequencenumber thatis less than the latestpolicy change sequencenumber,then this function discardsthe securityserver responseandreturns-EAGAIN . If permissionis denied, thenthisfunction returns-EACCES.

The kernel objectmanagerscall this function to per-form permission checks. Kernelobjectmanagers mayalsousevariantsof this function,suchasavc hasperm,avc haspermaudit, and avc haspermref, in order toomit the referenceor auditdataparameters.Kernelob-ject managers mayalsousemacroversionsof this func-tion, suchasAVC HASPERMREF, AVC HASPERM,andAVC HASPERMAUDIT, in order to automaticallyincludetheclassname in thepermissionsymbol.

inline int avc_notify _perm_ref(securit y_id_t ssid,securit y_id_t tsid,securit y_class_t tclass,access_ vector_t requested ,avc_ent ry_ref_t *aeref)

The avc notify permref inline function notifies theAVC componentthatanoperationassociatedwith there-questedpermissionshascompletedsuccessfully. If anyof therequestedpermissionsarein thenotifyaccessvec-tor of the corresponding AVC entry, then this functioncalls the securitynotify perm interface of the securityserver to notify thesecurityserver thattheoperation has

completedsuccessfully. If aeref refersto a valid AVCentry for the requestedpermissions,thenthereferencedentry is usedto obtainthenotify vector. Otherwise,thisfunction obtainsa valid entry andsetsaeref to refer tothisentryin thesamemannerasavc haspermref audit.

This function returns 0 if the notification is success-ful. If the securityserver returns an error upona secu-rity computeav call or a securitynotify permcall, thenthis functionreturns thaterror. If thesecurityserver re-turnsasequencenumberthatis lessthanthelatestpolicychange sequencenumber, thenthis function discardsthesecurityserver responseandreturns -EAGAIN .

Thekernel objectmanagershavenotyetbeenchangedto call this function. Kernelobjectmanagersmay alsousea variant of this function, avc notify perm, in orderto omit thereferenceparameter. Kernel objectmanagersmay also usemacroversionsof this function, suchasAVC NOTIFY PERMREFandAVC NOTIFY PERM, inorderto automatically include theclassnamein theper-missionsymbol.

#define AVC_CALLBACK_GRANT 1#define AVC_CALLBACK_TRY_REVOKE 2#define AVC_CALLBACK_REVOKE 4#define AVC_CALLBACK_RESET 8#ifdef CONFIG_FLASK_AUDIT#define AVC_CALLBACK_AUDITALLOW_ENABLE 16#define AVC_CALLBACK_AUDITALLOW_DISABLE 32#define AVC_CALLBACK_AUDITDENY_ENABLE 64#define AVC_CALLBACK_AUDITDENY_DISABLE 128#endif#ifdef CONFIG_FLASK_NOTIFY#define AVC_CALLBACK_NOTIFY_ENABLE 256#define AVC_CALLBACK_NOTIFY_DISABLE 512#endif

int avc_add_cal lback(int (*callb ack)(

__u32 event,security_ id_t ssid,security_ id_t tsid,security_ class_t tclass,access_ve ctor_t perms,access_ve ctor_t *out_retain ed),

__u32 events,security_id _t ssid,security_id _t tsid,security_cl ass_t tclass,

22

4 ACCESSVECTORCACHE 4.2 Interfacesfor theSecurityServer

access_vect or_t perms);

The avc add callback function registers an objectmanager callbackfunctioncallback with theAVC com-ponent for policy changenotifications. Whenthe secu-rity server callsanAVC interfacethatcorrespondsto anevent in the set eventswith a SID pair, classand per-missionsthatmatchssid, tsid, tclassandperms, theAVCcomponentcallstheregistered callback function with theparametersprovided by the securityserver. The call-back functionmaythenupdateany affectedpermissionsthatareretainedin thestateof theobjectmanager. ThewildcardSID, SECSID WILD, maybeusedfor thessidandtsid parameters to matchall SID values.Permissionvectors matchif they have a non-null intersection. Themeaning of eachevent valueis explainedin thedescrip-tion of the corresponding interface in the next subsec-tion. Callbackfunctionshave not yet beenimplementedfor the kernel object managers, so this function is notcurrently called.

4.2 Interfacesfor the Security ServerThe function prototypes for the AVC interfaces

provided for the security server are in the in-clude/linux/flask/avcss.hheaderfile. Theseinterfacesareusedby the securityserver to managethe cacheasneededfor policy changes. This subsectiondescribeseachof theseinterfaces. For eachinterface,the func-tion prototypeis listed followedby a descriptionof theinterface.

int avc_ss_gran t(securit y_id_t ssid,securit y_id_t tsid,securit y_class_t tclass,access_ vector_t perms,__u32 seqno);

The avc ss grant function grants previously deniedpermissions for a SID pair andclass.ThewildcardSID,SECSIDWILD, maybeusedfor thessidandtsid param-etersto matchall SID values.This functionaddstheper-missionsin permsto theallowedvectorin any matchingentriesin thecache.It thencallsany callbacks registeredby anobjectmanager for theAVC CALLBACK GRANTevent with a matchingSID pair, classandpermissions.

Permissionvectors matchif they have a non-null inter-section. This function updatesthe latestpolicy changesequence number to the greaterof its current valueandtheseqnovalue.

int avc_ss_try_ revoke(securit y_id_t ssid,securit y_id_t tsid,securit y_class_t tclass,access_ vector_t perms,__u32 seqno,access_ vector_t *out_reta ined);

The avc ss try revoke function tries to revoke previ-ously grantedpermissionsfor a SID pair andclass,butonly if they arenotretained in thestateof anobjectman-ager. If any of thepermissionsin permsareretained,theretainedpermissions are returnedin out retained. ThewildcardSID, SECSID WILD, maybeusedfor thessidandtsid parametersto matchall SID values. This func-tion calls any callbacksregisteredby an object man-agerfor theAVC CALLBACK TRY REVOKE event witha matching SID pair, classandpermissions.Permissionvectors matchif they have a non-null intersection. Eachcallbackis expectedto identify which matchingpermis-sionsareretained in thestateof theobjectmanager. Thesetof retainedpermissions returned by eachcallbackisaddedto out retained. This function thenremovesanypermissions in permsthatwerenot retainedfrom theal-lowedvectorin any matchingentriesin thecache.Thisfunction updatesthelatestpolicy changesequencenum-berto thegreaterof its current valueandtheseqnovalue.

int avc_ss_revo ke(securit y_id_t ssid,securit y_id_t tsid,securit y_class_t tclass,access_ vector_t perms,__u32 seqno);

Theavc ss revokefunctionrevokespreviouslygrantedpermissions for a SID pair andclass,evenif they arere-tainedin the stateof an objectmanager. The wildcardSID, SECSIDWILD, may be usedfor the ssid and tsidparametersto matchall SID values. This function re-movesany permissions in permsfrom theallowedvec-tor in any matchingentriesin the cache. It then calls

23

4 ACCESSVECTORCACHE 4.3 Implementation

any callbacks registered by an object manager for theAVC CALLBACK REVOKE event with a matchingSIDpair, classandpermissions.Permissionvectorsmatchifthey have a non-null intersection. Eachcallbackis ex-pectedto revoke any matchingpermissions that arere-tainedin the stateof the objectmanager. This functionupdatesthelatestpolicy changesequencenumberto thegreaterof its current valueandtheseqnovalue.

int avc_ss_rese t(__u32 seqno);

Theavc ss resetfunction flushesthecacheandreval-idatesall permissions retainedin the stateof the ob-ject managers. This function invalidatesall entriesinthe cache. It thencalls any callbacksregistered by anobjectmanager for theAVC CALLBACK RESETevent.Eachcallbackis expectedto revalidatepermissions thatareretainedin thestateof theobjectmanager by callingavc haspermref audit or oneof its variants.This func-tion updates thelatestpolicy changesequencenumbertothegreaterof its currentvalueandtheseqnovalue.

int avc_ss_set_ auditallow(securit y_id_t ssid,securit y_id_t tsid,securit y_class_t tclass,access_ vector_t perms,__u32 seqno,__u32 enable) ;

Theavc ss set auditallow functionenablesordisablesauditingof grantedpermissionsfor a SID pairandclass.ThewildcardSID, SECSID WILD, maybeusedfor thessidandtsid parametersto matchall SID values.Theen-ableflag shouldbe1 to enableauditingand0 to disableauditing. This function addsor removes,depending onthe valueof enable, the permissions in permsfrom theauditallow vector in any matching entriesin thecache.Itthencallsany callbacks registeredby anobjectmanagerfor the AVC CALLBACK AUDITALLOW ENABLE orAVC CALLBACK AUDITALLOW DISABLE event witha matching SID pair, classandpermissions.Permissionvectors matchif they have a non-null intersection. Thisfunction updatesthelatestpolicy changesequencenum-berto thegreaterof its current valueandtheseqnovalue.

int avc_ss_set_ auditdeny(

securit y_id_t ssid,securit y_id_t tsid,securit y_class_t tclass,access_ vector_t perms,__u32 seqno,__u32 enable) ;

Theavc ss setauditdenyfunction enablesor disablesauditingof denied permissions for a SID pair andclass.It hasthesamebehavior asavc ss set auditallow, exceptthat it modifies theauditdenyvectorandit is associatedwith the AVC CALLBACK AUDITDENY ENABLE andAVC CALLBACK AUDITDENYDISABLEevents.

int avc_ss_set_ notify(securit y_id_t ssid,securit y_id_t tsid,securit y_class_t tclass,access_ vector_t perms,__u32 seqno,__u32 enable) ;

Theavc ss setnotify functionenablesor disablesno-tification of completed operations for a SID pair andclass.It hasthesamebehavior asavc ss setauditallow,except that it modifiesthe notify vectorand it is asso-ciatedwith theAVC CALLBACK NOTIFY ENABLEandAVC CALLBACK NOTIFY DISABLE events.

4.3 ImplementationThis subsectiondescribesthe implementation of the

AVC. The include/linux/flask/avc.h header file containsthe inline AVC functions that are called by the kernelobjectmanagers. The kernel/avc.csourcefile containstherestof theimplementationof theAVC.

The avc init interface is implemented in avc.c. Thisfunction allocatesmemory for all of the cache en-tries using kmalloc and addsthem to an internal freelist. This function also allocatesa page of mem-ory using get freepage to use as a buffer for thefs/dcache.c:d pathfunction whencreatingpathnamesforauditrecords.

Both avc haspermref audit andavc notify permrefare implemented as inline functions in avc.h. Eachof thesetwo functions disablesinterrupts locally andtakes a single global spin lock (avc lock) on en-try using spin lock irqsave, and each function uses

24

5 PROCESSMANAGEMENT

spin unlock irqrestore before returning. The avc lockis releasedbefore calling securitycompute av andreac-quiredupon thereturnfrom thatcall so that theAVC isnot lockedduring the accessvector computation by thesecurityserver. Similarly, the avc lock is releasedbe-fore calling securitynotify perm. The two inline AVCfunctions call avc.c:avc lookupto searchthe cacheandavc.c:avc insert to adda new entry to the cache. Theavc haspermref audit functioncallsavc.c:avc audit toauditpermissionchecks.

The avc.c:avc audit function uses printk to logwhetherpermissionwas granted or denied, the namesof therequestedpermissions, thesecuritycontexts of theSID pair, andthenameof theclass.If thecurrent processhasa nonzero PID, thenthePID andexecutablepathofthecurrent processarealsologged. Theexecutablepathis determined by using the fs/dcache.c:d path functionon theexecutable’s dentry.

If file systemaudit datais set, then the path,devicenumber andinodenumber arelogged. Thepathis like-wise determinedusingd path. If networking auditdatais set,theninformationabouteachfield that is setin thenet structureis logged. If the socket field is set to anAF INET socket, then the local and foreign addressesof the socket are logged. If the socket field is set toan AF UNIX socket, then the pathor abstractnameislogged. If the abstractnamespacewas used,then theinitial NULL character is replacedwith an“@” charac-ter. If thepacket field is setto an IPv4 packet, thenthesourceanddestinationaddressesarelogged. If thenet-work interfacefield is set,thenthenameis logged.

The avc ss grant, avc ss try revoke, avc ss revoke,avc ss setauditallow, avc ss setauditdeny andavc ss setnotify functions are implemented in avc.c.Eachof thesefunctionscallsavc.c:avc control with thecorresponding event value. The avc control functioncalls avc.c:avc update cache to update any matchingentriesin the cache,and avc control calls eachof thecallbacksregisteredfor theeventwith matchingparam-eters. If the event is AVC CALLBACK TRY REVOKE,then avc update cache is not called until after thecallbacks have been called, since the function mustobtainthesetof retainedpermissionsfrom thecallbacks.The avc update cache function disables interruptslocally and takes the global spin lock (avc lock) on

entry, releasingthe lock andenabling interrupts beforereturning. The avc control function disablesinterruptsandtakesthelock only to updatethelatestpolicy changesequence number.

The avc ss reset function is also implemented inavc.c. This function disablesinterrupts and takes theglobal spin lock to invalidate the cache. Then, af-ter enabling interrupts and releasing the lock, thisfunction calls each of the callbacks registered forthe AVC CALLBACK RESET event. Finally, theavc ss reset function disablesinterrupts and takes thelock againto update the latestpolicy change sequencenumber.

5 ProcessManagement

This sectiondescribes thedesignandimplementationof theFlasksecuritymechanismsfor Linux processman-agement.

5.1 Design

In this section,thedesignof theFlasksecuritymech-anismsin the Linux processmanagement component isdescribed. This sectionbegins by discussingthe objectclassesthatrequire control. Next followsadiscussionofthenew permissions.Thenthecontrol requirementsforthe processmanagementsystemcalls areoutlined. Fi-nally, thechanges to theAPI aredescribed.

5.1.1 Object Classes Processesare the major ab-stractionin the processmanagementcomponent. Theprocessobject class was defined for this abstraction.Whena processis created, it is assignedthe SID of itsparent. ThatSID mayonly bechanged whena new pro-gramis executed. Unlessotherwisespecified,the newSID dependsontheold SID andtheSID of thenew pro-gram.Sincethecomputationof thenew securitycontextmay involve policy-specificlogic, it mustbe computedby thesecurityserver.

An additional objectclass,capability , wasdefinedtocontrol the useof Linux capabilities. It is sufficient toonly checkcapabilityuse,but it couldalsobe useful toplacecontrols over their distribution thatcouldaugmentthecurrent approach . However, at this time thatwill notbedone.

25

5 PROCESSMANAGEMENT 5.1 Design

PERMISSION(S) DESCRIPTIONexecute Executetransition SID Transitionentrypoint Entervia programsigkill Signalsigstopsigchldsignalfork Forkptrace Tracegetsched Getschedule infosetsched Setschedule infogetsession Getsessiongetpgid Getprocessgroupsetpgid Setprocessgroupgetcap Getcapabilit iessetcap Setcapabilit ies

Table3: Permissions for theprocessobjectclass.

5.1.2 Permissions Table3 showsthepermissionsde-finedfor theprocessmanagementcomponent.Thepro-cessexecutepermissionis usedto control theability of aprocesstoexecutefromagivenexecutableimage.Thisisdistinctfrom thefile executepermissionwhichis usedtocontrol theability of aprocessto initiatetheexecution ofaprogram.SinceLinux onthex86doesnotsupport readwithout executepermissionson memorypages,thebestdegreeof control that canbe obtained in secureLinuxwill befrom theprocessexecutepermissioncheckthatisdone. The implicationof this is that it will be possiblefor a processto be tricked into executing memory thatwaswritten asdata.This problem would not bepresentonotherarchitecturesthatdonothave this limitation.

Thetransitionpermissionis usedto control theabilityof a processto transitionfrom oneSID to another. Theentrypoint permissionis usedto control whatprogramsmaybeusedastheentrypoint for a givenprocessSID.Thispermissionis similar to theprocessexecutepermis-sion,except that it is only checkedwhena processtran-sitionsto a new SID. Hence,thesecuritypolicy candis-tinguishbetweenwhatprogramsmaybeusedto initiallyentera given process SID andthe full setof programsthatmaybeexecutedby thatprocessSID.

This entrypoint permissionis especiallynecessaryinan environment with sharedlibraries, since most pro-cessesmustbeauthorizedto executethesystemdynamic

loader. Without separatecontrol over entry point pro-grams,any securitylabelcouldbeenteredby executingthesystemdynamic loader. Separateentrypoint controlis alsonecessaryin orderto support securitylabel tran-sitionson scripts,sincethe new securitylabel mustbeauthorizedto executetheinterpreterandthescript.

Separatepermissionsfor eachsignalcould easilybedefined, but until empiricalevidencesuggeststhis is nec-essary, this will not bedone.Separatepermissionsweredefinedfor the SIGKILL andSIGSTOP signals,sigkill,sigstoprespectively, sincethesesignalscannot becaughtor ignored. A separatepermission,sigchld wasalsode-finedto control theSIGCHLDsignalbecauseexperiencedemonstratedthatit wasuseful to control thissignalsep-arately. A singlepermission, signal, will beusedto con-trol theremaining signals.

Theptracepermissionisusedtocontrol theability of aprocessto traceanotherprocess.Thegetsched, setsched,getsession, getpgid, setpgid, getcap, andsetcappermis-sionsareusedto control the ability of a processto ob-serve or modify the correspondingattributesof anotherprocess. Additional potential controls for scheduling,sessions,processgroups,andcapabilitiesarediscussedin Section10.

Currently, a separatepermission for eachLinux ca-pability is definedfor the capability objectclass. Thisallows control over all of theabstractions for which ca-pabilitiesarecurrently defined. In the future, the con-trol points for eachcapability will require reexaminationto determine if the capability permissionis sufficient tocontrol theresource.

5.1.3 Control Requirements Table4 showsthecon-trol requirementsfor processmanagementsystemcalls.In it, the control requirementsfor eachsystemcall arespecified,whereeachcontrol requirement is describedby theclass,permission,sourceSID,andtargetSID usedin apermissioncheck.Sincemultiplecallsmayhavethesamerequirements,morethanonecall maybe listed intheleftmostcolumnof a singletableentry. In this case,all of therequirementsin that tableentryapply to all ofthecalls. In the table,thepath target SID indicatesthatthepermissioncheckshould beappliedto eachdirectoryin thepathprefix, andthedirectory classis abbreviatedby dir.

26


CONTROL REQUIREMENT(S)CALL(S) Class Permission SourceSID TargetSIDexecve Dir search Current Path

File execute Current FileProcess transition Current NewProcess entrypoint New FileProcess execute New FileProcess ptrace Parent NewFD inherit New FD

kill Process sigkill Current Targetsigstopsigchldsignal

wait Process sigkill Child Currentsigstopsigchldsignal

fork Process fork Current Currentcloneuselib Process execute Current Fileptrace Process ptrace Current Targetgetpriority Process getsched Current Targetgetschedulergetparamsetpriority Process setsched Current Targetsetschedulersetparamgetsid Process getsession Current Targetgetpgid Process getpgid Current Targetsetpgid Process setpgid Current Targetcapget Process getcap Current Targetcapset Process setcap Current Target

Table4: ProcessManagementControl Requirements.

The execvesystemcall is the mostcomplicated pro-cessmanagementcall to control. Therearetwo relevantfile systempermissionchecks,thesearch checkbetweentheprocessSID andSID of eachcomponentof thepath-nameto verify thattheprogramcanbeaccessedandtheexecutecheckbetweenthecurrent processSID andnewprogram’sSID to verify thattheprogramcanbeinitiatedby a processwith thatSID. Thefile systemcontrols aredescribedin Section 6.1. A processexecutecheckbe-tweenthenew processSID andthenew programSID isdoneto verify thatthenew processimagecanexecuteinthesecuritycontext of theprocess.

SinceLinux supportsa variety of binaryformatsthatmustbehandledduringtheexecvesystemcall, not onlymust accessto the program that is to be executed becontrolled, but accessto whatever programsareusedtosupport theexecution of thatprogrammustalsobecon-trolled. An example of this is that whena script is ex-ecuted,accessto the script mustbe checked aswell asaccessto the interpreterof thescript. Similarly, executechecksfor sharedlibrariesareneeded. In addition, exe-cutioncheckswill beplacedin theLinux-specificsystemcall, uselib, to control a process’ability to specifya par-ticularsharedlibrary duringexecution.

Theability of aprocesstochangeits SIDmustbecare-fully controlled. This is done during theexecveprocess-ing sincethis is theonly placewhereaprocess’SID maychange. Whetherthenew SID is specifiedor resultsfroma default transition,the transitionpermissionis checkedbetweenthe old andnew SIDs, andthe entrypointper-missionis checked betweenthe new SID and the pro-gramSID. SID transitions on executablescriptsarenotpreventedasis currently donein Linux with setuidtran-sitions. Transitionsareprevented,however, if the pro-cessis sharingpartsof theprocessstate,suchasthefiledescriptor tableor signalhandlers,ascouldbe thecasewhencertainvaluesfor theflagsaresuppliedto clone. Iftheprocessis beingtraced,thentheptracepermissionischeckedbetweentheparentprocessandthenew SID.

Whena SID transitiondoesoccurit is alsonecessaryto revalidateany descriptors.Theneedto control file de-scriptorsis further discussedin section 6.1. The inheritpermissionfor file descriptors is checkedfor eachopendescriptor. Any descriptor that doesnot passthe checkwill beclosed.Oneconsequenceof this is thatit is quite

27


possiblethatstdin, stdout, andstderrcouldbeunexpect-edly closedon anexecve. This is only aninconvenienceexcept in theconstructionof commandpipelines.Severaloptions to minimizethis impactexist. It maybepossibleto addressthis solelywithin thecurrent framework withcorrect policy specification.It mayprove worthwhile tocontrol thesedescriptors separatelyfrom therest.It mayalsobepracticalto modify theshellor construct specialwrapper programsto handle descriptorinheritanceandsecuritytransitionsproperly. Theissueis still beingstud-ied.

The sigkill, sigstop, sigchld and signal permissionswereaddedto control whetherparticularsignalsmaybesentto a processwith a given SID. As signalsareonlygeneratedfrom within thekernelor local processes,per-missionchecking will only be done whenthe signal issentandwill not berequired whenit is received. Beforea signal canbe deliveredthe appropriatepermissionischeckedbetweenthesenderandreceiver SIDs. Becausethe fcntl call canbeusedto settherecipientof a signalsgeneratedfrom asynchronousI/O, theSID of theprocessmustbesavedin thedescriptionto allow appropriatesig-nal checking to be done whenthe kernelgeneratesthesignal.

The ability of one process to wait on anotherneedsto becontrolledbecauseinformationcanbepassedwiththeexit status.Originally, thedesigncalledfor aprocesswait permission.It wasplannedthatwhenever asecuritycontext transitionwasto occur, thispermissionwouldbecheckedto determine if theparentprocesswouldbeableto wait on thechild. If so,thennormal processingcouldproceed. However, if the parentwasto be forbiddentowait onthechild, thechildwouldhavebeenreparentedtothe init processandtheparent awakenedwith anappro-priateerror status.This approach hadto be abandonedbecauseit proveddifficult to guaranteetheprocessgroupsemanticsof Linux.

The sameeffect can be more cleanly achieved withthesignalpermissions.Whenthewait systemcall is ex-ecuted,theprocesswill only beallowedto wait if thereis a child processthat matches the argument to the callthat is permitted to sendits exit signal to the process.Thisexit signalis setduring processcreationandcannotbe changed. If the permissioncheckfails andno othermatching childrenprocessesthatcansendtheir exit sig-

nal to the parentexist, the calling processis given anerrormessageindicatingthatnochild wasfound.

WhenaprocessundergoesaSID transition,it is possi-blethatthepolicy will nolonger permitasignalto bede-liveredto any processeswaitingonthatprocesswhenthetransformedprocessterminates.To ensurethatawaitingprocessis not left waiting in suchsituations,SID transi-tions causewaiting processesto be awakened. Waitingwill continueonly if it is in accordancewith thepolicy.

Control of the exit systemcall is not required. Thetwo issuesassociatedwith it, receiving exit statusinfor-mationandbeingsignaledby a child process,arehan-dled by the checking donefor the wait call andsignalmechanism. A sideeffect of this decisionis thata zom-bie processmayberetainedin theprocesstableuntil itsparent diessinceits parentmaybepreventedfrom reap-ing it. In that case,the zombied processwill have tobe reparented to the init processfor reaping, a mecha-nismalreadypresentin Linux. To makethisdesignworkproperly, it mustbepossiblefor all processes,regardlessof their securitydomain,to signalthe init processto en-surethatit will beableto reaporphanedprocesses.Thiscouldbeguaranteedusingthesecuritypolicy mechanismor throughcodemodifications to thesignalmechanism.

An additional ramificationof usingsignalcontrols tohandle wait and exit notifications comesas a result ofaPOSIXrequirement(POSIX3.2.2.2) to signalany pro-cessgroupwith stoppedjobswhichbecomesorphanedasaresultof anexit. If aprocesshasundergoneaSID tran-sition after it hasdoneoneor moreforks, its deathwillcausea signal to be sentto thosechildreneven thoughthepolicy mightprohibit it.

Linux presentsanadditional issuewith regard to sig-nalsandexiting. It is possiblefor aprocessto setthesig-nalthatit will receivewhenits parent exits. Thecheckingin thesignalmechanismwill determine if this signalcanbedelivered,but it maybedesirableto control theabilityto usethe prctl systemcall which setsthis signal. Thisissueis still beingexplored.

BecauseSID transitionsdo not occurduring the forksystemcall, mostsecuritypolicieswouldnot require theexplicit control of thiscall. Somepolicies,however, mayhave a needto restricta process’ability to createa newprocess.The fork permissionwasadded to support suchpolicies.It is checkedduring calls to fork andits Linux-

28


specificgeneralization clone.

The ptrace call is controlled using the ptrace per-mission. This permissionis initially checked upona PTRACE ATTACH or PTRACE TRACEME request.In the caseof PTRACE TRACEME, the permissionischeckedbetweentheparentprocessandthecalling pro-cess.Otherwise,it is checkedbetweenthe calling pro-cessandthetargetprocess.Thepermissionis alsoreval-idatedon theotherptracerequestssincethecalling pro-cessmay have changed its SID or the policy may havechanged. As describedearlier, the ptracepermissionisalsocheckedduring execveif theSID of a tracedprocesschanges.Finally, theptracepermissionis checkedwhena processattemptsto accessthememfile of another pro-cessin theprocfsfile system.

The getpriority, schedgetscheduler, andschedgetparam calls arecontrolled using the getschedpermission. The setpriority, schedsetscheduler, andschedsetparam calls are controlled using the setschedpermission. The getsid, getpgid, and setpgidcalls arecontrolled using the getsession, getpgid, and setpgidpermissions, respectively. The capget andcapsetcallsarecontrolled usingthegetcapandsetcappermissions,respectively. Thesepermissionsare checked betweenthecallingprocessandthetarget processif they differ.

Most systemcalls that requiresuperuserprivilegestorun should also be controlled by the policy. For thesecalls, it may only be necessaryto assigna permissionthatdeterminesif aprocesswith agiven SID canexecutethe call. SincetheLinux capability mechanismalreadycontrols many of thesecalls, the capability permissionsareusedto makethemsubjectto thecentralsecuritypol-icy. The sourceandtarget SIDS usedin the capabilitypermissionchecking areboththatof thecurrent process.Capabilitiesarediscussedfurtherin Section10.

Systemcalls thatonly permit a processto observe itsown private stateor to modify its own unprivileged pri-vatestatetypicallydonotrequirecontrols. Someof thesecalls are listed in Table5. Otherprocessmanagementsystemcallsmayneedto becontrolled by thepolicy. Areview of the systemcall interfaceto determine the setof callsthatneedadditional controls is describedin Sec-tion 10.

Editorial Note:

CALL(S) DESCRIPTIONget*uid Obtain currentprocessinformationget*gidgetgroupsgetitimergetpgrpgetpidgetppidgetrlimitgetrusagesignal Signal handlingsigactionsigalstacksigprocmasksigpendingsigsuspendnanosleep Pauseexecutionpause

Table5: ProcessManagementSystemCalls without Control Re-quirements.

execve secure(..., sid)Executea file with a specified SID.

getsecsid()GettheSID of currentprocess.

getosecsid( )GettheSID of currentprocessprior to thelastexecve.

Figure 15: New Linux processmanagement systemcalls forsecurity-aware applications.

Tables4 and5 respectively will be augmented to includeall PM systemcalls thatdo or do not requirecontrol.

5.1.4 API extensions Figure 15 lists the new pro-cessmanagementsystemcalls for security-awareappli-cations.A new call, execvesecure, wasaddedto allowa security-aware applicationto specify a new SID forthetransformedprocessresultingfromtheexecutionof anew program.Currently, thistheonlywaytoallow apro-cessto specifya SID to which it will transition.Theex-ecvecall will bea wrapper around this call thatrequeststhetransitionSID to becalculatedby thesecuritypolicy.Two othersystemcalls, getsecsidandgetosecsid, wereaddedto allow a processto get its SID andits SID priorto thelastexecvecall respectively.

29

5 PROCESSMANAGEMENT 5.2 Implementation

STRUCT FIELDtask sid

osidavc ref

linux binprm sidfown struct sid

Table6: Changes to processmanagement datastructuresfor label-ing.

5.2 ImplementationIn this section,the implementationof theFlasksecu-

rity mechanismsin theLinux processmanagementcom-ponent is described. This sectionbegins by discussingtheimplementationof support for labelingprocessman-agement objects. Then, the implementation of the newsystemcalls is described. Finally, the mapping of thecontrol requirementsto thecodeis specified.

5.2.1 Labeling Only minimal modificationsto Linuxdatastructuresarerequired to support theprocessman-agement labelingrequirements,asshown in table6. Newfields for the SID of a processandits SID prior to thelast call to exec were addedto the task structure. Toallow the systemto function properly, the INIT TASK,definedin include/linux/sched.h had to be modified toinitialize thesenew fields to the initial SID definedinflask/initial sids. A pointer into theaccessvectorcache,avc ref, wasalsoaddedto thetaskstructureto beusedasa performance enhancing hint to theaccessvectorcacheentry likely to containthe resultsof permissioncheck-ing for that process. A SID field was required in thelinux binprm structurewhich is usedduring exec pro-cessingto prepare the transformedbinary imageof theprocess. Lastly, a SID field was also required in thefown structto allow proper permissionchecking on sig-nalsgeneratedby asynchronousI/O.

5.2.2 API Extensions The existing Linux API wasextendedto includeanexecvesecure systemcall whichhasoneadditionalparameterto specifythesecuritycon-text for the transformedprocess.The main routine forexecveprocessing,do execvein fs/exec.c, wasrenamedto bedo execvesecure, andanadditional parameter wasaddedfor the SID of the specifiedcontext. A newdo execvethat calls do execvesecure with a null SID

was addedto handle the existing execvecall. Whenanull SID is encounteredduring processing, the securityserver is consultedvia the securitytransitionsid inter-facefor adefaultSID thatwill beused.

The two new processmanagementsystemcalls werestraightforwardly implemented in the sysgetsecsidandsysgetosecsidroutines addedto kernel/sched.c. Likeothersimilar calls, thesetake no argumentsand returnthe appropriateelementof the taskstructure aspointedto by current. As theinformationis requestedonly in thecontext of thecalling process,no securitychecking wasrequiredfor thesecalls.

All threecallswereaddedto thenew securitylibrarylibsecure anda new header file, proc secure.h wascre-ated. Additionally, new secure versions of the otherforms of execwhichallow thespecificationof a securitycontext wereaddedto this library. Alternatively, thesecouldhave,andprobablyshould have,beenplacedin theC library. They wereadded to this new library for easeof implementation and for portability reasonsand willlikely bemoved to theC library in thefuture.

5.2.3 Control Requirements The processmanage-ment permissionswere definedin flask/accessvectorsandinterpretedfor eachcomponentpolicy in theappro-priatefiles in policy. It is throughthesepolicy files thattheneedto allow everyprocessto signaltheinit processwasaddressed.PermissionchecksusingtheAVC inter-facewereadded at variousplacesthroughout thekernelasneeded.

A convenient location to place the execve accesscheckswas in the prepare binprm kernel routine usedin the implementation of the execvecall. This routinewasthenatural choice becauseit is usedfor loadingtheexecutable requestedin the systemcall argumentsandalso any otherexecutablesindicatedby the binary im-ageheader. The specifiedSID for the new processim-agewas madeaccessiblefrom the linux binprm struc-ture built for the call. The otherSID valuesnecessaryfor permission checkingwere already accessiblefromwithin this routine. In general,placingtheaccesschecksin this routinemadeit unnecessaryto placeadditionalchecksin all of theindividual binaryhandlers. However,it wasnecessaryto addprocessexecuteandfile executechecksin the ELF binary handler since it was possi-

30

5 PROCESSMANAGEMENT 5.2 Implementation

ble that it could call other interpreters that otherwisewould have gone unchecked. Thesecheckswereaddedto do load elf binary in fs/binfmtelf.c.

Sincesharedlibrariesareloadedusingmmap, a pro-cessexecutecheckwasneeded in theold mmaproutinedefinedin arch/i386/kernel/sysi386.c. Section6.1.3de-scribesthecompletecontrol requirementsof mmap. Thischeck,however, is not sufficient on thex86 architecturesincea file maybemmappedreadonly andstill beexe-cuted.This is actuallyaninstanceof thegeneral problemof not beingableto control execution of anything thataprocesscanread. Thesecurityimpactof this particularproblem andthe bestway to minimize it arestill beinginvestigated.

Whenever acall toexecveis goingto resultin achangein securitycontext, additional action must be taken toensurethat the policy cannot be violated. The call isaborted with the global variable errno set to EPERMwhen there is inappropriatesharingthat resultedfroma previous call to clone. Similarly, the call is abortedwith EPERMif theprocessis beingtracedandthepar-ent processlacksptracepermissionto the new SID forthe process.Opendescriptors mustbe revalidatedwiththe inherit permissionandclosedwhennecessary. Thisis done in a new function, revalidate fds which is mod-eled after the flushold files routine usedto check thecloseon exec flag, called from the flushold exec rou-tine. Finally, the computecreds routine was modifiedto updatethesid andosidfieldsof thetaskstructureandto call wake up interruptibleon theparent to forceper-missioncheckingif theparentwaswaiting on thetrans-formedprocess.If theprocessis not waiting, this actionis harmless.A small sideeffect to this approachis thatit is possiblefor a parentprocessto noticethat its childhasundergone a SID transitionwhich preventsit fromwaiting.

Linux currently checks if signalsmaybedeliveredinthesendsig info routinedefinedin kernel/signal.cwhichis thecentralcontrol point for thesignalmechanism.Theappropriate signal permissioncheckswere placedim-mediatelyafter the existing checks. When the checksfail, theglobal variable errno is setto EACCES.Linux’ssignalchecking for signalsresultingfrom asynchronousI/O is donein thesendsigio routinedefinedin fs/fcntl.c.Heretoo, thepermissioncheckingis done following the

existingchecks.On failure,nosignalis sent.

Signalcheckingis alsousedto control aprocess’abil-ity to wait on another. Checksto determine if a child’sexit signalcanbedeliveredto theparent wereaddedtothe syswait4 routine in kernel/exit.c. Whenever a pro-cessis awakened, Linux checksto seeif the wait callshouldreturnor if theprocessshouldbeplacedbacktosleep. At this time, the permissionchecksarerepeatedto ensurethat the waiting processcancontinue to wait.If not,thewait call returnswith theglobal variableerrnosettoECHILD. Thisensuresthatthewaitingprocesswillnot beblocked indefinitely. In this case,whenthechildeventually exits, it will remainazombiedprocessuntil itcanbereapedby the init process.

The executepermission check for a sharedlibraryspecifiedin uselib was placed in sysuselib. Failureabortsthecall with theglobal variableerrnosetto EAC-CES.

No specialchanges to fork or clone were necessaryto handlethe initialization of the new fields of the taskstructure. Whenthe init process is properly initializedduring systemstartup, thosefields are inherited fromtheparentprocessduring processcreationautomaticallywithout modification to the existing code. Since forkis implemented as a special caseof clone, only theclonecall actuallyneededmodification. Thepermissionchecking wasaddedto thedo fork routinedefinedin ker-nel/fork.c. TheSID of thecurrentprocesswasusedtwicein the call to the AVC. Failure abortsthe call with theglobal variableerrno setto EACCES.

Theptracepermissioncheckwasaddedto theptracesystem call (arch/i386/kernel/ptrace.c:sysptrace), theexecve call (fs/exec.c:must not traceexecflask), andthe access routines for the mem file in procfs(fs/proc/mem.c:get task). The scheduling, session,andprocess group permissionchecks were added to thecorresponding systemcalls in kernel/sched.cand ker-nel/sys.c. The setcapand getcap permission checkswere addedto the corresponding systemcalls in ker-nel/capability.c.

Thechecking for all of thecapability permissions wascentralizedin a singlelocation, thecapable functionde-fined in include/linux/sched.h. Becausethe capabilitychecksaredone here,not all of thecontext informationthatmightmakemoreinterestingsecuritypoliciespossi-

31

6 FILE SYSTEM 6.1 Design

OBJECTCLASSpipedirectoryregular filesymboliclinkcharacterdeviceblock deviceFIFOsocket filefile systemfile description

Table7: Object classesfor theLinux file systemcomponent.

ble is available.This limits thecheckto only thecurrentprocessSID andpreventsthe ability to limit the useofa capabilityon a per-objectbasisaswaspossiblein theDTOSsystem.TheAVC referencein the taskstructurewasusedfor thesepermissionchecks. An important noteis thatthecapabilitypermissionscorrespondto thecapa-bility definitions in linux/include/linux/capability.h. Theimplementationof thechecking mechanismis dependentonthecorrect orderingof thepermissiondefinitionswithrespectto thecapabilitydefinitions.

6 File System

This sectiondescribes thedesignandimplementationof theFlasksecuritymechanismsfor theLinux file sys-tem.

6.1 DesignThis sectiondescribes our designfor integrating the

Flask security mechanisms into the Linux file systemcomponent. It begins with a discussionof the objectclassesandpermissions definedfor thefile systemcom-ponent. This is followed by a descriptionof the con-trol requirementsfor the systemcalls usedto manageandperform directory andfile operations. Then,theap-proach for providing persistentlabelsfor files, directo-ries,andfile systemsis discussed.Finally, thenew file-relatedsystemcalls definedfor security-aware applica-tionsaredescribed.

6.1.1 Object Classes The logical abstractionspro-videdby theLinux file systemcomponentwerestudiedto determine the setof objectclassesthat neededto be

labeledandcontrolledby theFlaskmechanisms.Thesetof objectclassesfor thefile systemcomponentis shownin Table7. Threeabstractions thatneedto becontrolled,pipes,files,anddirectories,wereimmediatelyevidentinthe Linux API. Files were further refinedinto separateobjectclassesfor eachfile typedefinedby theLinux API,i.e. regularfiles,symboliclinks, characterdevices,blockdevices,FIFOs,andUnix domainsocketfiles.

Whenapipeis created,it inherits theSID of thecreat-ing processby default. Whena directory or file is cre-ated, it is assigneda SID that represents the securitycontext in which it is createdby default. This contextdepends on the securitycontext of the creatingprocessand the securitycontext of the parent directory. Sincethecomputationof thenew securitycontext mayinvolvepolicy-specificlogic, it mustbecomputedby thesecurityserver.

Although file systemsarenot treatedasfirst-classob-jects in the Linux API, a separateobjectclasswasde-finedfor thefile systemabstraction. Entirefile systemsarelabelednotonly to control operationssuchasmount-ing andunmounting but alsoto representthe aggregatelabelof all files within thefile system.

Finally, an object classwas definedfor the file de-scription abstraction. The term file descriptionis usedby POSIX[3] to describetheinformationreferencedbyafile descriptor, e.g. thefile offset,file statusandfile ac-cessmodesfor anopen file. File descriptorsmaybein-heritedacrossexecvecalls,andthey maybetransferredthrough IPC. Consequently, it is necessaryto label andcontrol file descriptions. TheSID of a file description isinheritedfrom theSID of theprocessthatcreatedit.

6.1.2 Permissions For eachobject class,asetof per-missionswasdefinedto control accessto objectsin thatclass.Thesepermissionswereidentifiedby studying theservicesprovided by the Linux file systemcomponent.For eachservice,theobjectswhosestateis observedormodifiedby theservicewereidentified, andpermissionsfor thecorresponding objectclassesweredefined.

Table 8 shows the permissionsdefined for control-ling accessto the pipe object classand to the file ob-ject classes.Unlike theexisting Linux file permissions,which only control the ability to opena file, the Flaskreadandwrite permissionsaredefinedfor theactualser-

32


PERMISSION(S) DESCRIPTIONread Readwrite Write or appendappend Appendpoll Poll/selectioctl IO controlcreate Createexecute Executeaccess Checkaccessibilitygetattr Getattributessetattr Setattributesunlink Remove hardlinklink Create hardlinkrename Renamehardlinklock Lock or unlockrelabelfrom Relabelrelabeltotransition

Table8: Permissionsfor thepipeandfile object classes.

PERMISSION(S) DESCRIPTIONadd name Add a nameremove name Remove a namereparent Changeparentdirectorysearch Searchrmdir Removemounton Useasmountpointmountassociate

Table9: Additional permissionsfor thedirectory object class.

vicesof reading from a file or writing to a file. Theim-plicationsof this stricterdefinitionarediscussedfurtherin Section6.1.3. A separateappendpermissionwasde-fined to support append-only accessto a file. WhereastheexistingLinux accesscontrols permit certainservicesbasedonly on theattributesof thedirectory, suchastheservicefor obtaining a file’s attributesandthe servicesfor adding, removing or renaming a hardlink to a file,Flaskprovidesfiner-grainedcontrol throughcorrespond-ing file permissionssuchasgetattr, link, unlink, andre-name. Threepermissionsaredefinedfor therelabel ser-vice,sinceit is usefulto control therelationshipbetweeneachpairingof the threeSIDs involved: theSID of thesubject,theold SID of thefile, andthenew SID for thefile.

Table9 shows the additional permissionsdefinedfor

PERMISSION(S) DESCRIPTIONmount Mountremount Changeoptionsunmount Unmountgetattr Getattributesrelabelfrom Relabelrelabeltotransitionassociate Associate file

Table10: Permissionsfor thefile systemobject class.

PERMISSION(S) DESCRIPTIONcreate Creategetattr Getattributessetattr Setattributesinherit Inherit acrossexecvereceive Receive via IPC

Table11: Permissions for thefile description object class.

manipulatingdirectories.Threeseparatepermissionsareprovidedfor addingentriesto directories, removing en-triesfrom directoriesandchanging theparent entry(the.. entry) of a directory during a rename. In contrast,theLinux accesscontrols usethewrite accessmodeforall threeservices.Two permissionsaredefined for themount service,where the mounton permissionis usedto control the ability of a subjectto mount on a givenmountpoint and the mountassociatepermissionis usedto control the relationshipbetweenthe mounteddirec-tory andthemountpoint.

Permissionsfor controlling accessto file systemsareshown in Table10. Permissionsareprovided for con-trolling mounting andunmountingandfor obtaining filesystemattributes,suchasthenumberof freeblocks.Aswith files, threepermissionsaredefinedfor the relabelservice.Theassociatepermissioncontrols whatfiles arepermittedin thefile system.

Table11 lists thepermissions for controlling accesstofile description objects.Eachof thesepermissionsis im-plicitly grantedfor file descriptionobjects with thesameSID asthe subject. The getattr andsetattrpermissionscontrol servicesthatobserve or modify theflagsandthefile offsetof thefile description. The inherit andreceivepermissions control theserviceof inheriting descriptors

33


acrossanexecveandtheserviceof receiving descriptorsthrough IPC,respectively.

6.1.3 Control Requirements After defining permis-sionsfor theservicesprovidedby theLinux file systemcomponent,control requirementsweredefinedfor eachLinux systemcall thatprovidesoneor moreof theseser-vices.Thecontrol requirementsspecifythepermissionsthat mustbe grantedfor the systemcall to successfullyexecute.

In the following tables,the control requirementsforeachsystemcall are specified,whereeachcontrol re-quirement is describedby the class,permission, sourceSID (SSID),andtarget SID (TSID) usedin a permissioncheck.Sincemultiple calls mayhave thesamerequire-ments,more thanonecall maybe listed in the leftmostcolumnof a single tableentry. In this case,all of therequirementsin thattableentryapplyto all of thecalls.

In thetables,thepathtargetSID indicatesthattheper-missioncheckshould beappliedto eachdirectory in thepathprefix. File systemclassesandSIDsareabbreviatedby fs, file descriptionclassesandSIDsareabbreviatedbyfd, anddirectory classesandSIDsareabbreviatedby dir.A file permissioncheckusesthe classof the file beingaccessed,so the file classin the tablesmay be the pipeclass,thedirectory class,or any of thefile objectclasses.

Several of the systemcalls listed in the tableshavetwo forms, one of which takes a pathname parameterandtheothertakesa file descriptor parameter, e.g. statandfstat. In the tables,this is expressedas(f)stat. Thecorresponding control requirementsareidenticalexceptthatthedescriptor-basedcall naturally doesnot have thesearch requirement.

Table 12 shows the control requirementsfor systemcalls that manipulate files. The control requirementslisted in this table for the opensystemcall are the re-quirementsfor opening an existing file ratherthan therequirementsfor creatinga new file. The processmustbeableto searchthedirectoriesin thepathprefix, anditmustbeabletocreatethefile description. Theread, writeandappendrequirementsontheopen systemcall areen-forcedin accordancewith the flagsto open. The writepermissiongrantseitherwrite accessor append access.Theappend permissionis only checkedif write permis-sionis notgrantedandtheO APPEND flag is specified.

CONTROL REQUIREMENT(S)CALL(S) CLASS PERM SSID TSIDopen dir search current path

fd create current fdfile read current filefile write current filefile append current file

read, fd setattr current fdreadv, file read current filepreadwrite, fd setattr current fdwritev, file write current filepwrite file append current filesendfile fd setattr current in fd

file read current in filefd setattr current out fdfile write current out filefile append current out file

mmap fd setattr current fdmprotect file read current file

file write current filefile append current fileprocess execute current file

(f)stat dir search current pathlstat file getattr current file(f)chmod, dir search current path(f)chown, file setattr current filelchown,(f)truncate,utime(s)access file access current filepoll, file poll current fileselectfcntl: file lock current fileF GETLK,F SETLK,F SETLKWflockioctl: file getattr current fileFIBMAPioctl: fd getattr current fdFIONREAD file getattr current fileioctl: file getattr current fileFIGETBSZioctl: file getattr current fileGETFLAGS,GETVERSIONioctl: file setattr current fileSETFLAGS,SETVERSIONioctl file ioctl current file

Table12: Control requirementsfor manipulating files.

34


Sincethe read, write, andappend permissions arein-tendedto control the actualservicesof reading from afile andwriting (or appending) to afile, it is necessarytoverify that the permissionsarestill granted whenthoseservicesareperformed.Thepriorchecksduringtheopencall mayno longerbevalid, sincetheprocessmayhavechangedSID, thefile mayhavechangedSID, adifferentprocessmaybeusingthefile description, or a change inthe securitypolicy mayhave occurred. Hence,the sys-tem calls which implement thoseservices,suchas theread, write andsendfile systemcalls,mustrevalidatethepermissions obtained during open. The calls mustalsoverify that setattrpermissionto the file description pa-rametersis granted, sincethe file offset is modified bythesecalls.

Whenafile is mappedinto memory via themmapcall,theread, write, andappendpermissionsarerevalidated.However, thepermissionsmaybecome invalid while thefile is still mapped. Consequently, thepermissionsmustberevalidatedwhenpages arereadfrom thefile or writ-ten to thefile, andthepagesfor a file in thepagecachemustbeinvalidatedwhenthefile is relabeled or a policychange that would affect accessto the file occurs. Themmapcall mustalsocheckthe processexecutepermis-sion to control the ability of a processto executefroma particularsharedlibrary. The mprotectcall mustalsorevalidatethesepermissionswhenthecurrent protectionis changed.

Table 13 shows the control requirementsfor systemcallsthatmanipulate directories. In additionto requiringsearch permissionto directories in the pathprefix, thechdir, fchdir, andchroot systemcallsrequiresearch per-missionto the last componentof the path. The controlrequirementslisted in this table for the openandcreatsystemcallsaretherequirementsfor creatinga new file.Theprocessmusthavesearch permissionto thedirecto-ries in the pathprefix, createpermissionto the file de-scription,add namepermission to the parentdirectory,andcreatepermissionto thenew file. Furthermore,thefile must have associatepermission to the file system.The requirementsfor mkdir, mknod, and symlinkonlydiffer from therequirementsfor openin that thereis nofile description.

Therenamesystemcall requiressearch permissiontoboth paths,remove namepermissionto the old parent

CONTROL REQUIREMENT(S)CALL(S) CLASS PERM SSID TSID(f)chdir, dir search current pathchroot dir search current diropen, dir search current pathcreat fd create current fd

dir add name current parentfile create current filefs associate file fs

mkdir, dir search current pathmknod, dir add name current parentsymlink file create current file

fs associate file fsrename dir search current oldpath

dir remove name current oldparentfile rename current filedir reparent current filedir search current newpathdir add name current newparentdir remove name current newparentfile unlink current newfil edir rmdir current newfil e

link dir search current pathdir add name current parentfile link current file

unlink dir search current pathdir remove name current parentfile unlink current file

rmdir dir search current pathdir remove name current parentdir rmdir current dir

getdents, fd setattr current fdreaddir dir read current dirreadlink file read current file

Table13: Control requirementsfor manipulating directories.

35


CONTROL REQUIREMENT(S)CALL(S) CLASS PERM SSID TSIDremount dir search current path

fs remount current fsmount dir search current devpath

dir search current dirpathfs mount current fsdir mounton current dirdir mountassociate root dir

umount dir search current pathfs unmount current fs

ustat fs getattr current fs(f)statfs dir search current path

fs getattr current fs

Table14: Control requirementsfor manipulating file systems.

CONTROL REQUIREMENT(S)CALL(S) CLASS PERM SSID TSIDlseek, fd setattr current fdllseekfcntl: fd setattr current fdF SETOWN,F SETSIGfcntl: fd setattr current fdF SETFL file write current filefcntl: fd getattr current fdF GETFL,F GETOWN,F GETSIGioctl: fd setattr current fdFIONBIO,FIOASYNC

Table15: Control requirementsfor manipulatingdescriptions.

directory, renamepermission to the file and add namepermissionto thenew parent directory. If thefile beingrenamedis a directory, andits parent directory wouldbechanged by the rename,then reparent permissionmustbe granted to the file. If a file alreadyexists at thenew pathname, then remove namepermission must begranted to the new parentdirectory andunlink permis-sionor rmdir permissionmustbegrantedto theexistingfile or directory.

Table 14 shows the control requirementsfor systemcalls that manipulate file systems.The remount call inthetablerepresents themount systemcall usedwith theMS REMOUNTflag. The mount call in the table rep-resentsthe mount systemcall usedto mount a file sys-

tem. Mounting a file systemrequiressearch permissionto boththedevicespecialfile pathnameandto themountpointpathname,mount permissionto thefile system,andmounton permission to the mount point directory. Theroot directory of thefile systemmusthave mountassoci-atepermissionto themount point directory.

Table 15 shows the control requirementsfor systemcallsthatmanipulatefile descriptions. If a file is openedwith the O APPENDflag, andthis flag is subsequentlyclearedvia the F SETFLcommandof the fcntl systemcall, thenwrite permissionmust be grantedto the file.Theothersystemcallsin this tableonly observeor mod-ify thestateof thefile descriptionitself, sothey only re-quiregetattr or setattrpermissionto thefile description.The F SETOWN andF SETSIG commands to the fcntlsystemcall mustalsobe checked againstprocessman-agement control requirementsto ensurethat the callingprocessmaycausesignalsto besentto theowner.

Note that Table 15 does not include entries forfcntl.F SETFD, fcntl.F GETFD, ioctl.FIONCLEX orioctl.FIOCLEX. Theseoperations may be usedto ob-serve or modify theclose-on-exec flag of a file descrip-tor. Theclose-on-execflag of a file descriptor is privateto thatfile descriptorandis notpartof thefile descriptionstate.Hence,this flag is not sharedandaccessto it doesnot require any permissions.

6.1.4 Persistent Labeling Since file systems,files,and directories are persistentobjects, an approach forproviding persistentlabelsfor theseobjectswasdevel-oped. To ensurethat thesecurityattributesof theseob-jects arepreserved even if the file systemis moved toanother system,the Linux file systemcomponentmustmaintainatablewithin eachfile systemthatspecifiesthesecuritycontext of the file systemandeachfile anddi-rectorywithin that file system. This approachalsoen-suresthatthesecurityattributesarepreservedover time,evenif thepolicy changes,andthatthesecurityattributescanbeinterpretedby auserif amanual translationof at-tributesfor anew policy is required.

TheLinux file systemcomponentcanhandle securitycontexts without sacrificingpolicy flexibility or perfor-manceby treating security contexts as opaque stringsandby mapping theselabelsto SIDs by a queryto thesecurityserver for internaluseby the file systemcom-

36

6 FILE SYSTEM 6.2 Implementation

open secure(..., fd sid, f sid)Opena file with a file description labeled fd sid. If creating,create thenew file with label f sid.

mkdir secure(..., sid)Create a directory labeledsid.

mknod secure(..., sid)Create a nodelabeledsid.

symlink secure(... , sid)Create a symboliclink labeled sid.

stat secure(..., sidp)Getfile SID of pathname.

lstat secure(..., sidp)Getsymboliclink SID of pathname.

fstat secure(..., sidp)Sameasabove, except usinga fd.

statfs secure(..., sidp)GetfilesystemSID of file systemfor pathname.

fstatfs secure(... , sidp)Sameasabove, except usinga fd.

chsid(pathn ame, sid)Relabel file pathnameto sid.

fchsid(fd, sid)Sameasabove, except usinga fd.

lchsid(path name, sid)Relabel symboliclink pathnameto sid.

chsidfs(pat hname, fs sid, f sid)Relabel thefilesystemfor pathname.

fchsidfs(fd , fs sid, f sid)Sameasabove, except usinga fd.

Figure16: New Linux file-relatedsystemcalls for security-awareapplications.

ponent. For efficient storage,thefile systemcomponentmayassigna fixed-sizevalue,referredto asa persistentSID (PSID),to eachsecuritycontext associatedwith anobjectin thefile system,andmaythenpartitiontheper-sistentlabelingtableinto a mapping betweeneachPSIDandits securitycontext anda mapping betweeneachob-jectandits PSID.ThePSIDis purely aninternalabstrac-tion within thefile systemandhasa distinctnamespacefor eachfile system.Hence,PSIDsmaybe lightweightandthe allocationof PSIDsmay be optimizedfor eachfile system.

6.1.5 API extensions To permit applications to cre-ateobjectswith a specifiedlabel ratherthanthedefault

CONTROL REQUIREMENT(S)CALL(S) CLASS PERM SSID TSID(f)chsid dir search current path

file relabelfrom current filefile relabelto current newfile transition old newfs associate new fs

(f)chsidfs dir search current pathfs relabelfrom current fsfs relabelto current new fsfs transition old new fsfs associate new file new fs

Table16: Control requirementsfor relabeling.

label,anextendedform of eachof thefile creationsys-tem calls mustbe addedthat acceptsan additional SIDparameter. To permit applicationsto obtainthe SID ofanobject,anextendedform of eachof thefile statussys-tem calls must be addedthat return an additional SIDparameter. To permitapplications to change the SID ofan object, new systemcalls must be added. The newLinux systemcallsthatmustbeaddedfor security-awareapplicationsareshown in Figure16.

For the new systemcalls that are simply extendedformsof existingLinux systemcalls,thesamesetof con-trol requirementsapply. Thecontrol requirementsfor thenew systemcallsfor relabeling areshown in Table16.

6.2 ImplementationIn thissection,ourimplementationof theFlaskfile se-

curity mechanismsin theLinux file systemcomponent isdescribed. Theimplementationbeganby adding supportfor labelingfile systemobjects,followedby theadditionof thenew systemcalls.Finally, thecontrolrequirementswereimplemented.

6.2.1 Labeling Thekernel datastructureswerestud-ied to identify thestructuresusedinternallyfor mountedfile systems(structsuperblock), activefilesanddirecto-ries (struct inode), andfile descriptions(structfile). Allthreeof thesestructuresaredefinedin include/linux/fs.h.Sincethesestructuresareprivateto thekernelandhaveno specificsizerequirements,a SID field wasaddedtoeachstructure. Sincea struct inode object is usedtorepresent all typesof files, anobject classfield wasalsoaddedto thestructure.

37


Two otherprivatekernel datastructuresalsorequiredtheaddition of SID fields. Theinodeattributesstructure(struct iattr) is usedfor changing theattributesof a file,so a SID field wasaddedto this structure,anda corre-sponding flag (ATTRSID) was definedto indicatethatthe SID is being changed. The file description ownerstructure(structfown struct) is usedto storetheidentityof theprocessthatsettheowneron a file description, soa SID field wasaddedto this structure.

The implementation of the persistentlabeling tablewas partitionedinto a component that is independentof the file systemtype (fs/psid.c) and a set of compo-nentsthatarespecificto eachfile systemtype. Most oftheimplementationresidesin thefilesystem-independentcomponent; hence,persistentlabeling support for ad-ditional file systemtypes may be easily added. Thefilesystem-independent componentimplements themap-ping betweeneachPSID and its securitycontext usingregular files in a fixedsubdirectory of theroot directoryof eachfile system.TwoPSIDsarereserved: PSID0 rep-resentsthedefault labelto assignto unlabeledobjectsinthefile system,andPSID1 representsthelabelof thefilesystemitself. The subdirectory andits files arealwaystreatedasbeinglabeledwith a fixedsecuritycontext sothat the securitypolicy may control accessto the map-ping. Synchronouswrites areusedto update the map-ping files andthewritesareordered to ensurethat therearenodangling references.

The interface to the filesystem-independentcompo-nent is defined in include/linux/flask/psid.h. The filesystemcalls the fs/psid.c:psidinit function to initial-ize the mapping betweenPSIDsand securitycontextswhenthefile systemis mounted(fs/super.c:mount root,fs/super.c:do mount). If the file systemis unlabeled,then this function obtains the SIDs for the unlabeledfile systemfrom the security server. If the file sys-tem is unlabeledand it is being mounted read-write,then this function createsa new PSID mapping on thefile system. If an unlabeled file systemis mountedread-only initially andis subsequently remountedread-write, then the fs/psid.c:psidremount function createsa new PSID mapping on it when it is called byfs/ext2/super.c:ext2 remount. The file systemcalls thefs/psid.c:psidreleasefunction to free any memory andreleaseany files usedfor the PSID mapping when the

file systemis unmounted(fs/super.c:do umount).

The filesystem-specificcomponents implement themapping betweeneach file and its PSID. Currently,thefilesystem-specificcomponenthasonly beenimple-mentedfor thenative Linux file systemtype,ext2. Theext2-specificcomponentstoresthePSIDfor eachfile ina formerly unusedfield of the on-disk inode structure(struct ext2 inode). Sincethe PSID is readily availablein theon-disk inode,noextraoverheadis incurredeitherto obtainthe PSID whena file is accessedor to set thePSIDwhena file is created.

The ext2fs code calls the fs/psid.c:psidto sidfunction to obtain the SID of an existing inodebased on its PSID when the inode is read fromthe disk (fs/ext2/inode.c:ext2 read inode). Thefs/psid.c:sidto psid function is calledto obtaina PSIDfor aninode basedon its SID whenaninodeis allocated(fs/ext2/ialloc.c:ext2 new inode) or whenthe SID of aninodeis changed (fs/ext2/inode.c:ext2 notify change).

6.2.2 API extensions Due to the large number ofnew file-relatedcalls and the potential needfor futureexpansion, the new file-relatedcalls were implementedas library functions that invoke a single systemcall,flaskfilecall, with a first parameter that identifies thespecificcall. Internally, the Linux file systemcompo-nentusesa variant of theVirtual File System(VFS) in-terface. Extended forms of the file creationoperationswere addedto this interface to permit the filesystem-independentcodeto passthe SID of the new file to thefilesystem-specificcode. New operationswouldnothavebeennecessaryif theexistingfile creationoperationsac-cepteda general attributestructureasa parameter, asintheBSD VFS interface.

SID parametersneededto beaddedto several internalfunctionsto support thenew systemcalls.Someof theseinternal functions are called from many different loca-tions within the kernelandmay be calledfrom kernel-loadedmodules. Consequently, it was not practicaltosimply change theexisting function andupdate all callsto it. For suchfunctions, secure wasappendedto thefunction name,andthe interfaceandimplementationofthe function wereextended for the new processing. Astubfunction thatmerelycallsthenew functionwith de-fault parameterswasadded usingtheold function name

38


andinterface.This permitstheexistingcodeto continueto usetheold function interface,but introducestheover-headof anextra function call in thesecases.

6.2.3 Control Requirements TheLinux file systemcodewasstudiedto determine thelocationto implementeachpermissioncheckassociatedwith the control re-quirementsspecifiedin the design. Several factorsin-fluencedtheplacement of permissionchecks.Wheneverpossible,thepermissioncheckswereimplementedin thefilesystem-independent codeso that they areappliedtoall file systemtypes. Only a few control requirementsarespecificto theext2file systemtype,sothiswasfeasi-ble for almostall of thepermissionchecks. Permissionsaretypically checkedasearlyaspossiblein theprocess-ing of eachsystemcall to simplify cleanupfrom permis-sionfailuresandto easemaintenanceof thechecksasthefile systemcodeevolves. For servicesthatarealsocon-trolled by a Linux accesscontrol check, the Flaskper-missioncheckwasusuallyimplementedat thesamelo-cation. However, a Flaskpermissioncannot becheckeduntil thekerneldatastructuresfor thenecessaryobjectsareaccessibleandappropriately locked. This requireddeferring someof the Flask permissionchecks until alaterpoint in theprocessing.

To reducetheoverheadof permissionchecks, thefilesystemcomponentwas changed to storereferences toAVC entrieswith its file description(struct file) objectsand inode (struct inode) objects. Two reference fieldswere addedto the struct file: one for the permissionsgranted to the file description, andone for the permis-sionsgrantedto thefile. Sincemany of thefile operationsusepathnameparametersratherthanfile descriptors, afield for storinga referenceto theAVC entrycontainingthepermissionsgranted to thefile wasalsoaddedto thestructinode.

Table17showsthecontrol requirementsimplementedin eachkernel function usedto manipulate files. Onlythe class and permission are shown for each controlrequirement; the sourceSID and target SID can befound in the corresponding design table. The func-tionsthatimplement theservicesfor readingandwritingfiles revalidate the permissionsinitially checked duringopennamei, using the AVC entry referencein the filedescription. Sincethesepermissionsalso migrate into

CONTROL REQUIREMENT(S)FUNCTION(S) CLASS PERMfilp open fd createopennamei file read

file writefile append

sys read, fd setattrsys pread, file readfilemap nopagedo readvwritev fd setattr

file readfile writefile append

sys write, fd setattrsys pwrite, file writefilemap write page file appendsys sendfile fd setattr

file readfd setattrfile writefile append

old mmap fd setattrsys mprotect file read

file writefile appendprocess execute

cp new stat,cp old stat file getattrinode changeok file relabelfrom(SID) file relabelto

file transitionfs associate

inode changeok file setattr(other)sys access file accessdo select, file polldo pollsys fcntl: file lockF GETLK,F SETLK,F SETLKWsys flockfile ioctl: file getattrFIBMAPfile ioctl: fd getattrFIONREAD file getattrfile ioctl: file getattrFIGETBSZext2 ioctl: file getattrGETFLAGS,GETVERSIONext2 ioctl: file setattrSETFLAGS,SETVERSIONsys ioctl file ioctl

Table17: Implementing thefile control requirements.

39


CONTROL REQUIREMENT(S)FUNCTION(S) CLASS PERMlookup dentry dir searchsys (f)chdir, dir searchsys chrootmay create dir search

dir add nameopennamei, file createdo mkdir, fs associatedo mknod,do symlinkdo link file linkmay delete dir search

dir remove namevfs unlink file unlinkvfs rmdir dir rmdirvfs rename file renamevfs rename dir dir reparent

dir rmdirvfs rename other file unlinksys getdents, fd setattrold readdir dir readsys readlink file read

Table18: Implementing thedirectory control requirements.

the pagecachefor memory-mapped files, any cachedpagesfrom a file are invalidatedwhen the SID of afile is changed. As a result, subsequent accessto thepageswill causefilemapnopage to beexecuted.The in-odechange ok function implementsboththepermissionchecksfor changing theSID of a file andthepermissioncheckfor changingtheordinaryLinux attributesof afile.Only thecontrol requirementsimplementedin ext2 ioctlarespecificto thefilesystemtype.

The control requirementsimplemented in eachker-nel function usedto manipulate directories are shownin Table18. The lookupdentry function checkssearchpermissionon eachdirectory in the pathprefix. All ofthe systemcalls usethis function to perform pathnamelookup. Thefunctionsfor changing thecurrent androotdirectoriesmustalsoperform a search permissioncheckagainst the last componentof thepath. Themaycreateand maydeletefunctions provide convenient locationsfor theFlaskcontrol requirementson thecontaining di-rectory. Theunlink andrmdir permissioncheckshadtobeimplementedseparatelyfromthemaydeletefunction,sincethosechecks shouldnot be appliedwhen the re-

CONTROL REQUIREMENT(S)FUNCTION(S) CLASS PERMdo remount fs remountdo mount fs mount

dir mountondir mountassociate

do umount fs unmountsys ustat fs getattrsys (f)statfs fs getattrsys (f)chsidfs fs relabelfrom

fs relabeltofs transitionfs associate

Table19: Implementing thefile systemcontrol requirements.

CONTROL REQUIREMENT(S)FUNCTION(S) CLASS PERMsys lseek, fd setattrsys llseeksys fcntl: fd setattrF SETOWN,F SETSIGsys fcntl: fd setattrF SETFL file writesys fcntl: fd getattrF GETFL,F GETOWN,F GETSIGsys ioctl: fd setattrFIONBIO,FIOASYNC

Table20: Implementing thefile description control requirements.

namecall removes the old link. The sysgetdentsandold readdir functions revalidate read permissionusingtheAVC entryreferencein thefile description.

The remaining tables(Table 19 andTable 20) showthecontrol requirementsimplementedin thekernel func-tions usedto manipulate file systemsand file descrip-tions. The mount and mountassociatepermissionsde-pendon the SID of the file systembeingmounted andthe SID of the root directoryof that file system. Con-sequently, thesechecksare deferred until after the filesystemmetadatahasbeenloaded,just prior to linkingthefile systeminto thefile systemnamespace.

40

7 OTHERFILE SYSTEMTYPES 7.1 Procfs

7 Other File SystemTypes

This section describeshow the Flask file securitymechanisms were applied to control accessto severaladditional file systemtypes. Thesectionbegins by dis-cussingthe analysis,design,andimplementationof la-beling for the procfsfile system. It thendiscussesthedesignandimplementationof labelingfor thedevptsfilesystem.Finally, it discussesthedesignandimplementa-tion of labelingfor NFSclientsupport.

7.1 Procfs

This subsectionbegins with an analysisof the procfsfile systemandits implementation. Thedesignfor label-ing procfsfiles is thendescribed.Finally, theimplemen-tationof labelingandcontrols is discussed.

7.1.1 Procfs Analysis The Linux procfsfile systemprovidesan interface to kernel datastructuresasan al-ternative to thetraditional /dev/kmeminterface.This filesystemis typically mountedat /proc. The /proc file sys-tem hierarchy is describedin the proc(5) manualpageandin theDocumentation/proc.txt file.

TheLinux sysctlsystemcall providesaninterfaceforreading andwriting systemparameters. Thissystemcallis describedin the sysctl(2)manualpage. The systemparametersarearranged in a treestructure,andthey aretypically alsoaccessiblethrough aparalleldirectory treeunder the /proc/syssubdirectory. In additionto thepre-viously mentioneddocuments,the /proc/syshierarchy isdescribedin thefiles in theDocumentation/sysctldirec-tory. Basedon the documentationfor sysctl, it appearsthat applications should always usethe /proc/sysinter-faceinsteadof the systemcall interfacefor portabilityacrosskernelversions.

Thereis a subdirectory for eachrunning processun-der /proc, named by its processidentifier. A processmay alwaysusethe /proc/self symbolic link to refer toits own subdirectory. Theeffective uid andeffective gidof theprocessis usedfor theuserandgroupownership ofthefiles andsubdirectorieswithin eachprocess-specificsubdirectory. Severalfiles in thesesubdirectoriespermitany userto readthem: the cmdline, maps, stat, statm,andstatusfiles. The remainingfiles may only be readby the owner. The memfile, which providesaccessto

the memory of the process,mayonly be readandwrit-ten by the owner. The procfs implementation only per-mits a processto accessits own memfile or the memfile of a child processthat is stoppedandbeing traced(fs/proc/mem.c:get task). The Linux 2.2.12 kernel im-plementation doesnot support write accessto the memfiles dueto a risk of overwriting kernelmemoryif a pro-cessdiesin themiddleof a write, but future versionsofthekernelarelikely to support suchaccess.

Most of the files in /proc outside of the process-specific subdirectoriesare readableby all users. Themostnotableexceptionsare/proc/kmsgand/proc/kcore,which are only readable by the superuser. The/proc/kmsgfile is usedby klogd asasourceof kernelloginformationasanalternativeto thesyslog systemcall in-terface.The/proc/kcorefile providesaccessto thephys-ical memoryof the systemin corefile format, andcanbeusedby gdbto examinethecurrent stateof any kerneldatastructures.Thekernel implementationalsorequiresthataprocesspossesstheCAP SYSRAWIOcapabilitytoopenthe/proc/kcorefile (fs/proc/array.c:openkcore).

Only the superuser may write to files in /proc out-side of the process-specificsubdirectories. Most filesthat can be written correspond to systemparametersand are located in /proc/sys. A few files outsideof/proc/sys also permit writing for configuration. Forexample, /proc/mtrr may be written to manipulate thememory type range register, as described in Docu-mentation/mtrr.txt. Someof the files under /proc/ide,/proc/scsi, /proc/bus, and /proc/parport may be writtenfor device configuration.

The types and functions provided by theprocfs file system to the kernel are defined in in-clude/linux/proc fs.h. Entries in the /proc file systemare defined by struct proc dir entry objects. Theproc register function maybeusedto addanentryundera given parent entry, andthecreateproc entry functionmay be used to create and register a dynamicallyallocatedentry given a name,mode,and parent entry.Functions arealsoprovidedfor registering entriesundercertainwell-definedsubdirectories, such as the net orscsisubdirectories.

Whenan entry in /proc is lookedup, an inodeis ob-tainedfor the entry. The fs/proc/inode.c:proc get inodefunction copiestheownerandmode attributesfrom the

41

7 OTHERFILE SYSTEMTYPES 7.1 Procfs

entry into the inode when it is requestedby a lookup.This function alsocalls the entry’s fill inodeoperation.For process-specificfiles, this operation is implementedby thebase.c:proc pid fill inodefunction, which copiestheeffective uid andeffective gid of theassociatedpro-cessinto the inode. The inode.c:proc read inode func-tion alsocopiesthe effective identity attributesinto theinodewhentheinodefor aprocess-specificfile is initial-ized.

Thetypesandfunctionsprovidedby thesysctlcall tothekernel aredefinedin include/linux/sysctl.h. A sysctltable is definedby an array of struct ctl table objects.Eachobjectmay containa pointer to an arrayof childobjects.Thestaticallydeclared kernel/sysctl.c:root tablecontains the baseset of sysctl entries. The sysctl initfunction calls the register proc table function to createthecorrespondingentriesunder /proc/sys.

Additional sysctl tablesmay be addeddynamicallyby using the register sysctl table function. Unlikeproc register, this function doesnot link the new tableinto an existing tablein thehierarchy. Instead,the newtable is addedto a linked list of top-level tables. Con-sequently, dynamically-registered tables must containdummy entriesto provide the pathfrom the root of thehierarchy to thenewly registeredparameters. Theregis-ter sysctltablefunctionalsocallstheregister proc tablefunction on thenewly registeredtable.

When the sysctl system call is called, the ker-nel/sysctl.c:parse table function looks up the appropri-atestruct ctl table object,calling the ctl perm functionto checkthat the processhassearchaccessto eachta-ble in the prefix. Whena matchingentry is found, thedo sysctlstrategy function calls ctl perm to checkthattheprocesshastheappropriatereadand/orwrite accessto the table. Thectl permfunction is alsocalledby thedo rw proc functionwhenasysctlparameteris accessedthrough /proc/sys.

7.1.2 ProcfsLabeling Design To enable thesecuritypolicy to control accessto eachprocess-specific subdi-rectorybasedon thesecurityattributesof theassociatedprocess,eachprocess-specific subdirectory andits fileswill belabeledwith theSID of theassociatedprocess.Ifthesecuritypolicy needsto beableto distinguish thein-dividual files within eachprocess-specificsubdirectory,

thenanew interfacecouldbeaddedto thesecurityserverthatwould returntheSID for eachfile basedon theSIDof theassociatedprocess.However, it is notevidentthatthe securitypolicy will require suchdistinctions. Thiscontrasts with the distinctions in file modesamongthefiles in theprocess-specificsubdirectory.

Of particular notein the process-specific subdirecto-riesarethememfiles,sincethesefiles have thepotentialto provide readandwrite accessto thememory of otherprocesses.However, the existing restrictionson accessto memseemadequate if theability to ptraceachild pro-cessis controlledby the securitypolicy. Suchcontrolsneedto beaddedto theprocessmanagementcomponent.

Mostof thefiles outsideof theprocess-specificsubdi-rectorieshave thesamefundamentalsecurityproperties:readable by everyoneandwriteableonly by administra-tors. Consequently, mostof thesefiles may be labeledwith a singleSID. This labelingschememaybefurtherrefinedover time to providebettersupport for leastpriv-ilege. It seemsdesirableto provide support for easilyspecifying a distinct SID at any point in the /proc hier-archy and automatically assigningthat SID to all filesbelow that point that are not explicitly labeled. Thiswill permit gradual refinement of labelingwith minimalchanges.

Due to the highly sensitive natureof the kmsgandkcore files,eachof thesefiles will belabeledwith a dis-tinct SID to permit fine-grainedcontrol over accesstoeachfile. Note that the FlaskcapabilitypermissionforCAP SYSRAWIOwill alsoneedto begrantedfor accessto thekcorefile.

As with theLinux accesscontrols for sysctl, theFlaskcontrols should be samewhether a parameteris ac-cessedthrough /proc/sysor through the sysctl systemcall. Hence,file mandatoryaccesscontrols will beaddedto thesysctlsystemcall codeto parallel thecontrols thatarealready enforcedwhen/proc/sysis accessed.As aninitial step toward leastprivilege, the kernel, vm, net,fs, and dev subtreeswill eachbe labeledwith a dis-tinct SID. Additionally, the /proc/sys/kernel/modprobefile will have a distinct SID to permit fine-grainedcon-trol over the ability to change the pathexecuted by thekernelto automatically loadkernelmodules. Theotherfiles anddirectoriesunder /proc/syswill belabeledwitha SID thatdistinguishesthemfrom therestof /proc.

42

7 OTHERFILE SYSTEMTYPES 7.2 Devpts

7.1.3 Procfs Labeling Implementation Thebase.c:proc pid fill inode function and the in-ode.c:proc read inode function in fs/proc werechanged to copy the SID of the associatedprocessinto the inode for the process-specificfiles. The in-ode.c:proc readsuperfunctionwaschangedto initializethe SID of the root directory andthe file systemof theprocfs file systemto the proc initial SID. The initialSID wasdeclaredin flask/initial sidsanddefined in thesecuritypolicy configuration.

A sid field was addedto the struct proc dir entrystructurein include/linux/proc fs.h. Thefield wasaddedat the end of the structure to ensurethat the stati-cally declared structurescould be left unchanged. Theproc root kcore, proc root kmsg, andproc sysroot def-initions in fs/proc/root.cwerechangedto settheSID ex-plicitly to a distinct initial SID value. The initial SIDsweredeclaredin flask/initial sidsanddefinedin these-curity policy configuration.

The inode.c:proc get inode function was changed tocopy theSID fromthestructproc dir entrystructureintothe inode if the SID is non-null. This change permitsentriesto be individually labeledby settingthe SID inthe structure. If the SID is null, then the inode is leftunlabeledby proc get inode.

The fs/proc/root.c:proc lookup andfs/proc/fd.c:proc lookupfd functions were changedto copy the SID from the parent directory inode if theinodeis unlabeledafterthecall to proc get inode. Thesechanges causeunlabeled entries to be automaticallylabeledwith theSID of theirparentdirectory.

A sid field was addedto the struct ctl table struc-turein include/linux/sysctl.h. Thefield wasaddedat theendof thestructureto ensurethat thestaticallydeclaredstructures couldbeleft unchanged.Thekernel, vm, net,fs, anddev entriesin the kernel/sysctl.c:root table def-inition werechanged to set the SID of eachentry to acorresponding initial SID. The modprobe entry in thekern table definition waschanged to set the SID of theentry to a corresponding initial SID. The initial SIDsweredeclaredin flask/initial sidsanddefinedin these-curity policy configuration.

The ctl table inherit sid function was addedto ker-nel/sysctl.c. Thisfunction traversesasysctltableanden-suresthatall entriesarelabeled,usinginheritance from

the parent entry as necessary. The sysctl init functionwaschangedto call this function ontheroot table.

Thectl table root sid function wasalsoaddedto ker-nel/sysctl.c. This function is usedto copy theSIDsfromtheroot sysctltableinto thedummyentriesin a dynam-ically registeredsysctl table. The ctl table inherit sidfunction may thenbe usedto ensurethat all of the en-triesin thedynamicallyregisteredsysctltablearelabeledproperly. Theregister sysctltablefunctionwaschangedto call thetwo functions.

Theregister proc table function waschangedto copytheSID of thectl tablestructure into theproc dir entrystructurereturnedby createproc entry. This change en-suresthatthe /proc/sysentriesarelabeledwith thesameSID asthecorresponding sysctlentry.

Thectl permfunction waschangedto checktheFlaskdirectory search permissionwhena tableentry is beingtraversed. This function wasalsochangedto checktheFlask file read and/orwrite permissionswhen a tableentry is beingaccessed.Thesechangesensurethat theFlaskcontrols areenforcedwhenthe sysctlsystemcallis used. Sincethe ctl perm function is also called bydo rw proc, thesechecksarealsoredundantlyperformedwhenasysctlparameter is accessedthrough /proc/sys.

7.2 DevptsThedevptsfile systemprovidesaninterfaceto pseudo

terminal(pty) devices.It is typicallymountedat /dev/pts.A new pty device file is dynamically createdwhenthe/dev/ptmx pty mastermultiplex device is opened. Atmount time,auseridentity, group identity, andmodecanbespecifiedfor all ptyfilesin thedevptsfile system.Typ-ically, this featureis usedto set the group andmodetoallow write accessby programsthataresetgidto the ttygroup. A useridentity is typically notspecifiedat mounttime. In theabsenceof thecorrespondingmount option,theuserand/or group identity is inheritedfrom thepro-cessthatcreatedthepty.

As with theprocfsfile system,an initial SID wasde-fined for the devpts file systemand its root directory.The SIDs of the file systemand root directory are setto this valueby the fs/devpts/inode.c:devpts readsuperfunction. Thedevptsstatfsfunction returns this SID astheSID of thefile system.Thedevpts read inodefunc-tion returns this SID astheSID of theroot inode.

43

8 NETWORKING

To permitthesecuritypolicy to controlaccessto indi-vidual ptys,thedevptspty new functionwasmodified tocall thesecurityserver’s securitytransitionsid interfaceto obtaina SID for eachnew pty file. The SID of thecreatingprocessandtheSID of theroot directory of thedevptsfile systemarepassedto this interface asinputs.Thesecurityserverreturns aSID derived from thesetwoSIDs.Ptyfilesmayneedto besubsequentlyrelabeledbyprogramsto reflectchangesin thelabelof theassociatedprocess.For example, the login programcouldrelabela pty createdby rlogind basedon the initial securitycontext of theusershell.

7.3 NFSclient supportTo allow thesecuritypolicy on anNFSclient to con-

trol accessto file systemsmountedfrom ordinary NFSservers,eachNFSfile will be labeledbasedon theNFSserver identity. A file systemsecuritycontext anda filesecuritycontext canbespecifiedfor eachNFSserver inthepolicy configuration.Thesecontextsareappliedtoallfile systemsandall files mountedfrom theNFSserver.

An initial SID is definedasthe default SID for NFSfile systemsandtheir files. If securitycontexts arenotdefinedfor the NFS server in the policy configuration,thenthesecuritynfs sid functionreturnsthis initial SID.Otherwise,thesecuritynfs sid function returnstheSIDsthatcorrespondto thesecuritycontexts in theconfigura-tion.

The fs/nfs/inode.c:nfs readsuperfunction obtainstheSIDs for the file systemandroot directoryfrom these-curity server using the securitynfs sid function. Thenfs statfs function returns the file system SID. Thenfs fill inodefunctioncopiestheinodeSID fromtheSIDof theroot directory. Thenfs notify change function re-turnsEACCESif theSID is beingchanged,or it checkssetattrpermissionotherwise.

Separatelabelscould be supported for different filesystemsmounted from the sameNFS server, but thiswould require thenfs readsuperfunction to passanad-ditionalparameter to securitynfs sid to identify thepar-ticularfile system.Sincethemountcall is only providedwith the NFS file handlefor the root directory (asop-posedto the pathname on the server), this is currentlynot implemented. If themount programweremodifiedto alsopassthe pathname,thenthe configurationcould

OBJECTCLASSTCPsocketUDP socketraw IP socketUnix streamsocketUnix datagramsocketnodenetwork interface

Table21: Object classesfor theLinux networking component.

specifysecuritycontexts basedon both theserver iden-tity andthepathnameontheserverfor theroot directory.

8 Networking

This sectiondescribes thedesignandimplementationof theFlasksecuritymechanismsfor Linux networking.


Flask security mechanismsinto the Linux networkingcomponent. It begins with a discussionof the objectclassesandpermissionsdefinedfor thenetworking com-ponent. This is followedby a descriptionof thecontrolrequirementsfor the systemcalls usedto manage andperform network interprocesscommunication. Finally,the new socket systemcalls definedfor security-awareapplicationsaredescribed.

8.1.1 Object Classes The object classes for theLinux implementation of the AF INET and AF UNIXprotocol families are shown in Table 21. SinceLinuxusesthe BSD socket API, the socket is the principalcontrolled objectclass. Thesocket objectclasswasre-fined into separateobject classesfor the different typesof sockets. Whena socket is createdvia thesocket call,it inherits the SID of the processthat createdit by de-fault. If the socket is createdby a connection, then itinherits the SID of the listeningsocket by default. Analternativeapproachwouldbeto havethesecurityservercompute theSID of thenew socket basedon theSID ofthelisteningsocketandtheSID of theclient socket.

The Linux network component createstwo specialpurposesockets for useby the AF INET protocol fam-ily. The tcp socket is usedto sendresetswhena TCP

44

8 NETWORKING 8.1 Design

packetis rejected,sincetheremaybenolocalsocketcor-respondingto thepacket.Theicmp socket isusedtosendICMP messages.Two initial SIDsweredefinedfor thesesockets, with the corresponding securitycontext deter-minedby thesecurityserver.

For socket types that maintainmessageboundaries,eachmessageis separatelylabeled. For other sockettypes,eachmessageis implicitly associatedwith theSIDof its sendingsocket. Althoughmessagesarelabeledandcontrolled,aseparateobjectclassis notnecessary. Whena messageis senton a socket, it inherits theSID of thesendingsocket by default. When the network compo-nentreceivesamessagefrom thenetwork, theSID of themessageis initially setto a default messageSID associ-atedwith the receiving network interface. This defaultmessageSID is computedby the securityserver. If themessagewasprotectedusingthe IPSECprotocols, thentheSID of thereceived messageis setbasedontheinfor-mationin thecorresponding securityassociation.

Eachmessageis also associatedwith the SID of itssourcesocket and the desiredSID for its destinationsocket. By default, the desiredSID for the destinationsocket of a messageis setto theany socket initial SID.Whenamessageis receivedfromthenetwork, thesourcesocket SID of the messageis initially set to the defaultmessageSID for the receiving network interface. If themessagewasprotectedusingIPSECprotocols,thenthesourcesocketSID andthedestinationsocket SID aresetbasedoninformationin thecorresponding securityasso-ciation.

The nodeobjectclasswasdefinedto permit controlson inboundmessagesbasedonthesourceaddressandtopermitcontrols on outboundmessagesbasedon thedes-tinationaddress.Thenetwork interfaceobjectclasswasdefinedto permit controls basedonthenetwork interfaceusedto sendor receive a message.TheSIDs for nodesandtheSIDsfor network interfaces arecomputedby thesecurityserver.

TCPandUDPportnumbersarelabeledto permitcon-trols over the ability to bind to particular ports. Onlythoseport numberswhich areoutsideof the rangeusedto automatically bind sockets, ip local port range, arelabeledandcontrolled. Like messages,a separateob-jectclassis notnecessaryfor port numbers.ThesecurityservercomputesSIDsfor theportnumbers.

PERMISSION(S) DESCRIPTIONbind Bind namenamebind Useport or fileconnect Initi ateconnectiongetopt Getsocket optionssetopt Setsocket optionsshutdown Shutdown connectionrecvfrom Receive from socketsendto Sendto socketrecv msg Receive messagesendmsg Sendmessage

Table22: Additionalpermissionsfor thesocket object classes.

If anAF UNIX socket is associatedwith anobjectinthefile systemnamespace,therearetwo different objectswith separateSIDs that representthesocket in differentways. TheAF UNIX socket objectis createdfirst usingthesocket call andit inheritstheSID of thecreatingpro-cessby default. The socket file object is createdby asubsequentbind call on thesocket,andit is labeledwitha SID computedby thesecurityserverbasedon theSIDof the creatingprocessandtheSID of the parent direc-tory. The socket file objectcontinuesto exist until it isexplicitly unlinkedfrom thefile systemnamespace.If anAF UNIX socketis associatedwith anamein theabstractnamespace,thereis noseparateobjectfor thename.

8.1.2 Permissions Since sockets are accessedthrough file descriptions, the socket object classesinherit thepermissions definedfor controlling accesstothe file objectclasses.Only the read, write, poll, ioctl,create, lock, getattr, setattr, relabelfrom, relabelto, andtransitionfile permissionsaremeaningful for sockets.

Table22showsadditional permissionsthatarespecif-ically defined for controlling accessto thesocket objectclasses.Thebind, connect, getopt, setopt, andshutdownpermissionscontrol theability of processesto invokevar-ioussocket-specific systemcalls. For AF INET sockets,the namebind permission controls the relationship be-tweena socket andits port number. For AF UNIX sock-ets, the namebind permissioncontrols the relationshipbetweena socket andits file. The recvfrom andsendtopermissions control the relationshipbetweenthe send-ing socket andthe receiving socket for datagrams. Therecvmsgandsendmsgpermissionscontrol therelation-

45


PERMISSION(S) DESCRIPTIONlisten Listenfor connectionsaccept Accept a connectionnewconn Create new socket for connectionconnectto Connect to server socketacceptfrom Accept connection from client socket

Table 23: Additional permissions for the TCP and Unix streamsocket objectclasses.

PERMISSION(S) DESCRIPTIONgetattr Getattributessetattr Setattributestcp recv Receive TCPpackettcp send SendTCPpacketudp recv Receive UDP packetudp send SendUDPpacketrawip recv Receive Raw IP packetrawip send SendRaw IP packet

Table24: Permissionsfor thenetwork interfaceobject class.

ship betweena datagrammessageandthe receiving orsendingsocket. Thesetwo permissionsare implicitlygranted if themessageSID is equalto thesending socketSID.

The connection-orientedserviceprovided by streamsocketsrequiresseveral additionalpermissions,asshownin Table23. The listen andaccept permissions controltheability of processesto invoke thecorresponding sys-temcalls.Thenewconn permissioncontrols therelation-ship betweenthe server socket createdby a connectionand the listeningsocket. This permission is implicitlygranted if thesocketshave thesameSID. Theconnecttoandacceptfrom permissions control the relationshipbe-tweentheclientsocketandtheserversocket.

The setof permissionsfor the network interfaceob-ject classis shown in Table24. The setattrandgetattrpermissions control the ability of processesto manip-ulate the interfaceparameters. The remaining permis-sionscontrol therelationshipbetweenamessageandthenetwork interfaceon which it is sentor received. Simi-lar permissionsaredefinedfor thenode object class,asshown in Table25,to control therelationshipbetweenaninboundmessageandits sourceaddressandtherelation-ship betweenan outbound messageand its destination

PERMISSION(S) DESCRIPTIONtcp recv Receive TCPpackettcp send SendTCPpacketudp recv Receive UDP packetudp send SendUDPpacketrawip recv Receive Raw IP packetrawip send SendRaw IP packetenforcedest Enforcedestinationsocket

Table25: Permissionsfor thenodeobject class.

PERMISSION(S) DESCRIPTIONroute control Manipulaterouting tablesarp control ManipulateARP tablerarp control ManipulateRARPtablenet io control Usedevice-specific ioctl

Table26: Additionalpermissionsfor thesystemobject class.

address.Theenforce destpermissionfor thenodeobjectclasswasdefinedto support theextendedsocketcalls,asdescribedin Section8.1.4.

Table 26 shows permissionsthat were addedto thesystemobjectclassfor thenetworking component.Theroutecontrol permissioncontrols the ability of a pro-cessto manipulate the kernel IP routing table. Thearp control and rarp control permissionscontrol theability of a processto manipulatethekernelARP cacheand RARP table, respectively. The net io control per-mission controls the ability of a processto invoke adevice-specificioctl onanetwork device.

8.1.3 Control Requirements This subsectionde-scribesthe control requirementsfor eachLinux systemcall thatprovidesa serviceimplementedby thenetworkcomponent. The control requirementsspecify the per-missionsthatmustbegrantedfor thesystemcall to suc-cessfullyexecute. In the following tables,the controlrequirementsfor eachsystemcall arespecified,whereeachcontrol requirementis describedby the class,per-mission,sourceSID (SSID),andtargetSID (TSID) usedin apermissioncheck.Sincemultiplecallsmayhavethesamerequirements,morethanonecall maybe listed intheleftmostcolumnof a singletableentry. In this case,all of therequirementsin that tableentryapply to all ofthecalls.

46


CONTROL REQUIREMENT(S)CALL(S) CLASS PERM SSID TSIDlisten socket listen current so

socket newconn so newconn sidconnect socket connect current client so

socket connectto client so server sonetif tcp send client so netifnode tcp send client so nodenetif tcp recv server so netifnode tcp recv server so node

accept socket accept current listen sosocket newconn listen so server sosocket acceptfrom server so client sonetif tcp send server so netifnode tcp send server so nodenetif tcp recv client so netifnode tcp recv client so node

write, socket write current sosend, socket connectto so peersosendto, socket acceptfrom so peersosendmsg netif tcp send so netif

node tcp send so nodenetif tcp recv peerso netifnode tcp recv peerso node

read, socket read current sorecv, socket connectto so peersorecvfrom, socket acceptfrom so peersorecvmsg netif tcp send so netif

node tcp send so nodenetif tcp recv peerso netifnode tcp recv peerso nodefd receive current fd

Table27: Control requirementsfor connection-oriented communi-cation. The tcp sendandtcp recvpermissionrequirementsonly applyto TCPtraffic, not Unix stream traffic. Thereceivepermissionrequire-mentonly appliesto Unix streamtraffic containing file descriptors.

In the tables,network interfaceclassesandSIDs areabbreviated by netif. A socket permission checkusesthe class of the socket being accessed,so the socketclassin the tablesmaybeany appropriatesocket objectclass.Socket SIDsareabbreviatedby so. Sincea singlecall may involve multiple sockets,socket SIDs may beprefixed with a distinguishing identifier, suchas listen ,client , server, or dst .

Table 27 shows the control requirementsfor systemcalls usedto perform connection-orientedcommunica-tion. For eachof thesecalls, permission is required toinvoke the call on the socket, i.e. the listen, connect,accept, write, and read permissions.For Unix stream

socketsthatarebound in thefile systemnamespace,theclient processmustbegranted search permissionto thedirectoriesin thepathandwrite permissionto thesocketfile in orderto useconnect.

On theserver node,thenewconnpermissionmustbegranted betweenthe listeningsocket andthenewly cre-atedserver socket, andthe acceptfrom permissionmustbe granted betweenthe server and client sockets. ForTCP, thesepermissionsarecheckedwhentheserver re-ceivestheclient’s SYNpacket on a listeningsocket. Ontheclientnode, theconnecttopermissionmustbegrantedbetweentheclientsocketandtheserversocket. For TCP,this permissionis checked when the client obtains thelabel of the server socket from the server’s SYN-ACKpacket. If a TCP simultaneous openoccurs, thenbothnodes checkconnecttopermissionwhenthey receive theother node’s SYNpacket. The appropriate connectionpermission(connectto or acceptfrom) must be revali-datedwhentraffic is sentor received on an establishedconnection, sincea policy changemay revoke permis-sionfor theconnection. In thiscase,theconnectionmustbereset.ForTCP, oneachnode,theappropriatetcp sendandtcp recvpermissionsmustbegrantedfor thenetworkinterfaceandthepeernode.

For Unix streamsockets, the connectto permissioncheck is redundant with the acceptfrom permissioncheck,sincethe connectionis local. Nonetheless,bothpermissionchecks are performed to maintain consis-tency with the TCP controls. The network control re-quirementsfor Unix streamsocketsonly differ from theTCP requirementsin that thereis no equivalent for thetcp sendandtcp recvpermissionchecks.

Thereis alsoanadditional file control requirementforUnix streamor datagramcommunication, thereceivere-quirement on file descriptions. As explained in the filesystemcontrol design, openfile descriptionsmustbela-beledand controlled. The receivepermission must begranted betweenthereceiving processandeachopenfiledescription received through Unix streamor datagramcommunication.

Thecontrol requirementsfor connectionlesscommu-nicationareshown in Table28. As with theconnection-orientedcalls,permissionis required to invoke eachcallon the socket, i.e. the connect, write, andreadpermis-sions. For Unix datagram socketsthatarebound in the

47


CONTROL REQUIREMENT(S)CALL(S) CLASS PERM SSID TSIDconnect socket connect current sowrite, socket write current sosend, socket sendto so dst sosendto, socket sendmsg so msgsendmsg netif udp send msg netif

node udp send msg nodenetif rawip send msg netifnode rawip send msg node

read, socket read current sorecv, socket recvfrom so src sorecvfrom, socket recv msg so msgrecvmsg netif udp recv msg netif

node udp recv msg nodenetif rawip recv msg netifnode rawip recv msg nodefd receive current fd

Table 28: Control requirementsfor connectionlesscommunica-tion. Theudp sendandudp recvpermission requirementsonly applyto UDP traffic. The rawip sendand rawip recv permissionrequire-mentsapply to any IPv4 traffic other than TCP or UDP. The receivepermissionrequirementonly appliesto Unix datagramtraffic contain-ing file descriptors.

file systemnamespace,theclientprocessmustbegrantedsearch permissionto thedirectories in thepathandwritepermissionto the socket file in order to use connect,sendto, or sendmsg.

On the sendingnode,the sendtopermissionmustbegranted betweenthesource anddestinationsockets,andthe sendmsgpermissionmust be grantedbetweenthesourcesocket andthe message.For AF INET sockets,by default,theany socket initial SID is usedasthedesti-nationsocket SID in thesendtopermissioncheck, sincethesendingnode doesnot know theSID of thedestina-tion socket. On thereceiving node, therecvfrompermis-sionmustbegrantedbetweenthedestinationandsourcesockets, and the recvmsgpermissionmust be grantedbetweenthe destinationsocket and the message.ForIPv4 traffic, on eachnode, theappropriateudp sendandudp recvpermissions,or therawip sendandrawip recvpermissions, mustbe grantedfor the network interfaceandthepeernode.

For Unix datagram communication, the SID of des-tination socket is known when the sendtopermissioncheckis performed,soit is usedin thecheck.Thesendtopermissioncheckis redundantwith therecvfrompermis-

CONTROL REQUIREMENT(S)CALL(S) CLASS PERM SSID TSIDsocket socket create current sobind socket bind current so

socket namebind so portgetsockname socket getattr current sogetpeername socket getattr current sogetsockopt socket getopt current sosetsockopt socket setopt current soshutdown socket shutdown current so

Table29: Control requirementsfor othersocket calls.

sion check,sincethe communicationis local andsincethe actualdestinationsocket SID is usedin the sendtopermissioncheck.Nonetheless,bothpermissionchecksare performed to maintain consistency with the UDPandraw IP controls. Thenetwork control requirementsfor Unix datagramcommunicationonly differ from theUDP requirementsin that thereis no equivalent for theudp sendandudp recvpermissionchecks. As with Unixstreamcommunication, thereis theadditional receive(fd)file control requirementwhenreceiving file descriptors.

The control requirementsfor the other socket callsareshown in Table29. The createpermissionmustbegranted in orderto createa socket with the socket call.Theothercalls all require permissionto invoke thecallon an existing socket, e.g. the getattr permission. ForAF INET sockets,if thebind call is invokedwith a portnumber outsideof the rangeusedto automatically bindsockets,thenthenamebind permissionmustbegrantedbetweenthe socket andtheport number. For AF UNIXsockets,if thebindcall is invokedwith anamein thefilesystemnamespace, thenthenamebind permissionmustbegrantedbetweenthesocketandthesocketfile.

The control requirementsfor the ioctl commands areshown in Table30. Thecommandsfor manipulating theattributesof a network interfacearecontrolled throughthe setattrandgetattr permissionson eachnetwork in-terface.Theremainingcommandsarecontrolledthroughsystempermissions.

8.1.4 API extensions Figure 17 shows the newLinux socket system calls that must be added forsecurity-aware applications. The getsocknamesecure,getpeernamesecure, accept secure, recvfrom secure,

48


CONTROL REQUIREMENT(S)CALL(S) CLASS PERM SSID TSIDioctl: TIOC- socket getattr current soOUTQ,INQioctl: SIOC- netif getattr current netifGIFADDR,GIFBRDADDR,GIFDSTADDR,GIFNETMASKioctl: SIOC- netif setattr current netifSIFFLAGS,SIFADDR,SIFBRDADDR,SIFDSTADDR,SIFNETMASKioctl: SIOC- system route- current kernelADDRT, controlDELRT,RTMSGioctl: SIOC- system arp- current kernelDARP, controlGARP,CSARPioctl: SIOC- system rarp- current kernelDRARP, controlGRARP,CSRARPioctl: system net io- current kerneldevice-specific control

Table30: Control requirementsfor ioctl commands.

and recvmsgsecure calls permit applications to obtaintheSIDsof local andpeersocketsandtheSIDsof mes-sages.The socket secure and listen secure calls permitapplications to specify a particular SID to usewhen anew socket is created.Thelisten securecall alsopermitsapplications to specify that server socketscreatedby aconnectionshouldbe labeledwith theSID of the clientsocket. Thesendtosecureandsendmsgsecurecallsper-mit applications to specifya particular SID to usefor amessage.

The connect secure, sendtosecure, andsendmsgsecure calls also permit applications tospecifyadesiredSID for thepeersocket. For connectionrequests and outbound datagrams, this restriction canonly be enforced by the destinationnode. However,a destinationnode may not be capableof enforcingthe restrictionor it may not be trustedto enforce therestriction. Consequently, the sourcenode performs anenforce destpermissioncheckbetweenthedesiredSIDandthe destinationnode SID. This checkis not neces-sary for AF UNIX sockets,sincethe communication islocal.

Whenusedwith streamsockets,connect secure spec-ifies thedesiredSID of thelisteningsocket. TheSID ofthe server socket createdby the connectionmay differfrom thisSID sincetheserverapplication mayhaveusedlisten secure. If a client wishesto ensurethat theserversocket hasa particularSID prior to sending data,thenitmayobtaintheSID usinggetpeernamesecure. Alterna-tively, a clientmayspecifythedesiredserversocketSIDwith sendtosecure. In this case,sincetheserver socketSID wasobtained by the client node during connectionestablishment,theclientnodemaycheckthedesiredSIDagainst it.

Sincesockets areaccessedthrough file descriptions,the fstat secure call mayalsobeusedto obtaintheSIDof a socket. The fchsidcall maybeusedto relabelUDPsockets,raw IP sockets,Unix datagramsocketsor Unixstreamsockets. Relabelingof TCP sockets is not sup-portedin thecurrent designbecausethereis no mecha-nism for synchronizing the change with the peertrans-port layer. The change might alsoneedto be synchro-nizedwith thepeerapplication,becausethepeerapplica-tionmayberelyingonthesocketSIDprovidedby theex-tendedsocket calls. No mechanismis providedfor such

49

8 NETWORKING 8.2 Implementation

getsockname secure(..., sidp)GettheaddressandSID of thelocal socket.

getpeername secure(..., sidp)GettheaddressandSID of thepeersocket.

accept secure(..., sidp)Accept a connection andreturn theSID of thepeersocket.

recvfrom secure(.. ., sso sidp,msg sidp)Receive a message,its sourceaddress,the SID of the sourcesocket, andtheSID of themessage.

recvmsg secure(... , sso sidp,ms g sidp)Sameasabove, except usingthe recvmsginterface.

socket secure(..., sid)Create a socket with a specifiedSID.

listen secure(..., sid, useclient)Set the state of a socket to accept connections andspecify theSID to usefor server sockets created by connections. If sid isnon-zero, theneach server socket created by a connection willbe labeled with the specified SID. If useclient is non-zero, theneach server socket created by a connection will be labeled withthe SID of its peer socket. It is an error to specifyboth sid anduseclient.

connect secure(... , sid)Specify theaddressandthedesiredSID of thepeersocket. If thesocket is of type SOCK DGRAM, thendatagramsmayonly besentto or received from a socket with the specified SID. If thesocket is of typeSOCK STREAM,then theconnection will failunlessthelisteningsocket hasthespecified SID.

sendto secure(..., dso sid, msg sid)Senda messageandspecify the desiredSID for the destinationsocket and/ortheSID of themessage.

sendmsg secure(... , dso sid, msg sid)Sameasabove, except usingthesendmsginterface.

Figure17: New Linux socket systemcalls for security-awareappli-cations.

STRUCT FIELDsock sclass

sidnewconn siduseclientpeersid

openrequest conn requestsidnewconn sid

sk buff ssosiddsosidmsgsid

device siddefault msg sid

Table31: Changes to network datastructuresfor labeling.

synchronizationwith thepeerapplication for eitherTCPsocketsor Unix streamsockets.

8.2 ImplementationIn this section,the implementationof theFlasksecu-

rity mechanismsin theLinux networking component isdescribed. This sectionbeginsby discussingthe imple-mentationof support for labelingnetwork objects.Then,theimplementationof thenew socketsystemcallsis de-scribed.Finally, themapping of thecontrolrequirementsto thecode is specified.

8.2.1 Labeling Thekernel datastructureswerestud-ied to identify the structuresusedinternally for sockets(structsock andstructsocket), openconnection requests(structopenrequest), messages(structsk buff ), andnet-work interfaces(structdevice). Sincethesestructuresareprivate to the kernel andhave no specificsize require-ments,they wereextended to include additional fields,asshown in Table31.

Thestruct sock structurewasextendedto includethesecurityclass(sclass) and the SID (sid) of the socket,the SID to usefor new socketscreatedby connectionsto the socket (newconn sid), a flag to indicate the useof the client SID for this purpose(useclient), and theSID of the peer socket (peer sid). The allocator forstructsock objects,sk alloc, initializesthesecurityclassfield to the general socket class, the SID field to theSID of the current process,and the peerSID field totheany socket initial SID. The inet createfunction setsthe securityclassfield to be one of TCP socket, UDP

50


socket, or raw IP socket basedon the specifiedsockettype. The unix create function setsthe securityclassfield to be eitherUnix streamsocket or Unix datagramsocket. The inet listen andunix listen functionsset thenewconn sid field to the SID of the socket by default.The udp connect andunix dgram connect functions re-setthepeersid field to theany socket initial SID if theassociationis broken.

Themore abstractstructsocket structure is embeddedin an inodestructure (struct inode), which hasa secu-rity classandSID field usedby the file controls. Theallocatorfor struct socket objects,sock alloc, initializesthesecurityclassandtheSID of theinode to thegeneralsocket classandtheSID of thecurrent process,respec-tively. The inet createandunix createfunctionssetthesecurityclassfield in the inodeto the samevalueasinthestructsock object.

The struct openrequest structure was extendedto include the SID of the connection request(connrequestsid) and the SID to use when thesocket for theconnectionis created(newconn sid). Thisstructuretemporarily storestheseSID valuesfor TCPuntil the new server socket is createdat the completionof theconnectionestablishment.

The struct sk buff structure wasextended to includetheSID of thesourcesocket(ssosid), thedesiredSID ofthedestinationsocket (dsosid) andtheSID of themes-sage(msgsid). Theallocatorfor struct sk buff objects,alloc skb, initializesthesourcesocket SID andthemes-sageSID to theunlabeledinitial SID,andit initializesthedestinationsocketSID to theany socket initial SID. Theskbclone, skbcopy, and skbrealloc headroom func-tionspreserve thevaluesof thesethreeSID fieldswhenmessagesare copied. The ip defrag and ip glue func-tions ensurethat all fragmentsof a messagehave thesamevaluesfor the threeSID fields and that the threeSID fieldsaresetcorrectlyfor thecompletemessage.

When a messageis allocatedfrom a socket’s sendbuffer, thesock wmallocfunction setsthesourcesocketSID andmessageSID to theSID of thesocket, andthedestinationsocket SID to the peer SID of the socket.Whenan unlabeledmessageis associatedwith a send-ing socket, the skbsetownerw inline function setsthethreeSID fields in thesamemanner. There aretwo spe-cial casesfor settingtheSID fieldsof anoutboundTCP

message.Whena SYN-ACK is createdfor anormalcon-nection, tcp make synack setsthesourcesocketSID andthemessageSID to thevalueof thenewconnsid field ofthe struct openrequestobject,so that the SYN-ACK islabeledwith theSID of theserver socket thatwill becre-atedby theconnectionratherthantheSIDof thelisteningsocket. WhenanACK is sentto completea connectionhandshake,thetcp sendack functionsetsthedestinationsocket SID to the any socket initial SID, sincethe lis-teningsocket may have a different SID thanthe serversocket.

The struct device structurewas extended to includethe SID of the network interface(sid) and the defaultmessageSID for the interface (default msgsid). Thedevinet ioctl function setsthe SID field andthe defaultmessageSID field of the network interfaceif it hasnotbeenpreviouslyset.TheseSID valuesareobtainedfromthesecurityserverbasedon thenameof thenetwork in-terface.Whenanunlabeledmessageis received onanet-work interface,the ip rcv functionsetsthesourcesocketSID andthemessageSID to thedefault messageSID ofthenetwork interface,andthedestination socket SID totheany socket initial SID.

When a TCP SYN is received on a listeningTCP socket, the tcp v4 conn requestfunction setstheconnrequestsid field of the newly allocated structopenrequestobjectto thesourcesocketSID of themes-sage. If the useclientflag is set for the socket, thenthe newconn sid field of the openrequestobjectis alsoset to this value. Otherwise,the newconnsid field ofthe openrequestobject is copiedfrom the correspond-ing field of the socket. If SYNcookies arebeingused,thenthe openrequestobject is discarded andrecreatedwhen the client’s ACK is received. In this case,theconnrequestsid field is setto theSID of theACK mes-sage.

When a TCP ACK is received for an existing structopenrequestobject,the tcp createopenreq child func-tion setsthepeerSID of thenewly allocatedstructsockobject to the connrequestsid field of the openrequestobject,andit setstheSID of thenew socket to thenew-connsid field of the openrequest object. The securityclassfor thenewly allocatedstructsock objectis copiedfrom the listening socket. When a connection is ac-cepted,the inet accept function copiesthe socket SID

51


andsecurityclassfrom thestructsock objectinto thein-odefor thestructsocket object.

Whena TCP SYN-ACK is received in theSYNSENTstate,thetcp rcv stateprocessfunction setsthepeerSIDof theclient socket to thesourcesocket SID of themes-sage. Whena SYN is received in the SYNSENTstate(asimultaneousopen), thetcp rcv stateprocessfunctionsetsthepeerSID of eachsocket to thesourcesocketSIDof themessage.

For Unix streamsockets, the equivalent processingfor connectionestablishment occursentirely within theunix streamconnect function. If theuseclientflag is seton the listeningsocket, thenthe SID of the newly allo-catedstruct sock object is set to the SID of the clientsocket. Otherwise,the SID of the new server socket iscopiedfromthenewconn sidfieldof thelisteningsocket.ThepeerSID of theclient socket is setto theSID of theserversocket,andthepeerSID of theserversocket is setto theSID of theclientsocket.

8.2.2 API extensions TheLinux socketcallsareim-plemented aslibrary functions that invoke a singlesys-tem call, socketcall, with a parameterthat indicatesthekind of call. Consequently, the extended socket callswereimplementedsimplyby definingnew call valuestothesocketcall systemcall. To permit theexisting fchsidcall to beusedonsockets,theinodesetattrfunction waschanged to call a new sock chsid function if a socket isbeingrelabeled.

Internally, the Linux network componentusesan ab-stractinterfaceto call thecodespecificto eachprotocolfamily. Extendedforms of theconnect, accept, getname,listen, sendmsgand recvmsgoperationswere addedtothestructproto opsstructureto support thecorrespond-ing extendedsocket calls. A chsid operationwasaddedto thestructproto opsstructureto support relabeling ofsockets. An extendedform of the createoperation wasaddedto the net proto family operations vector to sup-port thesocket secure call. Within eachprotocol family,an abstractinterfaceis usedto call the transport layerprotocol code.Extendedforms of theconnect, sendmsg,and recvmsgoperationswereaddedto the struct protostructureto support the corresponding extended socketcalls.

The initialization function for ICMP

(icmp.c: initfunc) was modified to use the extendedcreate operation to create the icmp socket with theicmp socket initial SID. Likewise, the initializationfunction for TCP(tcp ipv4.c: initfunc) wasmodifiedtocreatethetcp socket with thetcp socket initial SID.

The inet create and unix create functions werechanged to set the SID of the socket when a partic-ular SID is specified. The inet listen and unix listenfunctions were changed to set the newconn sid fieldor the useclientfield of the socket if the correspond-ing parameter was specified. The udp connect andunix dgram connect functions were changed to set thepeer SID of the socket. The unix dgram sendmsg,ip build xmit, and ip build xmit slow functions werechangedto setthedestinationsocketSID and/orthemes-sageSID of themessageif particularvalueswerespeci-fied. Thetcp v4 connect function waschangedto setthedestinationsocket SID for the connectionrequest mes-sageto thespecifiedpeerSID. The tcp v4 sendmsgandunix streamsendmsgfunctions were changed to com-parethespecifiedmessageSID and/ordestinationsocketSID with theactualvaluesdetermined duringconnectionestablishment.

The udp deliver, raw rcv skb, unix find other andunix dgram sendmsgfunctions were changed to com-parethe peerSID of the socket with the source socketSID of the messageand to compare the SID of thesocket with the destination socket SID of the message.The tcp v4 do rcv functionwaschangedto compare thesocket SID with the destination socket SID of the mes-sagewhenamessageis receivedona listeningsocket. Ifa mismatchoccursona raw IP socket, thenthepacket issilently dropped.If a mismatchoccurs on a UDP socketandthe packet wasto a unicastaddress, thenan ICMPport unreachablemessageis sentin reply. If a mismatchoccursonaUDPsocketandthepacketwassenttoamul-ticastor broadcastaddress,thenthe messageis silentlydropped.If amismatchoccursonalisteningTCPsocket,thenaTCPresetis sentin reply. If amismatchoccursona Unix domainsocket, a connectionrefusederror is re-turnedto theconnecting or sendingprocess.

8.2.3 Control Requirements To minimize theover-headof permissionchecks, two AVC entry referencefields(avcr andpeeravcr) wereaddedto thestructsock

52


structureandoneAVC entryreferencefield wasaddedtothestructdevicestructure.Thesk alloc function initial-izesthesefieldsfor new socketobjects.Thedevinet ioctlfunction initializes this field for devices whenthey arefirst accessed.

Sinceacceptfrom permission is initially checked byTCP when the openrequest object is created,an AVCentry reference field (avcr) was added to the structopenrequeststructure.This field is initialized whenanopenrequestobject is createdby the cookiev4 checkfunction or the tcp v4 connrequestfunction. The fieldis set in thesefunctions whenit is usedfor the accept-frompermissioncheck.

To permit the connectto andacceptfrom permissionsto be revalidatedwhentraffic is sentor received on anestablishedconnection, a connection permissionfield(connperm) was also addedto the struct sock struc-ture. When a new TCP server socket is created,thetcp createopenreq child function setsconnperm fieldto theacceptfrompermission,andit copiestheavcr fieldfrom the openrequest object into the peeravcr field.For client TCP sockets, the tcp rcv stateprocessfunc-tion setsthe conn perm field to the connectto permis-sion. The peeravcr field is set in this function whenit is usedfor theconnectto permissioncheck. For Unixstreamsockets, the connpermandpeeravcr fields aresetby unix streamconnect for boththeclientsocketandtheserversocket.

Thecontrol requirementsimplemented in eachkernelfunction for TCPcommunicationareshown in Table32.Only the classandpermissionareshown for eachcon-trol requirement;the sourceSID andtarget SID canbefound in the corresponding designtable. If connecttopermissionis deniedduring connectionestablishment,aconnectionrefusederror is returnedto the local processandthe socket is shutdown. If acceptfrom or newconnpermissionis deniedduring connection establishment,a TCP resetis sent in reply to the connection request.The permissionstoredin the connperm field is reval-idated by the tcp do sendmsgand tcp rcv establishedfunctions. If permission is no longer granted whentcp rcv establishedreceivesa messageon a connectionor whentcp do sendmsgattemptsto senda messageona connection, thena connection reseterroris returnedtothelocalprocessandthesocket is shutdown. If tcp send

CONTROL REQUIREMENT(S)FUNCTION(S) CLASS PERMinet listen socket listen

socket newconninet stream connect socket connectinet accept socket acceptinet sendmsg socket writeinet recvmsg socket readtcp v4 conn request socket newconncookie v4 check socket acceptfromtcp rcv stateprocess socket connecttotcp do sendmsg socket connectto

socket acceptfromtcp rcv established socket connectto

socket acceptfromip queue xmit, netif tcp sendip build andsendpkt, node tcp sendip forward,ipmr queuexmitip recv netif tcp recv

node tcp recv

Table32: Implementing thecontrol requirementsfor TCPcommu-nication.

CONTROL REQUIREMENT(S)FUNCTION(S) CLASS PERMunix listen socket listen

socket newconnunix accept socket acceptunix streamrecvmsg socket readscm detach fds fd receiveunix streamconnect socket connect

socket connecttosocket newconnsocket acceptfrom

unix streamsendmsg socket writesocket connecttosocket acceptfrom

Table33: Implementing the control requirementsfor Unix streamcommunication.

53


CONTROL REQUIREMENT(S)FUNCTION(S) CLASS PERMinet dgramconnect socket connectinet sendmsg socket writeinet recvmsg socket readudp sendmsg, socket sendtoraw sendmsg socket sendmsgudp deliver, socket recvfromraw rcv skb socket recv msgip build xmit, netif udp/rawip sendip build xmit slow, node udp/rawip sendip forwardip rcv netif udp/rawip recv

node udp/rawip recv

Table34: Implementing the control requirementsfor UDP or rawIP communication.

CONTROL REQUIREMENT(S)FUNCTION(S) CLASS PERMunix dgramconnect socket connectunix dgramrecvmsg socket readscm detach fds fd receiveunix dgramsendmsg socket write

socket sendtosocket sendmsgsocket recvfromsocket recv msg

Table35: Implementing thecontrol requirementsfor Unix datagramcommunication.

CONTROL REQUIREMENT(S)FUNCTION(S) CLASS PERMinet create, socket createunix createinet bind, socket bindunix bind socket namebindinet getname, socket getattrunix getnamesock getsockopt socket getoptinet getsockoptsock setsockopt socket setoptinet setsockoptinet shutdown, socket shutdownunix shutdown

Table 36: Implementing the control requirementsfor the othersocket calls.

CONTROL REQUIREMENT(S)FUNCTION(S) CLASS PERMunix ioctl socket getattrdevinet ioctl netif getattr

netif setattrip rt ioctl system route controlarp ioctl system arp controlrarp ioctl system rarp controlinet ioctl system net io control

Table 37: Implementing the control requirementsfor ioctl com-mands.

or tcp recvpermissionis denied, thenanICMP port un-reachable messageis sentif themessagewaslocallygen-eratedoranICMPhostunreachablemessageissentif themessageis beingforwarded.

Table33showsthecontrol requirementsimplementedin eachkernel function for Unix streamcommunication.If newconn, acceptfrom, or connecttopermissionis de-niedduring connectionestablishment, thena connectionrefusederror is returned to the connecting process. Ifacceptfromor connecttopermissionis no longer grantedwhendatais sentontheconnection, thenaconnection re-seterror is returnedto thesending processandthesocketis shutdown. If receivepermissionis not grantedfor anopenfile description, thenthedescriptorsandany subse-quent descriptors in themessagearediscarded.

Table34showsthecontrol requirementsimplementedin eachkernelfunction for UDP or raw IP communica-tion. If recvfromor recvmsgpermissionis deniedwhena UDP unicastmessageis received, thenan ICMP portunreachablemesssageis sentin reply. If eitherof thesepermissions are deniedfor a UDP multicastor broad-castmessageor a raw IP message,thenthe messageissilently dropped. If udp sendor rawip sendpermissionis denied,thena permissiondenied error is returnedtothelocalprocessif themessagewaslocally generatedoranICMP hostunreachablemessageis sentif themessageis beingforwarded.If udp recvor rawip recvpermissionis deniedfor a unicastmessage,thenan ICMP port un-reachable messageis sent.

Table35showsthecontrol requirementsimplementedin eachkernelfunction for Unix datagramcommunica-tion. If recvfromor recvmsgpermissionis deniedwhena messageis sent,thena connectionrefusederror is re-

54

9 SYSTEMV IPC 9.1 Design

OBJECTCLASSsemaphoresetmessagequeuemessagesharedmemory

Table38: Objectclassesfor theLinux SystemV IPC component.

turnedto the sendingprocess. If receivepermission isnotgrantedfor anopenfile description, thenthedescrip-tors andany subsequent descriptors in the messagearediscarded.

The implementation of the control requirements fortheother socketcallsis shown in Table36. Theinet bindfunction only checks namebind permission if the portnumberis outsideof therangeusedto automaticallybindsockets. Theunix bind function only checksnamebindpermissionif the nameis in the file systemnamespace.Table 37 shows the implementation of the control re-quirementsfor theioctl commands.

9 SystemV IPC

This sectiondescribes thedesignandimplementationof the Flask securitymechanisms for Linux SystemVInter-ProcessCommunication.


Flasksecuritymechanismsinto theLinux SystemV IPCcomponent. It begins with a discussionof the objectclassesandpermissionsdefinedfor thecomponent.Thisis followedby a description of thecontrol requirementsfor thesystemcallsusedto manageandperform IPCop-erations. Finally, the new IPC-relatedsystemcalls de-finedfor security-awareapplicationsaredescribed.

9.1.1 Object Classes Thesetof objectclassesfor theSystemV IPC componentis shown in Table38. A classis defined for eachSystemV IPC abstraction.Addition-ally, a classis definedfor individual messageswithin amessagequeue,sothatmessagescanbeindividually la-beledandcontrolled. By default, the SID of a SystemV IPC objectwill besetto theSID of thecreatingpro-cess.For SystemV messagequeues,anadditional SID

PERMISSION(S) DESCRIPTIONassociate Associate a key with a semaphoresetread Readwrite Writecreate Createdestroy Destroygetattr Getattributessetattr Setattributes

Table39: Permissionsfor thesemaphoreobjectclass.

PERMISSION(S) DESCRIPTIONassociate Associate a key with a queueread Readwrite Writecreate Createdestroy Destroygetattr Getattributessetattr Setattributesenqueue Messagemayresideon queue

Table40: Permissionsfor themessagequeueobject class.

attributewill bebound to eachmessage.ThatSID is setby default to theSID of themessagesendingprocess.

9.1.2 Permissions Thepermissionsdefinedfor con-trolling accessto eachSystemV IPC object classareshown in Table39,Table40,Table41,andTable42.

Thesemget, msgget, andshmgetsystemcallsandtheirassociatedsecurevariantseachrequireassociateaccessto associateakey with anID whenaccessinganexistingobjectby key. If anobjectis beingcreatedandthepro-cesshascreatepermission, it is assumedthatit implicitlyhastheability to associateakey with thecreatedIPCob-ject andassociatepermissionis not required. Sincethekey canalsobe obtainedvia semctl, msgctl, andshmctlcallswith theSEM STAT, MSG STAT, SHM STAT, andIPC STAT optionsthesealso require associatepermis-sion.

The semctl(IPC INFO), semctl(SEM INFO),msgctl(IPC INFO), msgctl(MSG INFO), shm-ctl(IPC INFO) and shmctl(SHM INFO) system callsreturn information to the calling processthat is com-binedfrom all objectsof the given type without regardto the object SID. The designtherefore restrictsuseofthesecalls to processeswith a new systempermission

55

9 SYSTEMV IPC 9.1 Design

PERMISSION(S) DESCRIPTIONsend Add a messageto a queuereceive Remove a messagefrom a queue

Table41: Permissionsfor themessageobject class.

PERMISSION(S) DESCRIPTIONassociate Associate a key with a segmentread Readwrite Writecreate Createdestroy Destroygetattr Getattributessetattr Setattributeslock (Un)lock page(s) in memory

Table42: Permissionsfor theshared memoryobject class.

(ipc info.) This accessis now necessaryfor correctfunctioning of the ipcs program. It may be desirablein the future to modify the ipcs programto selectivelyreturninformationbasedontheexecutingSID.

9.1.3 Control Requirements The control require-mentsfor the SystemV IPC systemcalls areshown inTable43,Table44,andTable45. For themostparttheseareobviousextensions of thestandard Linux permissionbits.

Unlike for the file systemopencall, semget, msgget,shmget and their secure variants can not validate therequestedreador write permissions sincethesesystemcallsmayalsobeusedto obtainanid for usein thesem-ctl, msgctl, andshmctlcalls which may require neitherreadnorwrite permissionto besuccessful.Thereadandwrite permissionsarecheckedwhenmaking systemcallswhichperformtheactualdataoperations.

Themessagequeueobjectemploys thereadandwritepermissionto determine if a specificprocessmayutilizea specificqueuefor receiving or sending messages,re-spectively. In contrastthemessage objectemploys sendandreceivepermissionsto determine if a givenprocessis allowed to receive or senda given message.The en-queuepermissionis usedto determineif agivenmessageis permittedto “passthrough” thegivenqueue.

CONTROL REQUIREMENT(S)CALL(S) CLASS PERM SSID TSIDsemget, sem create current semsemgetsecure sem associate current semsemsid sem getattr current semsemop(semop==0) sem read current semsemop(semop!=0) sem write current semsemctl.SEMSTAT, sem getattr current semIPC STAT sem associate current semsemctl.IPCGETNCNT, sem getattr current semIPC GETPID,IPC GETZCNTsemctl.IPCSET sem setattr current semsemctl.IPCRMID sem destroy current semsemctl.IPCGETALL , sem read current semIPC GETVALsemctl.IPCSETALL , sem write current semIPC SETVALsemctl.SEMINFO, system ipc info current kernelIPC INFO

Table43: Control requirementsfor manipulatingsemaphores.

CONTROL REQUIREMENT(S)CALL(S) CLASS PERM SSID TSIDmsgget, msgq create current msgqmsggetsecure msgq associate current msgqmsgsid msgq getattr current msgqmsgsnd, msgq write current msgqmsgsndsecure msg send current msg

msgq enqueue msg msgqmsgrcv, msgq read current msgqmsgrcvsecure msg receive current msgmsgctl.MSGSTAT, msgq getattr current msgqIPC STAT msgq associate current msgqmsgctl.IPCSET msgq setattr current msgqmsgctl.IPCRMID msgq destroy current msgqmsgctl.MSGINFO, system ipc info current kernelIPC INFO

Table44: Control requirementsfor manipulating messagequeues.

56

9 SYSTEMV IPC 9.2 Implementation

CONTROL REQUIREMENT(S)CALL(S) CLASS PERM SSID TSIDshmget, shm create current shmshmgetsecure shm associate current shmshmsid shm getattr current shmshmat(SHM RDONLY) shm read current shmshmat(!SHM RDONLY) shm read current shm

shm write current shmshmctl.SHMSTAT, shm getattr current shmIPC STAT shm associate current shmshmctl.IPCSET shm setattr current shmshmctl.IPCRMID shm destroy current shmshmctl.SHMLOCK, shm lock current shmSHM UNLOCKshmctl.SHMINFO, system ipc info current kernelIPC INFO

Table45: Control requirementsfor manipulatingsharedmemory.

9.1.4 API extensions New calls wereadded to per-mit a processto createa SystemV IPC object with aspecifiedSID andto permita processto obtaintheSIDof anexisting object.New callswerealsoaddedto per-mit a sendingprocessto specifya particularSID for amessageandto permita receiving processto obtaintheSID of thereceivedmessage.

The semsid, msgsid, and shmsidsystemcalls wereaddedto retrieve the securityID for a given semaphoreset, message queue, or shared memory segment re-spectively. The semget secure, msgget secure, andshmget securesystemcallswereadded to providea wayto requestanIPC objectwith a specificsecurityID.

The msgsndsecure and msgrcv secure systemcallswereaddedto enablesendingandreceiving a messagewith aspecificSID to or from amessagequeue. Thems-grcv secure call takesa SID reference parameterwhichis eithera specificSID to usein selectinga message,ora null or wildcardSID to allow the return of a messageat any SID to which accessis permitted. The call alsoreturns theSID of thereturnedmessageusingthis refer-ence.

9.2 Implementation

This sectiondescribesour implementationfor inte-grating the Flask security mechanisms into the LinuxSystemV IPC component.

9.2.1 Labeling New structures (semidkernel andmsqidkernel) were added to parallel (and contain)semidds and msqidds respectively. This permits thekernel to maintainSIDs in the datastructureswithoutaltering the public versions of eachstructureand thethereby the existing API. A number of small changesweremadein sem.h, msg.h, sem.candmsg.c to accom-modate the new structures. Thesearesimilar to theex-isting shmidkernel structurewhich is usedto maintainkernelmappingsfor memory segments.Theadditionoflabel datato eachof thesethreestructuresis controlledby conditionalcompile directives,however, thenew ker-nelstructures themselveswereaddedto thebasecodeasweretherelatedstructurereferences.

9.2.2 API Extensions In reality no new systemcallswere added, although eight new APIs were added tothe systemcall interface. The new APIs utilize thepreviously existing sysipc systemcall demultiplexer insysi386.c to dispatchthe new IPC relatedcalls. Cur-rently only the Intel 32-bit architecture hasbeenmodi-fied.

Thesemget secure, msgget secure, andshmgetsecurecallsallow a callerto requestanIPC objectwith a givenkey andagivenSID. If thecallerhascreateaccessbut thekey is alreadyallocatedto anIPC object with a differentSID, thecalleris returnedEACCES.

The msgrcv and msgrcv secure calls skip messagesthatarelabeledwith a SID for which thecallingprocessdoesnothavereceiveaccessratherthanreturnEACCES.This may result in accesschecksbeingperformedanddenialof accessbeingauditedfor messageswhoseex-istenceis not evenapparentto thecalling processwhena) the msgrcv call is used,or the msgrcv secure call isusedwith a SID of SECSIDWILD or SECSIDNULL,andb) messagesexist on the queuefor which the pro-cessdoesnot have receivepermission,andc) accesshasbeenrevoked from the processfor the queue or frommessagesto which it hadaccesswhenit calledmsgrcvor msgrcv secure. In that(unusual)case,thecallingpro-cesswill alsowait indefinitelyfor a message.

A beneficial implication of the interactions betweenthe read, write, receive, send, andenqueuepermissionsandindependentSIDs for message queuesandindivid-ual messages is that policies may be developedwhich

57

10 SYSTEMCALL REVIEW

allow restrictedmulti-level messagequeues.Thesemaybe desiredto createa convenient one-way communica-tion mechanismfor processes.Policy writers,of course,needto carefully considerthetheimplicationsof suchaone-way channel if it is desiredandimplemented.

9.2.3 Control Requirements The semctl, ms-gctl and shmctl system calls with the IPC RMIDor IPC SET options each allowed a process withCAP SYS ADMIN to bypassthestandardLinux ownerchecks.TheFlaskchecks,however, arenot bypassedbyCAP SYS ADMIN, andasdescribedin Section5.2,theuseof CAP SYS ADMIN even to bypassthe standardownerchecksis subjectto additional Flaskchecks.

Eachcontrol point that hasthe potential to generatean audit record addsthe ID of the semaphore set,mes-sagequeue, or sharedmemory region to the audit dataincluded in therecord.

The shmat(!SHM RDONLY) control point is imple-mentedas a check for read and write since the logi-cal semanticsaswell asthex86 implementationof not-readonly arereadandwrite.

Sinceshmatalso writes the accessgranted into thememory segmentstructuresfor hardwareuseoneachac-cess,acall-back will eventually benecessarytoallow theaccesscontrol embodied in thememory structuresto berevalidatedor revokedonapolicy change.

Thecasestatementconditions in thesyssemctlfunc-tion wereslightly reorderedto collect somereadbasedaccesschecksandgetattr accesschecksthat werebothcovered by the standardLinux readpermissionbit. Aseeminglyredundantcheckwas found for the ”ID Re-moved” (EIDRM) condition betweenswitch statementsin thatfunction thatwasalready coveredby thecheckatthebeginning of syssemctl. Thefirst casein theswitchfollowing the EIDRM checkis a permissioncheckforGETALL thatalsoseemsto beredundantwith thecheckpreviously performed in the casesabove. No controlpoint wasaddedfor thesecondpermissioncheckastheprevious permissioncheckshould still be valid. (Thereare no processsleepsin the GETALL code path be-tweenthesepoints.) No otherchangesweremadeto im-prove theflow of thecasestatements,asthis wasseenascounter-productive given thereorganization in laterker-nelversions.

The semexit function performs a checkwhen free-ing undostructuresthatthesemaphore values donotbe-comenegative. A printk wasaddedafter that checktoallow detectfailureof thatassumption. Sincetheprintkshouldnever be executed unlessthereis a kernelbug,thereshouldbeno impactfrom thischange.

10 SystemCall Review

This sectioncontains the resultsof a review of theLinux/i386 systemcall interfaceto determine what ad-ditional Flaskcontrolsareneeded. The following sub-sectionsdescribetheresultsfor eachcategory of systemcalls.As controlsrecommendedin thisreview areimple-mented, thecorrespondingdiscussionshouldberemovedfrom this sectionandintegratedinto anappropriatesec-tion of thedocument.

10.1 Process Management

Thissubsectiondescribestheresultsof thesystemcallreview for callsrelatedto processmanagement.

10.1.1 Scheduling Flask provides controls over theability to observe or modify the scheduling characteris-ticsof otherprocessesandtheability to increasepriority.However, Flaskdoesnot yet provide a scheduling pol-icy. Support for a new scheduling policy basedon thesecuritycontexts of processeswould bedesirable. Suchsupport will likely requirea new interfaceto thesecurityserver.

10.1.2 Sessionsand ProcessGroups The ability toobserveorsetthesessionandprocessgroupidentifiersofotherprocessesiscontrolledbyFlask,but thesessionandprocessgroup abstractions arenot labeledor controlled.TheFlaskmechanismscould beusedto provide a labelfor eachsessionandprocessgroup, to control whatpro-cessesmaybein eachprocessgroup, andto control whatterminalmay serve asthe controlling terminal for eachprocessgroup. However, it is notclearthatsuchlabelingandcontrols areneeded,sincesignaldelivery andtermi-nal accessarecontrolled through theexisting Flasksig-nal andfile controls. Furtherstudyof theuseof sessionandprocessgroups is needed.

58

10 SYSTEMCALL REVIEW 10.1 ProcessManagement

10.1.3 Userand Group Identity Thesetuid, seteuid, setreuid , setresuid, andsetfsuidcallsmaybeusedtosettheuseridentityattributesof thecallingprocess.Thesetgid, setegid , setregid , setresgid, setfsgid, andset-groupscalls may be usedto set the group identity at-tributesof the calling process. Linux permits unprivi-legedprocessesto perform certainkinds of changes totheir identity attributes,suchas changing the effectiveidentity to the real identity or vice versa,or changingtheeffective identity to thesavedidentity. Linux permitsmoregeneral changesin identity for processesthathavetheCAP SETUIDandCAP SETGIDcapabilities.

Thesecalls only affect theprivatestateof thecallingprocess. Furthermore, the Flaskcontrols arenot basedon theLinux identity attributes. Consequently, changesin Linux identityattributesareirrelevantto theFlaskse-curity policy anddonotneedto becontrolledby thepol-icy. However, it maybe valuable to provide Flaskcon-trolsonthesecallsto allow thepolicy to confinechangesin Linux identity. The Flaskcap setuidandcap setgidpermissions arechecked whenthe corresponding capa-bilities are required by Linux. If it is desirable for thepolicy to beableto confine Linux identitychanges,thennew Flaskpermissionsneedto bedefinedto control allusesof thesesystemcalls.

10.1.4 Capabilities The ability to get or set the ca-pability setsof another processis controlled by Flask.Flask controls the useof capabilities by requiring thata processalsohave a corresponding capabilitypermis-sion. Hence,possessionof a capability is necessarybutnot sufficient to have the corresponding privilege whenFlaskis enabled. SinceFlaskdirectlycontrols theuseofcapabilities,it is not necessaryto controlthesettingandinheritanceof capabilitysetsotherthanensuringthattheability of a processto observe or change the capabilitysetsof anotherprocessis controlled.

Flaskcouldbeextendedto provide a finer-grainedre-placement mechanismfor capabilities. Sucha mecha-nismwasdevelopedfor oneof Flask’s predecessors,theDTOS system.This mechanismpermittedprivilegestobegrantedbasedonboththeattributesof theprocessandthe attributesof the relevant object, e.g. discretionaryreadoverridecouldbegrantedto a particular setof files.Sincethe mechanism obtainedprivilege decisionsfrom

theFlasksecurityserver, managementof privilegeswascentralizedandverification thatprivilegesweregrantedappropriatelywasstraightforward.

10.1.5 Timers Thealarm andsetitimercallsmaybeusedto arrangefor a signalto besentto thecalling pro-cessafteraninterval. Thegetitimercall obtainsthevalueof an interval timer. The calls are implementedin ker-nel/sched.c and kernel/itimer.c. Currently, no controlsareperformed. A processcould arrange for a signal tobedelivered andperformanexecveor execvesecure be-fore the signal is generated,thus effectively deliveringa signal to itself after a SID change. This signal is notsubjectto any accesschecking,soadditionalcontrolsarenecessarywhenthe execveis performed. Timerscouldbe clearedupon an execvethat changesSID if the call-ing processlackstheappropriatesignalpermissionto thetransformedprocess.

10.1.6 Resource Limits and Usage The setrlimitcall may be used to change the resource limits forthe calling process. The call is implementedin ker-nel/sys.c. Linux requirestheCAP SYSRESOURCEca-pability to usethe setrlimit call to increasethe soft orhardlimit abovethecurrent hardlimits, soFlaskrequirescap sysresourceunder thesameconditions. Flaskdoesnot provide a processresourcelimit policy. Support fordefiningresource limits basedonthesecuritycontextsofprocesseswould bedesirable. For now, Flaskonly con-trols the ability to increasethe limit above the currenthardlimit.

The getrusage call may be usedto get resourceus-ageinformationfor thecalling processandits children.Similarly, the timescall maybeusedto obtainthe timeusageof thecallingprocessandits children.Linux doesnot control theuseof thesecalls. Sincetheusagestatis-tics of a child processareonly addedinto the parent’scombinedstatisticsfor its childrenif theparentreaps thechild, theexisting Flaskwait controls aresufficient. Noothercontrols seemnecessary.

10.1.7 Other ProcessCalls The prctl call is a gen-eral interfacefor performing operationson a process.Itonly supports a single operation that setsor clearsthesignalthat thecalling processwill receive whenits par-ent dies. The existing Flaskcontrolsfor signalsensure

59

10 SYSTEMCALL REVIEW 10.3 File System

that thedelivery of thesignalis controlled. However, itwould beusefulto checktheappropriatesignalpermis-sionwhenthiscall is usedsothatthecallingprocesswillbeawareof any permissionfailure.

The rt sigqueueinfo call is a variant of kill for real-time signals.This call is already controlled through theexistingFlasksignalpermissions.

Thegetpidandgetppidcallsmaybeusedto obtaintheprocessidentifierof thecallingprocessandits parent,re-spectively. Thegetpidcall doesnot requireany controls,sinceit only revealsprivatestateof thecalling process.The getppidcall would only needto be controlled if itwould be useful to conceal the PID of the parent, butsucha needis notevident.

10.2 Memory Management

Thissubsectiondescribestheresultsof thesystemcallreview for callsrelatedto memory management.

The mprotect call may be usedto set the protectionon a region of memory. The call is implemented inmm/mprotect.c. Linux requiresthatthenew protectionbeasubsetof themaximumprotectiononthemapping. Foranonymous memory or aprivatecopy-on-writemappingof a file, the maximum protectionallows all accesses.For a sharedmapping, the maximum protection alwaysallows readandexecuteaccessbut only allows write ac-cessif thefile is openfor writing.

Flaskensuresthatmprotectcannot beusedto increasethe current protection on memory-mappedfiles beyondwhat the securitypolicy authorizes. Flask shouldalsocontrol theability toexecuteanonymousmemory. A newpermissioncould be introducedbasedon the SID of aprocess that controls whetherthe process is allowed toexecute anonymous memory.

The mlock andmunlock calls maybe usedto disableandreenable paging for a rangeof memory. Themlock-all andmunlockall callsmaybeusedto disableandreen-ablepagingfor all pages mappedinto theaddressspaceof the calling process.Thesecalls are implemented inmm/mlock.c. Linux requiresCAP IPC LOCK to disablepaging, so Flask requirescap ipc lock permission. Noadditional controls seemnecessary.

10.3 File SystemThissubsectiondescribestheresultsof thesystemcall

review for callsrelatedto thefile system.

The nfsservctlcall is the interfaceto the kernelNFSdaemon. The call is implemented in fs/nfsd/nfsctl.c.Linux requires CAP SYSADMIN to use the call, soFlask requirescap sysadmin permission. Since theFlaskcontrolshavenotyetbeenintegratedinto theLinuxNFSimplementation,no further controls arerequired atthis time. Separatepermissionsfor theindividual opera-tionsmaybeintroducedat a latertime.

Thequotactl call maybeusedto manipulatediskquo-tas. This call is implemented in fs/dquot.c. Linux re-quiresCAP SYSRESOURCEfor enablingor disablingquotas, getting the quota of another useror group, orsettinga quota. Hence,Flaskrequires cap sysresourcepermissionfor thesecommands. When enabling quo-tas,a quotafile is specified.This file mustalreadyexist,typically beingcreatedby thequotacheck program. Thefile is openedfor readandwrite access,andtheexistingFlaskfile accesscontrols areapplied.It might beusefulto adda new permissioncontrolling what files may beusedasquotafiles. Linux doesnot control thequotactlcommandsfor syncingthe quota files, obtainingquota-relatedstatistics,orobtaining thequotalimits andcurrentusagefor useror groupof thecallingprocess.Flaskdoesnotprovideadiskquotapolicy. Support for definingdiskquotasbasedonthesecuritycontextsof processeswouldbedesirable.

The bdflush call may be usedto start, flush or tunethe buffer-dirty flush daemon. The call is implementedin fs/buffer.c. Linux requires the CAP SYSADMIN ca-pability, soFlaskrequirescap sysadminpermission.Itmight be useful to addnew permissionsto control theindividualoperationsprovidedby thecall.

The swaponandswapoff calls may be usedto startand stop swappingto a file or device. Linux requiresCAP SYSADMIN andsearchaccessto thefile to useei-ther call. Flaskrequires cap sysadminpermissionandsearch permission. It might beusefulto adda new per-missioncontrolling whatfiles maybeusedasswapfiles.

The chroot systemcall may be usedto changetheroot directory. The call is implementedin fs/open.c.Linux requires searchaccessto the new root directoryandCAP SYSCHROOT. Flask requires search permis-

60

10 SYSTEMCALL REVIEW 10.5 SystemOperations

sion to the new root directory and cap syschroot per-mission.No further controls seemto benecessary.

10.4 Kernel Modules

Thissubsectiondescribestheresultsof thesystemcallreview for callsrelatedto kernelmodules.

Thecreatemodulecall maybeusedto registeranameandto reservekernel memory for aloadablemodule. Theinit module call may be usedto load a relocatedmod-ule imageinto kernelmemoryandto run the module’sinitialization function. The deletemodulecall may beusedto removemodules.Thesecallsareimplementedinkernel/module.c. Linux requiresCAP SYSMODULE touseany of thesethreecalls,andFlaskrequiresthe cor-responding cap sysmodulepermission. No additionalcontrols seemto benecessaryfor thesecalls.

The querymodule call may be usedto obtain infor-mationrelatedto loadable modules.Theget kernel symscall maybeusedto obtainthekernel andmodulessym-bols.Thiscall is obsoletedby querymodule. Linux doesnot control the useof thesetwo calls. Flask controlsshouldbedefinedfor thesecallsto control theiruse.

The kernel module loader(kernel/kmod.c) runsmod-probe to automatically load moduleswhenthey arere-quested.Thekernelmodule loader runsasthesuperuserwith all capabilitiesenabled. Thekernelmodule loaderwaschangedfor Flaskto run with thekmodinitial SID.Otherwise,theFlaskcontrolswouldbebasedontheSIDof theuserprocess.

Although the Flask controls for module-relatedcallsarestraightforward,protectionof the kernel module fa-cility requiresconfigurationof thesecuritypolicy to labelandcontrol accessto themodule objectfiles, themoduleutilities, the module configuration files, and the kernelpathfor modprobe. Thepolicy configuration for kernelmodulesis describedin [7].

10.5 SystemOperations

Thissubsectiondescribestheresultsof thesystemcallreview for callsrelatedto theoverall system.

Thestimeandsettimeofdaysystemcallsmaybeusedto set the systemtime anddate. Both calls are imple-mentedin kernel/time.c. Linux requiresCAP SYSTIMEto use thesecalls, so a processmust have the Flask

cap systime permission to usethesecalls. No furthercontrols seemto benecessary. Theadjtimex call maybeusedto reador modify theclock adjustment parameters.Thiscall is implementedin kernel/time.c. Linux requiresCAP SYSTIME to usethis call to modify the parame-ters,soFlaskrequirescap systime. No furthercontrolsseemnecessary.

The sethostname and setdomainname calls may beused to set the host and domain namesfor the sys-tem.Linux requiresCAP SYSADMIN to useeithercall.Flaskrequires cap sysadminpermission. No other con-trolsseemnecessary.

The acct call may be used to enable or disableprocess accounting. The call is implemented in ker-nel/acct.c. Linux requires the calling processto haveCAP SYSPACCT to usethe call. If the call is usedtosettheaccountingfile, thenthecallingprocessmustalsobe ableto openthe accounting file with append access.TheFlaskcap syspacct permissionis checkedwhenthecall is used,andtheFlaskfile mandatory accesscontrolsarechecked if an accounting file is specified. It mightbeusefulto adda new permissioncontrolling whatfilesmaybeusedfor accounting.

The reboot call may be usedto reboot the systemorto enable or disablethereboot keystroke. Thecall is im-plementedin kernel/sys.c. Linux requiresthatthecallingprocesshaveCAP SYSBOOT, soFlaskrequiresthatthecalling processhave cap sysbootpermission. No othercontrols seemnecessary.

The ioperm call may be used to set I/O port ac-cesspermissionbits for the calling process for a spec-ified port and range. The call may only be usedforthe first 0x3ff I/O ports. This call is implemented inarch/i386/kernel/ioport.c. If thepermissionbits arebe-ing setto anything non-zero,thenLinux requiresthatthecalling processhave CAP SYSRAWIO. Thus,Flaskre-quiresthecorrespondingcap sysrawiopermission.Portaccesspermissions arenot inheritedon fork but they areinheritedacrossexecve. New Flaskcontrolsshould bedefinedto control inheritanceof port accesspermissions.It mayalsobedesirableto support individual labelingofdifferent I/O ports and to adda permission controllingaccessto particularports.

The iopl call maybeusedto change theI/O privilegelevel of the calling process. The call is necessaryfor

61

REFERENCES REFERENCES

moreportsthan0x3ff. For example, thecall is usedby8514-compatibleX serversto rununderLinux. Thiscallis implementedin arch/i386/kernel/ioport.c. If theprivi-legelevel is beingincreased, thenLinux requiresthatthecalling processhave CAP SYSRAWIO. Thus,Flaskre-quiresthecorrespondingcap sysrawiopermission. Theprivilege level is inherited on fork and acrossexecve.New Flaskcontrols shouldbe definedto control inher-itanceof I/O privilege levels. It mayalsobedesirabletoaddseparatepermissionsfor thedifferentlevels.

The syslog call may be used to read or clear thekernel messagering buffer and to set the consoleloglevel. Linux requires that the calling processhaveCAP SYSADMIN to useany syslogoperation exceptfortheoperation to readthe last4k of messagesin theringbuffer. Hence,Flaskrequirescap sysadminpermissionfor all of the otheroperations. SeparateFlask permis-sionsshouldbedefinedfor thedifferentkinds of syslogoperations,e.g. separatepermissionsto control readingandclearingthelast4k of messagesversuschanging theconsolelog level. Additionally, it seemsdesirabletocon-trol the ability of processesto readthe last 4k of mes-sages,soa Flaskpermissionshouldbeaddedto controlthis operation.

Thesysinfocall maybeusedto obtaininformationonoverall systemstatisticssuchasthe loadaverage,avail-ablememory, andnumber of current processes.Linuxdoesnot control theability to usethis call. A Flaskper-missionshouldbedefinedto control theuseof this call.

11 To Do

This sectionlists tasksthat have not yet beencom-pletedfor integratingtheFlasksecuritymechanismsintotheLinux kernel.

� Add controls identifiedby systemcall review

� Performfunctionalandperformancetesting

� Add mandatorycontrols for SystemV IPC

� IntegrateIPSECwith network mandatorycontrols

� Add mandatorycontrols for NFS

� Add support for polyinstantiateddirectories

� Add support for polyinstantiatedports

� Add notificationsfor completedoperations

� Add policy change callbacks

� Integratefile cryptography with file mandatorycon-trols

� Replace SIDs with SID descriptors (reference-countedSIDs)

References[1] W. E. Boebert andR. Y. Kain. A Practical Alternative to Hierar-

chical Integrity Policies. In Proceedings of the Eighth NationalComputer Security Conference, 1985.

[2] T. FineandS.E. Minear. AssuringDistributedTrustedMach. InProceedings IEEE Computer Society Symposiumon Research inSecurity andPrivacy, pages206–218,May 1993.

[3] Institute of Electrical and Electronics Engineers, Inc. Informa-tion Technology — Portable Operating System Interface (POSIX)— Part 1: System Application Program Interface (API) [C Lan-guage] , 1996.Std1003.1,1996Edition.

[4] P. A. Loscocco,S. D. Smalley, P. A. Muckelbauer, R. C. Taylor,S. J. Turner, and J. F. Farrell. The Inevitability of Failure: TheFlawed Assumptionof Security in Modern Computing Environ-ments. In Proceedings of the 21stNational Information SystemsSecurity Conference, pages303–314,Oct.1998.

[5] S.E. Minear. Providing Policy Control Over ObjectOperationsina MachBasedSystem.In Proceedingsof theFifth USENIXUNIXSecurity Symposium, pages141–156,June1995.

[6] O. S. Saydjari, J. M. Beckman, andJ. R. Leaman. LOCK Trek:Navigating Uncharted Space. In Proceedingsof the 1989 IEEESymposiumon Security andPrivacy, pages167–175, 1989.

[7] S.Smalley andT. Fraser. A Security Policy Configuration for theSecurity-EnhancedLinux. Technical report,NAI Labs,Oct.2000.

[8] R. Spencer, S.Smalley, P. Loscocco,M. Hibler, D. Andersen, andJ. Lepreau. TheFlaskSecurity Architecture: SystemSupportforDiverseSecurity Policies. In Proceedingsof the Eighth USENIXSecurity Symposium, pages123–139,Aug. 1999.

62

Documents

Integrating Flexible Support for Security Policies into the Linux Operating System · 2018. 9. 11. · the design and implementation for integrating the secu-rity mechanisms of the