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