A PrivilegeMechanism for UNIX System V Release4 OperatingSystems CharlesSalemi, Suryakanta Shah, Eric Lund - UNIX SystemLaboratories, Inc.

ABSTRACT

Any multi-user, multi-tasking operatingsystem, such as the LINIX SVR4 Operating System,must provide protectionmechanisms that prohibit one user from interfering with anotheruser, or limit the executionof certainsystem operations that affect critical system resources.These protection mechanisms must also provide the ability to overridethese restrictions,cornmonly referred to asprivilege. For over twenty years,UNIX-based operating systemshave had one suchprivilege, called "root" or "super-user"which is signifiedby ã processwhose effective user ID is 0. The "super-user" has the ability to overridethe restrictionsimposed by theseprotection mechanisms. In the UNIX SystemV Release4 EnhancedSecurity product this single,omnipotent, privilege is dividedinto a set of discrete privilegesdesigned to assurethat sensitivesystem services execute with the minimum amountof privilegerequired to performthe desiredtask. This paperdescribes the privilege control mechanismimplemented as part of the IINIX SystemV Release4.1 EnhancedSecurity (SVR4.lES) product. The SVR4.1ESprivilege controlmechanism separates the privilegemechanism from the accesscontrol mechanism, it providesfor fine grainedcontrol over sensitiveoperation access by users,and it controlsthe propagationof privilegefrom one processto another. Our goalsalso include accommodating multiple privilegecontrol mechanisms within the UNIX SystemV kernel. Theseprivilege mechanismscan be "plugged" into the kernel through well defined interfaces,much the ' sameway as UNIX file systemsare currentlyadded to the kernel.

Introduction modifications.This paperdescribes the kernelinter- ,,root,,privilege we definedthat are requiredto support The granularityof rhe is too l::t:":l]"ts of separate.-privilegemodules' It also coarsefor-a systemthat dictaresnnå granitarity-ìi l[^:",1":pt the assignmeníof privitege and rhe abiñty to gï:Í^b^t^t the major differences between the two modules the assJrtionof privitege-throughouttnr ó*r.uioi-oi"åítr"l n_riv]t3ee supportedunder svR4.lES. a process.fhe svn¿.irs privilegecontrol mechan- ProblemDefinition ism is designedto meetthe the followinggoals: Beforewe beginour discussion,it is necessary o to make the privilege control mechanisma to providea definitionfor the term privilege. Sim- ,,privilege" separate,loadable module, ply stated, is the ability to overrideres- o to make minimal changesto existingkernel trictions imposedþy protectionmechanisms. For code, example,a process/requires privilege to changethe a to separatethe privilege control mechanism systemdate, mount or unmounta file systern,or and accessmechanism, modify file attributes(if not the owner of the file) o to make the file-basedprivileges file system becausethese operations are restrictedby the protec- independent, don mechanisms. ' to preserveuNIx systemv compatibility' our missionfrom the start was explicit: add the Our approachwas to use the conceptof privilege capabilityof supportingdiscrete privileges assigned setsth-at are _assigned to both processesand execut- to each sensitivesystèm operationin the keinel. able files. The conceptof privilegesets is not new. This was necessaryio providè-privilegea -onprivilege policy that We are awareof two papersdiscussing the imple- basedpropagation of attributesother mentationof privilege control mechanismsthat also than the effective usei Ip. However, we also had madeuse of privilegesets [1][2]. the require-mentto remaincompatible with previous the The featurethat makesthe implementationof our UNIXOperating System by maintain- l-t:*lt^:fing the concept privilege control mechanismuniqu" is our f;ilh of a "super-user"' goal: file systemindependence. This featuremakes iteasyforfilesystemdeveloperstomakeuseofour_ priviregemechaíism. rn adåition, exisring nr; sys- åi":;,nf: îåi,:Îl.Hf,Lru¿ii:'lJååt":ä tem types function properly withour any ;-;';"orotro^.

'92 Summer USENIX - June 8-JuneL2,1992 - SanAntonio. TX 235 A PrivilegeMechanism ... Salemi....

The privilegecontrol mechanismwe chosefor UNIX Therefore, to accomplish this goal, a general SVR4.1ESremoves the omnipotenceof effectiveuser privilege interfacewas requiredthat would allow for ID 0 by defining a set of discreteprivileges, each the flexibility of specifying the privilege policy one used to overrideindividual restrictionsimposed desiredfor a particularprivilege module. by. sensitivesystem operations. It also definesan General Privilege I nterface inheritance policy, by associatingprivileges with Each concept executable files, to control propagation of below has a correspondingrou- tine in a specificprivilege privileges. In addition, it gives flexibility to control mechanism.The behaviorfor each routine designers of privilege modules by providing is relative to the privilege policy enforced privilege well{efined interface routines that are general by that mechanism. enoughto support a privilege policy basedon any Initialization processattribute. To beginwith, theremust be a way to initialize the systemprivilege mechanism at systeininitializa- Defining the Kernel Privilege Interface tion time. Functionsthat might be performedby this lVhy a Loadable Privilege Control Mechanism? procedureinclude: allocationof datastructures, ins- tallation of Our first goal was to make the privilege control "bootstrap" data, or initializationof localstatic variables. mechanism"plug compatible" so administrators could choosethe privilege policy they prefered at PrivilegeRequests systemconfiguration time. A procedureis needed to determineif a privilegerequested process There were quite a few debatessur- by a is containedin the "religious" set of privileges roundingthis particulargoal. One schoolof thought currently in effect for that process. This procedureis the policy argued very strongly that the operating system maker of any privilege shouldbe configuredwith a privilegepolicy that was modulebecause it makesthe decisionto grant or denyprivilege when in effect for the entire life of the system. It was felt a requestis made. that any deviation from the privilege policy only Propagation meant that the potential existed for more things to Anotherprocedure is requiredto calculatethe go wrong./ Another schoolof thoughtdisagreed con- privileges for new processes.This procedurepro- tending that the system went through one or more vides the privilege propagationmodel for the phasesbefore the entiresecurity policy was in place. module. They felt that while the systemwas transitioningto ProcessPrivilege M anipulation the frnal phase,the privilege policy shouldbe based A procedure on the effectiveuser ID and once the transitionto a is requiredto allow a processto count,set, securesystem was complete,change the privilege clear,and retrieve its privilegesets. policy to one that was file-based. ProcessPrivilege Recalculetion A procedure We decided to go with the first interpretationfor is requiredthat will recalculate severalreasons: processprivileges whenever the effective user ID is modified.r o The privilege mechanismhas always been a "point of attack" with respect to security FiIe PrivilegeM anipulation break-ins. Adding complexity for determin- Another procedureis requiredto assignand ing which privilege policy was in effect retrieveprivilege associatedwith a file. This allows appearedto weakenthe privilegemechanism. software external to the policy module to identify . Using the modular approach and defining files that are includedin the system.The systemis separateprivilege policies does not preclude madeup of files that havebeen analyzed and deter- the use of a privilege control module that minedto securelyuse certain privileges. behaves in the manner described by the secondinterpretation. When retrieving privileges this proceduremust retrieve them from the same data o It is flexible enoughto allow a designerof a structurewhere they are storedfor useby the propagationprocedure. privilege module the option of basing the privilege policy on other attributesof the pro- Fíle PrivilegeRemoval cesssuch.as the effectiveor realgroup ID, the A routine is requiredto removethe privilege sensitivity label of the process, etc. with information associatedwith system files whenever minor modifrcationto existing kernel source media containing"trusted" files is removedfrom code. In this case,only the privilege module the system. This preventsthe introductionof "Tro- sourcecode would require modification. The jan Horses" when a new file systemis mountedon privilege requestchecks in the kernel would the samemount point. remainundisturbed. 3This procedureis requiredto maintaincompatibility @f Murphy'sLaw. with lD-basedprivilege modules.

'92 236 Summer USENIX - June 8.June 12,1992- SanAntonio, TX Saleml,... A PrivilegeMechanism ...

Privilege M echanismInformation in the working set that are not in the new . . A procedureis requiredto allow a processthe ma,rimumset are removedfrom the working ability to retrieve specific informationregarding the set. privilegemodule. This informationmight be iñ the a Processprivilege sets are unchangedduring a form of--how many privilege sets are iupported by fork(2) operarion.The privilegesets of ihe the privilegemechanism, what the nameJof thosê child processare identical to those of the setsare, the numberof privilegescontained in each parent. set, which privilege mechanismis in effect, etc. File Privilege Sefs.. Cunently, two privilegemodules exist that makeuse A file canhave several privilege sets.ó File privilege of the privilege interfaceroutines. They are: sets are usedto establishthe privileges SUMmodule provides a privilege policy of. lhe newT that sup- processwhen the file is executed. ports a set of The following file discreteprivileges and the privilege set is "super-user" cunently supportedfor both privilege concept. This moduleis con- modules: sideredto be lD-basedsince the propagation ¡ Fixed privileges: a set of privileges of privilegeis based always on the effective'uàerID given to of the process. the new processindependent of tñe processprivileges of the invoking process. LPM moduleprovides a privilege policy that sup- portsa setof discreteprivileges and an inheii- The-following file privilege set is supportedonly in tanc.epolicy.a This moduleil consideredto be thefile-based privilege module: file-basedsince the propagationof privilegeis o Inheritable privileges: a set of privileges basedon the inheritancepolicy that useJthe given to the new processonly if the privilege maximumprivilege set of the currentprocess was in the maximum set of the invoking pro- and the set (or sets) of discreteprivileges cess. assignedto the executableprogram hte Uelng The following rules apply to file privilegesets: exec'ed, ¡ File privilege sets can only be assignedto Definitions ordinary,executable file types. o All privileges associatedwith a file T!. following is a list of the privilege ate . sets removedwhen the file is modified. required and their definitions. Also- indicãtedis which-privilege sets are used by the two privilege Isolationof the Privilege MechanismCode in the modulessupported in SVR4.lES Kernel ProcessPrivilege Sets The secondand third goalsinvolve the isolation process A can have several privilege sets.5 of the privilege kernel mechanismin the kernel Theseare usedto control the assignmèntof privilege cod.e. privilege mechanismwas tightlfcoupled throughout .The the life of the process. Cunently, boih with the accessmechanism because a-process i,rith privilege modules support the following þrocess effectiveuser ID 0 had unlimitedaccess. This asso- pnvilegesets: ciationhad to be severed.When we did this, how: . privileges: YT1 u. the ser of privileges ever,we wantedto keepthe modificationof existing held in trust for a process.This is ihe seiof kernelsource code to a minimum. privileges requiredby a process to complete Minimizing Kernel Changes all of the programtasks. o Working privileges: the set of privileges To achievethe secondgoal, minimizing kernel necessaryto complete a particular program changes,the kernel sourcecode was analvzeã.Two taskin a process. mechanismsfor determiningprivilege in the kernel were The following rules apply to the maximum and identified: working processprivilege sets: 1. callingthe internalkernel routine suser0 to o The working set is always a subset of the checkif the effectiveuser ID was 0, and maximumset. 2. explicitly checkingwhether or not the effec- tive userID was0. . fF working set may be alreredat any rime. The new workingset mustbe a subsetof the Existingroutines in the kernelthat eithercalled the maximum set. suser0 routine or checkedthe effectiveuser ID o The maximumset may be alteredat any time. The new maximumset is a subsetof the pre- oFile viousmaximum set. privilegesets are also limited to 255. /The termzew is usedhere rather When the maximumset is altered,privileges thanchild becausea prccessmay be exec'eddirectly ove¡ the callingprocess withoutinvoking the fork(2) systemcall. ThJprivilege 4Defined cont¡ol mechanismwill work properly becausethe iathe privitegepropagatian interface routine. JThe privilegesetting for the new processis donebefore the currentimplementation limit is 255. newprocess is executed.

'92 - Summer USENIX June E-June LZ, LggZ- San Antonio. TX 237 A Privilege Mechanism ... Salemi,...

had to be modified to call the prívilege requesttolr- those privileges requìred to complete all its tasks tine definedin the privilegemodule.6 instead of giving it all privileges via the Separatlonof Privllege and AccessMechanlsms setui.dinode of.the file. This methodprovides a protection policy in use. from usersbecause of the well-definedsvstem inter- F ile-B asedPropagation Model face for accessingthe inode. However,this imple- mentation is limited because file system types The following model is in effect for the alreadyin use can not take advantageof a modular file-basedprivilege module: privilege implementation. A privilege can be acquired only if the Because of this limitation another method was privilege exists in the maximumset of, the cal- needed to achieve the fourth goal of file system ling processor is in the frxed sef of a file. A independence.This method must provide similar processwith an emptymaximurn set can never protection from users that the inode schemepro- passa privilege to anotherprocess. The com- vides, i.e., it should be accessedonly througha putationof the new maximumand working sets well-defined interface. Also, to achieve the first is donein the execQ kernelcode: goal, it has to fit well into the modularprivilege Step [A] The maximumset of the calling process interface. is intersectedwith the inheritableset associ- atedwith the programfile being executed. To meet thesegoals a memory-basedkernel table is Step [B] The result of Step [A] is unioned with used to define the privileged commands in the the set associatedwith the programfile operating fued system. Using a memorybased table pro- being executedto form the new maximumand vides the following beneñts: working sets, o File systemindependence. The privilege con- trol mechanismcan work acrossfile system There is an important principle implemented types. by this feature: A processgains only those o The number of privileged commandscan be privileges that were in either its fixed or reduced,or expanded,independent of the inheritableprivileges. A startingproc€ss can- privilegepolicy in use. not force a privilege onto or through a new o Privilege can never be imported from othe¡ process.If a processmistakenly executes the media since the privilege information is not t¡/rongnew process(i.e., a "Trojan Horse"), part of the file attributes] it cannotpass any privilegesthat the new pro- was ID-Bas ed M echanisrnF eature cess not designedto enforce. Figure Using the setuid-on-execmechanism9 and set- L illustratesthe file-based propagation model. ting the owner of an executablefile to roor is still supported in the lD-based privilege mechanism ID-Based Propagation Model becausethat privilege policy supportsthe conceptof The following model is in effect for the "super-user." However, this mechanismalso sup- ID-basedprivilege module: portsfued privilegeson executablefiles. Therefore, A privilege can be it is possible to assign to an executablefile only acquired only if the privilege exists in the maximumset of, the cal- lirg processor is in thefixed sef of a file. The @in devicedrivers had already computationof. the maximumand workíng sets been addressedin SVR4 by providing the DDr/DKI for the resultingproc€ss is done in the execQ interfaceroutine, drv3riv [4]. kernelcode: YU.S. Patent# 4,135,240.

'92 238 Summer USENIX - June 8.JuneL2,1992 - SanAntonio, TX Salemi,... A PrivilegeMechanism ...

First, the maximum privilege set of the calling indicatorfor use later and go to Step processis stored in a temporaryprivilege set tDl. when the propagationroutine is entered. Then, Step[D] Doesthe executablefile being exec'ed the following conditionsare evaluatedto deter- have any fixed privileges? If so, add mine the maximumand working privilegesets these privileges to the temporary for the resultingproc€ss: privilegeset. Step[A] Doesthe executablefile being exec,ed If privilege have the setuid-on-execbit asserted?If the sets for the calling pro- yes,go to Step If no, set the tem- cess differ from the temporaryprivilege [B]. setgenerated polary privilege set to 0 and go to Step above,do the following: tDl. a. set the maximumprivilege set for the resultingprocess Step [B] Is the owner of the executablefile being to the tem- exec'ed "root"? If yes, turn on all poraryprivilege set. b. privileges in the temporaryprivilege set If the indicatorwas set in Step set the working privilegeset and go to Step [D]. Otherwise,go to [C], for the resulting process Step[C]. to the fixed set privileges Step [C] Is the effecrive user ID of the calling of found on process "root"? If no, turn off all the executablõfile.Io Otherwise, privileges in the temporaryprivilege set ffin compatibilitywith older and go to Step [D]. Otherwise,set an versionsof theUNIX operating system.

exec0

maxlmum {2,3,6,91 working {2,3,6,9}

Figure 1: The File-BasedPropagation Model

Figure 2: The ID-Basedpropagation Model

Summer'92USENIX - June 8-June12,1992 - SanAntonio, TX 239 A Privilege Mechanism ... Salemi,...

set the working privilege set for effective UID is equal to the privileged the resultingprocess to 0. tD. Figure 2 illustrates the lÞ-based propagation Otherwise,only clearthe working privilegeset model. if neither Condition [A] nor Condition [B] are Privilege Recalculatlon true. The privilege recalculationroutine adjuststhe Figure i illustrates the lÞ-based recalculation maximum and working privilege sets of a process model. accordingto the privilege modulein use. F iIe-B ased Rec alculation M ode I Conclusion This routine has a null effect in the file-based Moving the privilege mechanismfrom the ker- privilege module. This is becausewe intentionally nel proper to a separate,loadable module was separatedthe accessmechanism from the privilege extremely simple. We were fortunate that the mechanism(see Section 3.2). checks for privilege in the kemel were somewhat well-defined. IÈB øse d Reca lculation M ode I We were also fortunatethat our sys- tem was basedon UNIX SystemV Release4 sincea This routine has extreme signiñcancein the lot of the groundwork to make the separationeasier IÞ-based privilege module becauseof the right- was donein thatrelease. coupling betweenthe accessand privilege mechan- ism. This routine is called by the access0, In addition,we maintainedcompatibility with SVR4 setuid0, and seteuidQ systemcalls. despiteextensive modifications required in the ker- nel. This means that any operating system The following model is in effect for the lD-based configuredwith the SUM module bühavesin the privilegemechanism: exact same manner as an SVR4 OperatingSystem The maximum and working privilege sets for with hard-codedprivilege checksfor effective UID the current processare adjustedwhenever the 0. effective user ID is modified basedon the fol- lowing conditions: References Condition [A] Clear the maximum and working [1] Knowles,F. and Bunçh,5., A LeastPrivilege privilege sets for the curent processif Mechanismfor UNIX. Proceedingsof the 10th none of the processUIDs (effectiveUID, NationalComputer Security Conference. (Sep saved UP-, or real UID) equal the 1987)Baltimore, MD. privilegedll lo. [2] Hecht, M. S., et al. UNIX Without the Condition[B] Otherwise,ser the working privilege Superuser.Summer USENIX Technical Confer- set to the maximumprivilege set if the encesand Exhibition. (Jun 1987)Phoenix, AZ. [3] Bach, Maurice J., The Design of the UNIX OperatingS.ystem, Prentice-Hall, Inc., 1986 ttTtre privìlegedID hastraditionally been user ID 0. However,this is nowa tunablevariable allowing for any [4] UMX Press Title, UNIX System V Release4 userID to be considered"all-powerful" in an lD-based Device Driver InterfacelDriver-Kernel Inter- privilegemechanism. User ID 0 is the defaultvalue for face ReþrenceManual, thisvariable.

A¡e any processUID's Is the effectiveUID equalto the "privileged"ID? equalto the "privileged"ID?

Figure 3: The ID-BasedRecalculation Model

'92 240 Summer USENIX - June 8-June12,1992 - SanAntonio, TX Salemir... A PrivilegeMechanism ...

Author Informatlon CharlesSalemi is currently a Member of Staff at UNIX System Laboratories,Inc. He has been involved with the UNIX OperatingSystem since he receivedhis degreein ComputerScience from the City University of New York in 7977. He has been a memberof the SecurityDevelopment Team since 1987. Within this projecthis principalinterests have been in the areaof the privilege mechanismand the Identification' and Authentication facility. Along with his other accomplishments,he was one of several people responsiblefor the developmentof the SourceCode Control System (SCCS). SuryakantaShah is a SeniorMember of Staff at UNIX System Laboratories.She receiveda MS in Computer Science from Queens College in 1983. During the past 1.0years at UNIX SystemLabora- tories,she has worked on numerousfeatures of Sys- tem V including 82 security, processmanagement, virtual memory,a¡d the RFS distributedfile system. Cunently, Kanta is adding multiprocessingcapabili- ties to the 82 securityfeatures. Eric Lund receiveda BA in English from Tufts University in 1984. Since Spring of 1991 he has been a Senior Programmer/ Analyst developingon 'inMulti-Level Securityfeatures for Cray ResearchInc. Eagan,Minnesota. Prior to his work at Cray,Eric worked at USL where he helped develop the Privilege, Trusted Path, and Audit mechanisms, developedthe TrustedFacility Managementmechan- ism, and performedCovert Channel Analysis on Sys- tem V Release4.l.ES. Eric was alsoone of the prin- cipal developersof the SystemV VerificationSuite. In his sparetime, Eric enjoyscamping, rock climb- iog, juggling, woodworking, and beer brewing/tasting.

Summer'92 USENIX- June8-June 12,1992 - SanAntonio, TX 241