Commentaires 0

Retranscription du document

The Impact of LinuxSuperuser Privilegeson Systemand DataSecurity within a CloudComputing StorageArchitectureDiploma ThesisAuthor:Steffen SchreinerComputer Science,April 2009Prof.Dr.Johannes BuchmannDepartment ofCryptography andComputeralgebraDiploma Thesis in Computer ScienceThe Impact of Linux Superuser Privilegeson Systemand Data Security within aCloud Computing Storage Architectureby Steffen SchreinerApril 2009The thesis was developed in cooperation with a companyunder a nondisclosure agreement.This document ispublic,all company and product informations werepseudonymized and it has been edited for content.Supervisor and Examiner:Prof.Dr.Johannes BuchmannCryptography and ComputeralgebraDepartment of Computer ScienceTechnische Universität DarmstadtDeclaration of Academic HonestyI hereby declare that this diploma thesis is my own work and has not been sub-mitted in any formfor another degree or diploma at any university or other insti-tute.Information derived fromthe published and unpublished work of others hasbeen acknowledged in the text and a list of references is given in the bibliography.Ehrenwörtliche ErkärungHiermit versichere ich,die vorliegende Diplomarbeit ohne Hilfe Dritter und nurmit den angegebenen Quellen und Hilfsmitteln angefertigt zu haben.Alle Stellen,die aus den Quellen entnommen wurden,sind als solche kenntlich gemacht wor-den.Diese Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbe-hörde vorgelegen.Darmstadt,April 2009 Steffen SchreinerTo Hanne and GerhardDu kannst!So wolle nur!(You can!Just will it!)J.W.v.Geothe,Faust IAbstractDiscretionary access controlled operating systems like Linux are unsuited to beused as a basis for service-oriented environments or within the scope of cloudcomputing,as it is not possible to partition or decompose the power of superuserprivileges in a convenient way.This deﬁciency of possible decomposition is notonly a threat in the face of potential privilege escalation and exploitation or ahostile administrator,but is a major functional drawback.This thesis develops seven problem statements with respect to the applicationITComp Clustered Data Services (CDS).These concern the Linux superuser privi-leges’ characteristics omnipotence,resistiveness,unavoidable obtainment,cover-upassistance,undermined conﬁdentiality,unfeasible compartmentation,and degradedcompliance.Analyzing four available Linux security mechanisms,SELinux stands out as theonly mechanism suited for a potential solution.SELinux is analyzed and de-scribed in detail with respect to its potential application in CDS.Finally,the thesisgives an outline for the advancement of the SELinux Reference Policy to incorpo-rate the software components of the ITComp CDS cluster.ContentsContents1 Introduction 11.1 Motivation....................................11.2 Objective of the Paper.............................31.3 Outline......................................32 Background and Fundamentals 52.1 Security Goals..................................52.2 Access Control..................................62.2.1 The Principle of Least Privilege..................82.2.2 Discretionary Access Control....................82.2.3 Mandatory Access Control.....................92.2.4 Role Based Access Control.....................102.2.5 Superuser Privileges.........................102.2.6 Reference Monitor..........................112.2.7 Type Enforcement...........................112.2.8 Bell-LaPadula Model.........................122.3 Threats,Vulnerabilities and Attacks....................132.3.1 Flawed and Malicious Software..................132.3.2 Privilege Escalation..........................142.3.3 Rootkits.................................14IXContents2.3.4 Zero-Day Attacks...........................152.3.5 Covert Channels............................153 The Linux Operating System and the Superuser 173.1 Linux Architecture...............................173.2 Access Control..................................193.3 The Superuser..................................193.3.1 Setuid..................................203.3.2 Sudo - Substitute User Do......................213.3.3 POSIX Capabilities..........................223.3.4 Chroot..................................233.3.5 Conclusion...............................244 ITComp Clustered Data Services 254.1 Introduction...................................254.2 ITComp Very Large File System.......................264.3 Architecture...................................274.3.1 Clustered Trivial Database.....................304.3.2 Services.................................314.3.3 Directory Service...........................314.3.4 Backup and Archiving........................324.4 Administration.................................324.5 Signed Software Updates...........................334.6 Multi-Client Capability............................345 The Problem of the Linux Superuser 355.1 Omnipotence..................................365.2 Resistiveness...................................375.3 Unavoidable Obtainment...........................385.4 Cover-up Assistance..............................385.5 Undermined Conﬁdentiality.........................39XContents5.6 Unfeasible Compartmentation........................405.7 Degraded Compliance.............................416 Requirements to Secure the CDS Cluster 436.1 Security Goals of CDS.............................436.2 Prerequisites and Dependencies.......................446.3 CDS Cluster Requirements..........................466.4 A Role Design for Administration......................476.4.1 Analysis and Reporting Role....................486.4.2 Access Management Role......................486.4.3 Service Management Role......................496.4.4 Resource Management Role....................496.4.5 System Maintenance Role......................506.4.6 Data Management Role.......................506.4.7 Remaining Privileged Access....................517 Mechanisms to Conﬁne the Linux Superuser 537.1 Linux Security Modules............................547.2 AppArmor....................................557.3 Grsecurity....................................567.4 RSBAC......................................577.5 SELinux......................................598 SELinux in Detail 618.1 Architecture and Functionality.......................618.2 Type Enforcement...............................648.3 Deﬁning Roles..................................668.4 Multilevel Security...............................678.5 Reference Policy................................678.6 Policy Analysis.................................69XIContents9 Outline for a Secure ITComp CDS Cluster with SELinux 719.1 Prototyping a SELinux Policy extension..................719.2 Applying File Contexts in VLFS.......................749.2.1 Security Context Labeling in VLFS’ Extended File Attributes 749.2.2 Specifying VLFS Security Contexts in the Policy........769.2.3 Specifying VLFS Security Contexts as Mount Option.....789.3 Multi-Client Capability............................789.4 Performance Inﬂuence.............................799.5 Future Work...................................8010 Conclusion 81Abbreviations 83List of Figures 85Bibliography 87XIIChapter 1.Introduction...once someone learns the root password who sympathizes with theordinary users,he or she can tell the rest.The ”wheel group” featurewould make this impossible,and thus cement the power of the rulers.I’mon the side of the masses,not that of the rulers.If you are used tosupporting the bosses and sysadmins in whatever they do,you mightﬁnd this idea strange at ﬁrst.Richard M.Stallman,Gnu Core UtilsApplications derive their functionality and assurance fromthestrength of the underlying infrastructure;unfortunately,thedependability of that infrastructure has largely been ignored.Dixie B.Baker,Fortresses Built Upon Sand1 Introduction1.1 MotivationBy the end of 2007,the companies IBM and Google announced an initiative1to encourage the development along the so called cloud computing paradigm.1http://www.nytimes.com/2007/10/08/technology/08cloud.html11.1.MotivationCloud computing can be considered as a relative of the grid computing approachwhile also comprising aspects of service-oriented architecture (SOA),Softwareas a Service (SaaS),and hardware management and cost of ownership arisingfrom utility computing [AFG+09].The idea of cloud computing is to pool for-merly separated computing infrastructure into major environments that supportscalability on demand while hiding localization and implementation,and offer avariety of applications to a multitude of users or clients as an application service.In June 2008,the information technology research ﬁrm Gartner published areport [HN08],declaring seven major security issues regarding the emerge ofcloud computing,whereas the ﬁrst two stated issues are privileged user accessand compliance.Although,the report concentrates on a totally opaque scenarioof computing,with unknown service providers and a priori unwarranted servicequalities,it points out an issue,which already applies to less complicated envi-ronments.Discretionary access controlled operating systems like Linux are unsuited to beused as a basis for service-oriented environments or within the scope of cloudcomputing,as it is not possible to partition or decompose the power of supe-ruser privileges in a convenient way.This deﬁciency of possible decompositionis a threat from both potential privilege escalation and exploitation and hostileadministrators.While the user side of such distributed applications can be se-cured and more strictly controlled through additional layers within and aroundthe application,a similar approach regarding the activity of system administra-tion is much more difﬁcult.The reason for this is the need for privileged access,respectively superuser privileges,in the course of administration.Since discre-tionary access controlled superuser privileges can circumvent security layers bymodiﬁcation of system resources’ ownership and their permissions,it is very dif-ﬁcult to limit a superuser’s access.Although,only selective operations actuallyneed privileged access during system administration,the coarse grained conceptof the discretionary access controlled superuser represents only an all or nothingfreedom of decision.2Chapter 1.Introduction1.2 Objective of the PaperThe application Clustered Data Services (CDS) is a high-performance network-attached storage (NAS) application developed by the company ITComp.Follow-ing a clustered,horizontal scaling architecture and along with the idea of cloudcomputing,ITComp CDS is intended to centralize formerly separated technologyinto one massive system.The application’s clustered central unit is based on aRed Hat Enterprise Linux version 5 and provides storage access by several net-work protocols as different services.Subject matter of this thesis is the analysis of superuser privileges in the oper-ating system Linux with respect to its utilization in the application ITComp CDS.The goal is to identify the problems arising from superuser privileges and to dis-cover and discuss potential methods of resolution and their capabilities.Finally,the thesis gives an outline,how and to what extent a solution can be achievedand realized.1.3 OutlineStarting with the background and fundamentals of computer security and accesscontrol in Chapter 2,the thesis gives an overviewof different access control mod-els and attacks.Subsequently,in Chapter 3 the operating system Linux and itssuperuser root are presented and Linux’ mechanisms regarding its utilization andscope of validity are described.Chapter 4 describes the architecture and designof the application ITComp Clustered Data Services (CDS),its components andtheir interaction.Within Chapter 5 seven problems are developed and formu-lated concerning superuser privileges in Linux with respect to its appliance inthe application CDS.Chapter 6 speciﬁes the prerequisites and requirements for31.3.Outlinea solution to the seven problems described in the previous Chapter.Beyond,theChapter contains an exemplary abstract role design regarding the administrationof CDS.During Chapter 7 four available security and access control extensions forthe operating systemLinux are presented and discussed with respect to the spec-iﬁed requirements and a potential utilization within CDS.Chapter 8 describes indetail the architecture and functionality of the Linux security extension SELinuxand Chapter 9 gives an outline for a potential appliance of the extension withinCDS,especially concerning the association of the CDS data storage.Finally,Chap-ter 10 presents the conclusion.4Chapter 2.Background and Fundamentals2 Background andFundamentalsThis chapter presents an overview of the background and fundamentals of se-curity and access control in computer systems.The individual sections are notmeant to discuss the particular topic exhaustively,but to supply the necessaryfoundations for this thesis in order to discuss superuser privileges in the scope ofsecurity.2.1 Security GoalsThis thesis is based on the security goals conﬁdentiality,integrity,availability,au-thenticity and accountability,which are outlined as follows:ConﬁdentialityConﬁdentiality represents the concept of carrying or transferring informationwhile avoiding any unauthorized leakage,respectively keeping the informationconﬁdential or secret.Not providing any information may include even to keep52.2.Access Controlthe simple existence of the information conﬁdential or secret as well.IntegrityIntegrity states that an information or system is not modiﬁed in an unauthorizedmanner.Analogue,integrity concerns the detection and the prevention of its vi-olation,whereas both aspects are assumed to be crucial.AvailabilityAn information or systemneeds to be protected frombeing retained or withheld.An example for a violation of a system’s availability is a denial of service attack.AuthenticityAssuring authenticity means to guarantee the genuineness of an object,such asto guarantee the identity of the senders in the course of a message exchange orthe identity of the originator of a data set.Within access control an authentica-tion veriﬁes the identity of a subject based on a predeﬁned procedure,like e.g.the presentation of a user identiﬁcation and a corresponding password.AccountabilityA system needs to process and keep logging and audit records in a tamper-proofmanner and provide authorized subjects access to these records.2.2 Access ControlAccess constitutes the distinction of a subject and an object and describes a relationbetween them.An object can be protected by supervision over its access,whichis termed access control.Consequently,the extend of access a subject is providedwith,is limited by access control.In order to be able to protect resources and6Chapter 2.Background and Fundamentalsdata,computer systems use access control mechanisms to decide which kind ofaccesses should be either allowed or denied.A simple but very fast access control mechanism is a two dimensional matrix,stating which subjects may access which objects.Yet,matrices have certain draw-backs as e.g.their maintenance and storage.Another mechanism is an AccessControl List (ACL),which represents a list associated with the concerned objectthat includes all allowed accesses and the corresponding subjects.Permissions in respect to access control within the scope of computer systemsare verbalized in several ways,such as rights,privileges or permissions.Withinthe remainder of this document the termrights will be utilized in order to refer toconcrete technical representations of certain permissions,such as e.g.the rightto read a ﬁle.The termprivileges will be employed whenever an abstract extentof permissions is discussed.An important aspect while discussing access control concerns the distinction ofdifferent kind of accesses.Well known access rights are e.g.read,write,andexecute.The strength of expression of an access control mechanisms depends onboth the possible ways of describing subjects and objects and what kind of accessrights are distinguished and classiﬁed.For instance,a system might distinguishthe permission of writing to a ﬁle into either the operation of altering and pos-sibly deleting existing content and the act of only adding new information.Thiswould describe the differentiation of a real write and an append only access.An-other special formof access rights regards their delegation,as a subject may havethe permission to pass on rights or abstract sets of privileges to other subjects,which will be further discussed in Section 2.2.2.A system or mechanism can allow all possible accesses by default and only con-strain,control,or prohibit certain accesses.This behavior is called default allowand also referred as blacklisting,since all entities named in a list represent forbid-72.2.Access Controlden accesses.Correspondingly,the contrary behavior of only allowing by explicitdesignation is called default deny or whitelisting.2.2.1 The Principle of Least PrivilegeOne rule or principle for designing security systems is the principle of least privi-lege,which delineates a guideline about the amount of privileges subjects shouldbe granted with."The principle of least privilege states that a subject should be given onlythose privileges that it needs in order to complete its task."[Bis03]The deﬁnition of the principle of least privilege presumes a given access controlmethod with a given strength of expression.The extent of effectiveness or gain ofthe principle in a concrete system depends fundamentally on that strength.Thecoarser the access control is implemented,the more access privileges a subjectwill be awarded by the principle,since ”the least” is a statement that is speciﬁedrelative to the utilized access control mechanism.2.2.2 Discretionary Access ControlDiscretionary access control (DAC) is based on the idea of identity of subjects andobjects and ownership as a relation between them.The ownership entitles anowner to determine the access privileges regarding the owned object,respec-tively grant and revoke other subjects access to that object.Beyond,it may be8Chapter 2.Background and Fundamentalseven allowed to hand on the ownership of an object to other subjects.Hence,DAC is also called identity-based access control [Bis03].DAC can be describedas a mechanism due to which an object’s access privileges are at least partiallydetermined by its owner.Accordingly,the owner of an object needs to foreseethe possible consequences of her inﬂuence and actions regarding access controladjustments.This aspect highly inﬂuences both system and data security.A discrepancy regarding DAC concerns the abstract concept of ownership,as theDAC ownership represents the intention to translate a social real world conceptinto the scope of computer systems.However,an operating system and the run-ning software has the power and sovereignty over its resources and data.Thus,the abstraction of ownership can be only represented within this limits and a usercan only access data and resources due to the utilization of the operating systemand the running software.2.2.3 Mandatory Access ControlIn contrast to the concept of ownership and delegation an alternative is to instan-tiate an authority that rules over access in a mandatory manner.Mandatory accesscontrol (MAC) bases access decisions on a given systemof rules,which is referredto as access policy.Neither a decision derived from the access policy nor the pol-icy itself can be modiﬁed by any normal subject or entity in the concerned systemand the derived decisions must be enforced.MAC mechanisms can also considerother concepts or mechanisms of access control.However,regarding genuineMAC implementations,the policy must always be evaluated within the processof decision making and the ﬁnal decision must be dominated by the policy.Forinstance,a MAC system can support a concept of ownership and delegation,yetonly within the boundaries of legality in regards to the access policy.92.2.Access ControlIn order to maintain the access policy,it is possible to entitle a system entitywith the privileges to access and modify the policy.Another approach is to en-force the system into a certain state in order to load a new policy and thereforeensure that the policy is immutable during normal system operation.2.2.4 Role Based Access ControlAnother approach in order to model extents of access privileges is called rolebased access control (RBAC) [FK92],[FCK95].By insertion of a new level ofabstraction,access privileges are not directly applied to user accounts,but toroles.The user’s extent of access privileges is deﬁned by the roles she is permittedto utilize.Depending on her designated actions,a user needs to switch her activerole and therefore performs tasks with different sets of privileges,whereas arole can be utilized by several users.Users may be allowed to use several rolessimultaneously,or they are restricted to only one active role at a time.Further,roles can reﬂect hierarchical relationships.The concept of RBAC can be combined with either DAC or MAC mechanisms.2.2.5 Superuser PrivilegesWithin this thesis the termsuperuser will be generally utilized in order to denotea user account within a computer system that is equipped with a superset of allavailable privileges.Thereby,this superset is made up of concrete privileges andthe right to change ownership of all data and resources in matters of delegation.10Chapter 2.Background and Fundamentals2.2.6 Reference MonitorComputer systems that are shared by several participants employ an entity thatcontrols and enforces the access relationship between each user and its environ-ment within the system.Such an entity,called the reference monitor [And72],canvalidate all references to programs and data,while it complies with the followingproperties.• The reference validation mechanism is tamper proof.• The reference validation mechanism is always be invoked.• The mechanism is small enough to be tested (exhaustively if necessary).2.2.7 Type EnforcementType Enforcement is an access control mechanism ﬁrst described by Boebert et al.[BK85].The underlying idea is to classify a system’s subjects and objects alonga set of equivalence classes,whereas classes of subjects are called domains andclasses of objects are called types.All domains and types receive identiﬁers calledlabels.Legitimate accesses are deﬁned by the association of domains and typesor of domains among one another.Two tables called the Domain Deﬁnition Tableand the Domain Interaction Table are utilized in order to model the associations,containing concrete access rights along the existing labels.An extension of the Type Enforcement approach is the Domain Type Enforcement[BSS+95],at which the two tables are replaced by a high-level language thatprovides more ﬂexibility in expressing associations.Further,the extension intro-duces the concept of implicit typing,the maintenance of type and domain labels112.2.Access Controlduring system run-time.Whereas within the original Type Enforcement mech-anism,it is necessary to maintain these labels in an auxiliary task.Along withimplicit typing,subjects and object are determined based on system hierarchyand listed exceptions.The Type Enforcement or the Domain Type Enforcement approach can be uti-lized in order to implement mandatory access control within a system,as theaccess control is based on enforceable rule sets.2.2.8 Bell-LaPadula ModelA famous security model called the Bell-LaPadula Model [BL73,BL76] was de-signed in order to enable the utilization of different levels of conﬁdentiality andis based on the following two properties:Property 1 (no read-up):A subject may only read an object if its security levelis as least as high as the objects security level and the access is discretionaryallowed.Property 2 (no write-down):A subject may only write to an object if its se-curity level is at most as high as the objects security level and the access isdiscretionary allowed.The simple Bell-LaPadula Model can be extended in order to function not onlybased on different levels,but as well on different categories or compartments.This combination of levels and categories presents a lattice,whereas the level12Chapter 2.Background and Fundamentalsbased properties above need to be adjusted in order to function as a dominancepredicate within this lattice [Bis03].2.3 Threats,Vulnerabilities and AttacksThe opponents of security or protection goals are threats,their correspondingrisks,attacks,and the underlying vulnerabilities.A threat is a potential securitybreach with respect to the deﬁned security goals [Bis03].A particular threat cor-responds to an underlying vulnerability of a system.A threat can be suppressedby control of the corresponding vulnerability [PP06].Anattack is the exploitationof a vulnerability.Yet,threats are not necessarily connected to attacks,as thereare also threats like human or system errors and environmental dependencies.Finally,the risk is a combination of probability and impact of a certain threat.A major goal in the scope of security is the control and consequently the deter-mination and mitigation of vulnerabilities in order to reduce their correspondingthreats.2.3.1 Flawed and Malicious SoftwareRegarding computer security the term ﬂaw with respect to software does notnecessarily imply a piece of program code is not serving its purpose correctly.A ﬂawed software might be working perfectly,but the ﬂaw has not taken effector may even never take effect.Software ﬂaws may be not only errors,but aswell gaps,holes or opportunities,which are exploitable for attacks and therefore132.3.Threats,Vulnerabilities and Attacksrepresent vulnerabilities.The exploitation of software ﬂaws or the attack on vulnerabilities are representa-tives of malicious software appliance.Malicious code or malicious logic is a pieceof software,that violates a system’s security policy [Bis03].2.3.2 Privilege EscalationWhile having access to a system either by normal authorization or due to an at-tack,privilege escalation describes the act of gaining additional privileges due tothe exploitation of vulnerabilities [PP06].Thereby,the gain of superuser priv-ileges may be of special interest,as they represent the maximum of possibleprivileges (see Section 2.2.5).2.3.3 RootkitsA special kind of malicious software that utilizes privilege escalation is repre-sented by so-called rootkits.Rootkits are based on the inﬁltration of maliciouscode into a computer system while hiding their existence as long as possible,respectively as long as the duration of a further agenda [Eck08].The inﬁltra-tion is accomplished due to privilege escalation,potentially combined with otherattacks,whereas a major target is the gain of superuser privileges.Figure 2.1shows possible ambushes for rootkits in operating systems.Whereas,the ﬁrsttwo cases reﬂect a scenario,in which the rootkit undercuts the operating system,the remaining three cases each denote a different hide-out within the operating14Chapter 2.Background and Fundamentalssystem.Each of the different ambushes is associated with a foregoing privilegeescalation in order to gain a sufﬁcient amount of privileges to enter the corre-sponding location within the computer system.Figure 2.1:Rootkit Ambushes,Source:Modiﬁed [Tan08]2.3.4 Zero-Day AttacksZero-day attacks are based on vulnerabilities that are not known or ﬁxed yet.Thetermrefers to the time frame between the moment an individual gains knowledgeabout the vulnerability and develops a feasible attack and the moment the attackis actually executed.Since a target has no knowledge about the threat,it has notime and opportunity for preparation or protection.2.3.5 Covert ChannelsCovert channels are a technique to overcome access control and security mech-anisms by using shared system resources for communication [Bis03].Typical152.3.Threats,Vulnerabilities and Attacksexamples are statistical information about a system,such as memory or proces-sor workload,an operating system’s process list,or the meta information storedin a ﬁle system.By implementation of a protocol that was agreed upon before,such as a binary encoding based on existence and non-existence of a resource,entities or subjects are able to exchange information.The leakage of conﬁdentialinformation is only one example of the threat a covert channel can constitute,violations of communication protocols or circumvention of defense mechanismsare others.Covert channels are used for example,to inﬁltrate malicious codeinto a system in a covert or secret manner.Thus,covert channels are not onlyconnected to attacks on conﬁdentiality.16Chapter 3.The Linux Operating System and the Superuser3 The Linux OperatingSystemand theSuperuserThis chapter gives a presentation of the relevant characteristics of the Linux op-erating system.A short introduction on the Linux architecture and its accesscontrol is followed by a description of the Linux superuser account root.Theremainder of this chapter discusses available proprietary Linux mechanisms thatconcern the area of validity and power of the system’s superuser and the potentialdecomposition of its privileges.3.1 Linux ArchitectureThe Linux kernel follows a monolithic design,whereby the kernel is responsiblefor all core features of the operating system and organizes these features withinone address space.By utilization of kernel modules it is possible to load andunload programcode into the kernel during systemrun-time.However,the mod-173.1.Linux Architectureules’ program code resides also in the kernel’s address space and is consequentlypart of the monolithic kernel layer called the kernel space.On top of the kernelspace resides the system’s user space,which is also known as the Linux userland.The user space consists of the operating system’s libraries,applications and itsmulti-user environment.Figure 3.1 shows this layered Linux architecture.In order to switch between the operating system’s user and kernel space,Linuxutilizes different mechanisms for each direction.The Linux kernel receives sys-tem calls from user mode through its system call interface and uses kernel signalsto send information into user mode.In order to submit system calls without fur-ther restrictions,a user or subject needs to possess superuser privileges.Normalsystem users can only use a subset of the available system calls.Other connections between the kernel and the user space are the virtual ﬁleFigure 3.1:Linux SystemLayers,Source:modiﬁed [Tan08]systems procfs and sysfs.Both ﬁle systems exist for special purposes and as analternative to system calls,e.g.in order to conﬁgure kernel modules,read thesystem’s process list,or trigger the kernels network behavior.18Chapter 3.The Linux Operating System and the Superuser3.2 Access ControlLinux utilizes a DAC mechanism based on users and groups to organize and con-trol accesses.A user has certain privileges based on her identity and her member-ship in groups.The ﬁle system distinguishes the three access rights read,write,and execute,which are organized as a triplet.Each object in the ﬁle systemholdsan attribute with three entries of these triplets,for each the owner,the owninggroup,and a third one concerning other subjects.This last entry represents theaccess privileges applying to anybody that is neither member of the owning groupnor the owner herself.An objects owner can alter all of the three triplet entriesand therefore delegate access to the object.3.3 The SuperuserWithin the operating system Linux,the superuser is the only user account thathas the right to write the topmost entry in the ﬁle system hierarchy ’/’,which iscalled root.The ﬁle system mounted at this location is called the root ﬁle system.Consequently,the superuser account is named root likewise.This characteristicis derived from Linux’s ancestry in the Unix world and can be found in a lot ofother Unix operating systems as well.The Linux root user is the ﬁrst and only user account present in the systemduringstart up and has the numeric user id ’0’.During normal systemoperation it is theonly user that can enter the kernel space without any restrictions.Accordingly,the root user owns all system resources at least through delegation.In otherwords,the root user possesses a superset of all user privileges in a Linux system.Running a genuine Linux system without further extensions or restrictions,thesystem and its user’s data is completely at the mercy of the persons that haveroot privileges at their disposal.This is also the case if the root privileges where193.3.The Superuseracquired unauthorized as described in Section 2.3.3.The following ﬁve sections brieﬂy discuss four different mechanisms related tothe validity and propagation of superuser privileges in a Linux operating system.3.3.1 SetuidWhenever a Linux program is executed,the program’s process is started andrunning thereafter by utilization of the executor’s user and group identiﬁer.Con-sequently,the program receives the privileges the user and its group are entitledwith.Setuid is a bit attribute of ﬁles in Linux ﬁle systems,that triggers the operatingsystem to execute a program with the privileges of the corresponding ﬁle owner.The setgid bit offers the analogue functionality for group privileges.By utilization of this mechanism it is possible e.g.to allow unprivileged users toexecute programs with superuser privileges.A standard utilization scenario ofthe setuid bit regards the programpasswd,which enables users to change theirsystem password.Obviously a normal user should not be able to edit the sys-tem’s password ﬁle,but only to write the entry concerning her own password.By setting of the setuid bit attribute for the passwd program ﬁle owned by root,the program is not started with the caller’s but rather with superuser privileges.Thereby,it is the responsibility of the passwd program not to enable a user to doanything more than to edit her own password.20Chapter 3.The Linux Operating System and the Superuser3.3.2 Sudo - Substitute User DoThe Linux program sudo enables users to run programs by appliance of otheruser accounts,and consequently can be used in order to run programs with su-peruser privileges.A central system conﬁguration ﬁle controls the usage of theprogram.The ﬁle contains information about which users can run what programsby utilization of which other user accounts and offers some elementary conﬁningpossibilities,such as e.g.shell parameter matching and time out speciﬁcation.By appliance of sudo it is possible to allow listed users to run only certain pro-grams.For instance,a user could be allowed to run the passwd program in orderto change other users passwords,but exclude certain arguments respectively cer-tain users by further speciﬁcation in the conﬁguration ﬁle [Ano01].Thus,sudois e.g.able to allow only the editing of speciﬁc ﬁles,yet it does not provide anymethods to conﬁne or control the editing process itself.More precisely,the appliance of sudo has fundamental limits concerning the pro-gram execution after its foregoing control.If an editor provides the feature ofsystem command execution,as for instance,vim1or emacs2,a user limited bysudo to the utilization of this editor can use its command execution interface tosend system commands to the operating system.Sudo will not control this be-havior and the commands will be executed with the foreign privileges speciﬁedwithin the sudo conﬁguration for editor usage only.Further,as the identiﬁcationof programs and ﬁles is only possible by speciﬁcation of ﬁle names in the conﬁgu-ration ﬁle,sudo is vulnerable to attacks on these.E.g.considering a user allowedto run a certain trivial program with superuser privileges by appliance of sudo.In order to get superuser access to the system,the user would only need to getthe programﬁle replaced by another ﬁle containing a shell code.Sudo would not1http://www.vim.org/2http://www.gnu.org/software/emacs/213.3.The Superuserrealize this kind of fraud and consequently supply the user with a shell runningwith root’s superuser privileges.3.3.3 POSIX CapabilitiesPOSIX Capabilities describe a feature in order to split up superuser privileges inUnix operating systems.POSIX is an acronym for ”Portable Operating SystemInterface for Unix”,which is the name of a corresponding set of internationalstandards for Unix operating systems.POSIX Capabilities were part of the Linuxkernel since kernel version 2.2,yet the feature was limited to processes.In early2008,ﬁle system capabilities were additionally introduced within the Linux ker-nel version 2.6.24.The POSIX Capabilities describe a split up of superuser privileges operations intocertain fragments.Currently,32 capabilities can be applied to processes and ex-ecutable ﬁles,that describe certain privileged tasks.These are e.g.,to send akillkernel signal to foreign processes,change systemtime,reboot the system,changeof ownership,and rights of foreign owned ﬁles or to bind processes to privilegednetwork ports.A process carries a set of capabilities it is permitted to use at mostand another set deﬁning which capabilities are used effectively.The latter can bechanged by the process,yet needs to be a subset of the former.Whenever a pro-cess starts another new process,either its complete set of permitted capabilitiesor a freely speciﬁable subset of these capabilities is passed on.The functionality of the POSIX Capabilities’ ﬁle system feature is analogue tothe setuid bit.An executable ﬁle can be equipped with capabilities while the in-formation is stored in extended ﬁle attributes within the ﬁle system.Wheneverthe ﬁle is executed by a user,its running process has the speciﬁed capabilities.22Chapter 3.The Linux Operating System and the SuperuserConsequently,this can be seen as an extension or a partial replacement for thesetuid functionality.POSIX Capabilities offer a limited possibility to split up superuser privileges astheir functionality only comprises a small and ﬁxed set of hooks.Further,a pro-cess needs to possess all necessary capabilities while it is not possible to adapt aprocess’ effective set of privileges during run-time,or to enforce a certain behav-ior.Analogue to the utilization of the setuid bit attribute,ﬁle system capabilitiesare based on the accessibility of the corresponding ﬁles and it is not possible toindependently specify their users.3.3.4 ChrootThe command chroot allows to change the system’s root ﬁle systemto a speciﬁeddirectory [red],whereas the Linux kernel gets attached to an additional newrootﬁle system.The speciﬁed directory needs to include at least a partial copy ofa Linux installation functioning as a Linux root environment.The caller of thechroot command will end up in the new root ﬁle system environment,that isserving concurrently to its ancestor while sharing the Linux kernel.Linux systems use this technique during their boot up procedure.Thereby,theLinux kernel uses a given initial ramdisk ﬁle systemas its very ﬁrst root environ-ment.After initializing the storage devices a device and partition that is speciﬁedby kernel parameter as the system’s later root ﬁle system is mounted within theinitial root ﬁle system.The init process executes a chroot to the location of thenew root ﬁle system and initializes the user space.Chroot is generally utilizable in order to separate entities,yet this comes by thecost of additional storage space and maintenance for the additional root ﬁle sys-233.3.The Superusertems.Moreover,all potential root environments share the virtual ﬁle systems/proc and/sys and due to the sharing of the Linux kernel,the root users of allenvironments are identical at kernel level.3.3.5 ConclusionIn its standard form,the Linux operating system is fundamentally based on theusage of superuser privileges.By utilization of setuid,sudo,or POSIX Capabilitiesit is possible to allow normal users to run programs by utilization of other useraccounts including root.Thereby,sudo and POSIX Capabilities offer each a verylimited functionality to further restrict this utilization.The Chroot mechanism inLinux is a possibility to separate entities in the same system to a certain extent.Yet,this separation does not apply to superuser privileges.24Chapter 4.ITComp Clustered Data Services4 ITComp Clustered DataServicesThis chapter describes the application ITComp Clustered Data Services (CDS),anetwork storage application that is designed and developed within the scope ofcloud computing.4.1 IntroductionCDS is a decentralized high-performance network-attached storage (NAS) appli-cation,based on a clustered architecture following the approach of horizontalscaling.Along with the idea of cloud computing,CDS is intended to centralizeformerly separated technology into one massive system.More precisely,the goalis to integrate different storage applications into one system that is capable ofproviding these applications as different services.The difference of CDS to classical clustered NAS approaches is the utilizationof a single ﬁle systemnamespace that is apparent and accessible in parallel by all254.2.ITComp Very Large File Systemcluster nodes.This is accomplished by appliance of the ITComp Very Large FileSystem(VLFS) based on Storage Area Network (SAN) disk array storage devices.Currently,CDS supports only single-client installations,whereas the ﬁle system’saccess control is provided and maintained by an external directory service,suchas Microsoft Active Directory [Dia02].This thesis is based on the CDS version 1.2.3,which was released in March 2009.4.2 ITComp Very Large File SystemThe ITComp Very Large File System (VLFS) is a parallel,clustered ﬁle systemdesigned for high-performance demands such as supercomputers or large com-puting clusters.It allows to access clustered storage in parallel due to its ownproprietary distributed locking,journaling and replication mechanisms.Whereasthe concrete data and its meta data are stored together without appliance of acentralized meta data functionality in a SAN.A VLFS cluster is connected by aLocal Area Network (LAN) based on the Internet Protocol (IP) and is able tomaintain its own cluster management by dynamically designating nodes whilestill performing.Currently,IBM Advanced Interactive eXecutive (AIX),MicrosoftWindows and Linux operating systemenvironments are supported.Whereas thisthesis concerns the application of VLFS in CDS,it will only consider a scenariobased on Linux as a cluster environment.The VLFS cluster approach used within the application CDS is based on a Linuxenvironment while utilizing a shared-disc storage model in a SAN (Figure 4.1).Within the SAN,the VLFS cluster is connected with the storage units via FibreChannel,whereas the storage units are hard disk arrays.In a shared-disk model,all nodes in a cluster have equal access on all storage26Chapter 4.ITComp Clustered Data ServicesFigure 4.1:VLFS SAN Shared Disk Architecturedevices,thus each VLFS node has a full consistent view on the complete ﬁle sys-tems the cluster nodes are holding within the SAN.The VLFS software packages for Linux include a user space application with aserver program for cluster control and several kernel modules in order to inte-grate the ﬁle system and its functionality into the Linux kernel.By that kernelintegration,the VLFS ﬁle systems can be provided transparently over a virtual ﬁlesystemlayer and are accessible in Linux as native POSIX compatible ﬁle systems.4.3 ArchitectureConceptually,the ITComp CDS application cluster represents a redundant,high-performance NAS extension for a VLFS ﬁle system,accessible by different serviceprotocols.Accordingly,CDS as a complete system describes the interconnec-274.3.Architecturetion of Internet Protocol (IP) based LAN storage clients and SAN based storagedevices.Figure 4.2 shows the interconnection of the different system entitiesaround the CDS cluster.The application provides a NAS extension as a secondFigure 4.2:CDS Overviewclustered application,the Clustered Trivial Database (CTDB),on top of a VLFSﬁle system version 3.2.1 (see Figure 4.3).The CTDB manages parallel and con-current (see Section 4.3.1) accesses to the VLFS ﬁle system and is running next28Chapter 4.ITComp Clustered Data Servicesto the VLFS application on all CDS cluster nodes.Further,all cluster nodes arebased on a Red Hat Enterprise Linux (RHEL) version 5.Both clustered applica-Figure 4.3:CDS Cluster Architecturetions use a private LAN for communication,whereas a public LAN is utilized forthe services.Each of the equal CDS cluster nodes provides access to the clustersVLFS ﬁle system by Common Internet File System (CIFS),Network File System(NFS),Hypertext Transfer Protocol Secure (HTTPS),and File Transfer Protocol(FTP) services.All nodes,respectively the CDS cluster,utilize one directory serverfor addressing and access control (see Section 4.3.3).Finally,each CDS clusternode is accessible by the ITComp Backup Data Manager (BDM),a storage man-agement application (see Section 4.3.4).Figure 4.3 gives an overviewof all thesecomponents within a CDS cluster node.294.3.Architecture4.3.1 Clustered Trivial DatabaseThe Clustered Trivial Database (CTDB) is based on clustering efforts of theTriv-ial Database utilized by the unclustered NAS Linux application Samba1.Alongwith the approach of Samba,the CTDB is holding a database in order to storemeta data that is necessary to export POSIX ﬁle systems by CIFS,e.g.to Mi-crosoft Windows based NAS clients.The CTDB application cluster manages theparallel and concurrent accesses on the VLFS ﬁle systemby all available protocols(see Section 4.3.2).Beyond,it utilizes the VLFS ﬁle system to store informationabout its state within private ﬁles in order to coordinate the cluster.Further,the CTDB is responsible for fail over and recovery actions and load bal-ancing while performing.It enables the CDS cluster to change both device andcluster node infrastructure in a non-disruptive way.In case of a node failure,theCTDB is able to recover the lost connections by taking over the degraded node’sIP address to one of the remaining nodes while delaying the services data transfermomentarily and therefore protecting the clients utility and data.If nodes are reconnected or added to the cluster,the load is redistributed byusing the same functionality,whereas the CDS cluster follows an all-active de-sign.Consequently,the cluster utilizes all nodes in order to balance load andworks without spares.This seamless integration of nodes allows the cluster togrow bit by bit along with necessity while supporting the ability to be dynami-cally adjusted on demand.1http://www.samba.org30Chapter 4.ITComp Clustered Data Services4.3.2 ServicesEach CDS cluster node provides data access over the protocols CIFS,NFS,HTTPS,and FTP while utilizing the Directory Service in order to authenticate the ac-cesses.Thereby,CDS is based on the existing Linux applications Samba,NFS,Apache,and Vsftp (see Figure 4.3).The applications are adjusted in order to beorchestrated with the CTDB and the VLFS applications inside each one of theCDS cluster nodes.The application Samba provides the CIFS service and its appendant applicationWinbind supplies the corresponding connection of each CDS cluster node withthe Directory Service.The NFS service is supplied by the corresponding LinuxNFS server application,the Apache web server provides HTTPS accessibility andthe Vsftp server is responsible for FTP.4.3.3 Directory ServiceWithin the public LAN,a directory service is necessary in order to provide nam-ing services and network authentication for the CDS cluster (see Figure 4.2).This service has to offer identity management,central authorization,and accesscontrol.These responsibilities comply with a Microsoft Active Directory service,which is expected to be utilized.Yet,it is possible to supply the required func-tionality otherwise,as e.g.by appliance of separate open source systems.More precise,the CDS cluster requires a Domain Name Service (DNS) for namespace custody and address resolution and a Lightweight Directory Access Proto-col (LDAP) service in order to supply information about users and groups and toenable a centralized access control for CDS.Finally,a Kerberos [Bis03] Service314.4.Administrationsupplies network authentication and centralized authorization within the publicnetwork.4.3.4 Backup and ArchivingCDS enables the appliance of a storage management application,the ITCompBackup Data Manager (BDM).The application comprises information life-cyclemanagement features,as e.g.centralized and automated data archiving,andbackup and recovery features,whereas it is possible to utilize both disk and tapestorage devices.The storage management is maintained within an external computer system andis connected to the CDS cluster by a designated program running on every node.4.4 AdministrationWithin upcoming releases,CDS will employ an administration setting with a sep-arated standalone administration console (see Figure 4.2) that will communicatevia the Secure Shell (SSH) protocol with the CDS cluster.This administrationconsole will offer a graphical user interface over HTTPS and a command-lineinterface over SSH.The command-line interface will use a proprietary shell thataccepts only a limited,predeﬁned command set and consequently prevents an ad-ministrator fromarbitrary command execution,which normal Linux shells wouldoffer.Both the commands derived fromthe graphical user interface and the onesread fromthe command-line interface will be translated by the console into stan-dard Linux commands.These commands will be veriﬁed by syntax and elemen-32Chapter 4.ITComp Clustered Data Servicestary semantic checks and consequently submitted via SSH to a CDS cluster node,where they will be executed by the root user account.This utilization of the Linuxroot account should be avoided as outlined within the following chapters.Currently,CDS utilizes a cluster node in order to provide an administration inter-face by running a service application as a normal Linux process.The administra-tion interface is communicating internally via SSHby utilization of the Linux rootaccount and is accessible by graphical user interface and command-line interfaceas described above.This scenario is considered to be vulnerable,as e.g.failures or attacks on theadministration interface could interfere directly with the cluster responsibilitiesand will not be further discussed.4.5 Signed Software UpdatesIn order to impede the inﬁltration of malicious or ﬂawed software and to guar-antee the authenticity of software during install and updates of CDS,ITCompsupplies digitally signed software updates by appliance of the Yellow dog Up-dater Modiﬁed (YUM) [red].YUM is the package-management utility includedand utilized in the Red Hat Enterprise Linux Distribution.ITComp maintains itsown YUM repository,which consists of both update packages provided by RedHat and proprietary ITComp CDS packages.The integrity and authenticity of thepackages is assured by GNU Privacy Guard (GPG) public key certiﬁcates,whereasthe YUMpackage-management is provided with certiﬁcates during systeminstal-lation and invokes a veriﬁcation of each package that is about to be installed.334.6.Multi-Client Capability4.6 Multi-Client CapabilityAlong with the approach of Cloud Computing,multi-client capability is a featureheaded to be realized within future versions of CDS.Currently,it is not yet pos-sible to separate different clients within the same CDS installation while givingeach client a partial system view with sovereignty over its ﬁle systems and theﬁle system’s access control.Even if this feature is not even speciﬁed in detail,this thesis will account fora generic multi-client capability,whereas two aspects are adopted as a generalabstract requirement.At ﬁrst,the Linux operating systemas the basis of the CDScluster nodes needs to be capable of compartmentation.More precisely,it needsto be possible to partition the CDS storage service into areas that are protectedand shielded against mutual accesses,as e.g.by user groups or domains providedby the directory server.Secondly,in order to enable an independent administra-tion of each storage compartment or area,privileges for administration need tobe partitioned or decomposed as well along the layout of storage compartments.34Chapter 5.The Problem of the Linux SuperuserWhen I was a kid,one day I realized mysteriously markings on the car keys ofmy grandfather’s old light mint Audi.I retrieved a chair and grabbed all thekeys of the old wodden key board at the wall.I encountered two identical carkeys wearing different markings.Instantly,I questioned my grandfatherabout this dramatic ﬁnding.He explained me diligently one key would be anexclusive ignition key that could neither open the glove locker nor the trunk.As far as I can tell my grandfather never utilized a valet parking service,yethis car keys would have allowed himto do so.5 The Problemof theLinux SuperuserThis chapter formulates and describes seven problems arising from the existenceof DAC superuser privileges in Linux.The problems are derived and deﬁned in the face of an ITComp CDS clusterbased on a genuine Linux operating system.However,each of the problems isformulated as general as possible,since the underlying issues are assumed to ap-ply to a multitude of usage scenarios,concerning operating systems based on theappliance of DAC super privileges in service oriented environments or within thescope of cloud computing.The general problems will be translated into concreterequirements within the subsequent chapter.355.1.OmnipotenceAll problems are formulated while assuming a CDS cluster and its environmentis performing normally and with integrity,and accordingly excluding the caseof preceding foreign inﬂuence or attacks or a biased installation.Yet,personsentitled to utilize superuser privileges are not assumed to be necessarily candidor well-meaning,nor can human failure be excluded.Along with the idea of ahostile administrator and the principle of least privilege,the following problemsare intended to reason why superuser privileges denote a fundamental problemto the Linux operating system.5.1 OmnipotenceA system administrator that possesses superuser privileges in Linux can accessany kind of information and data represented in the corresponding computersystem.Furthermore,she has unconditional possibilities to compromise or sabo-tage the system and can delegate an arbitrary amount of its superuser privilegesto any other user present in the system.Thus,no user can protect her data fromaccess based on superuser privileges.This level of access is way beyond the principle of least privileges concerningthe administrator’s original function of system maintenance.In the face of ahostile administrator it means a drastic system threat as the potential impact ofsuccessful attacks needs to be assumed as paramount.36Chapter 5.The Problem of the Linux SuperuserProblem of Omnipotence:The Linux superuser represents a super set of allprivileges and has unconditional and illimitable power within the operatingsystem.Consequently,it constitutes a major violation of the principle of leastprivilege and a drastic system threat in the face of hostile or careless adminis-trators.5.2 ResistivenessSuperuser privileges own all entities in a Linux operating system at least by del-egation.This is observable e.g.during boot time or in the single user mode,where root is the only user account present and available in the operating sys-tem.Whereas,this root account does not differ fromthe one present during othersystem modes,respectively the multi-user mode.As superuser privileges are omnipresent and deﬁned to be omnipotent,their va-lidity spans even future introduced system entities and resources.Respectively,superuser privileges are not a ﬁxed amount but rather the maximumof privilegesby deﬁnition and are by deﬁnition always present in the system.Problemof Resistiveness:The omnipotence of superuser privileges in Linuxis immutable and resistant within time.375.3.Unavoidable Obtainment5.3 Unavoidable ObtainmentSince the menace of software ﬂaw exploitation or privilege escalation cannot becontrolled easily,superuser privileges represent a fundamental problem and adrastic threat for Linux systems beyond their delivery to authorized personnel.Also apart from hostile administrators,the impact of misuse of superuser privi-leges gained due to privilege escalation attacks needs to be estimated equally asparamount.Problem of Unavoidable Obtainment:As it is not possible to avoid poten-tial illegitimate obtainment of superuser privileges due to attacks,their simpleexistence constitutes a fundamental drastic threat.5.4 Cover-up AssistanceSuperuser privileges may be misused in order to hide,cover,or clean up attacksor malicious activities.Consulting the ﬁgure of speech ”opportunity makes thethief”,the opportunity may be both the fact of getting access to a property andthe expected chance to run away after making an achievement without beingcaught.An example of this facet is an administrator that even with a least privilege levelof access may have possibilities that are highly exploitable in a malicious way.Yet,a difference to a case with possessing of superuser privileges may be thechances to hide the unauthorized actions and to get away successfully with thebeneﬁt.Another aspect concerns attacks that last a certain time period,whereasthe action of hiding is an integral part of the attack itself,as e.g.rootkits.38Chapter 5.The Problem of the Linux SuperuserConsequently,it is possible to distinguish two forms of covering up an attack.While on the one hand,the cover-up is crucial for the technical success of theattack,on the other hand,it is crucial with respect to the success of the attacker.Problem of Cover-up Assistance:Superuser privileges enable to hide ongo-ing attacks,to clean up and cover tracks,and to wipe out evidence.5.5 Undermined ConﬁdentialityIn otherwise fully encrypted or protected environments,Linux systems with su-peruser privileges,that are processing unencrypted data,dominate the overalllevel of conﬁdentiality by their level of system security.More precisely,supe-ruser privileges,in Linux systems working with unencrypted data,abandon anyachievement made elsewhere in the environment through the use of encryptionor protection,since their access regarding the unencrypted data is not conﬁne-able.Thus,the existence of superuser privileges in Linux undermines conﬁden-tiality.Linux systems processing unencrypted data within subsystems like separated pro-grams,compartments,or virtual hosts which share the systemin a transparent orvisible way are highly vulnerable to covert channel attacks.This situation can beexploited at least by utilization of superuser privileges.Even though it is not pos-sible to eliminate any kind of covert channels in systems based on interference(see Section 2.3.5),superuser privileges can not only lead to the total loss overthe control of a system,but as well to the total loss of data.395.6.Unfeasible CompartmentationProblemof Undermined Conﬁdentiality:Superuser privileges foil and un-dermine conﬁdentiality gained in an environment from encryption or protec-tion,if the corresponding system has access on decrypted data.Beyond,su-peruser privileges support or even enable the establishment of covert channelsbetween subsystems that share a Linux system.5.6 Unfeasible CompartmentationIn Linux systems that are hosting subsystems like e.g.chroot environments,su-peruser privileges apply unhindered to these subsystems.Regardless how theyare obtained,superuser privileges in a Linux system can control,compromise orsabotage subsystems that share the same Linux kernel.Therefore,it is not possi-ble to protect entities within a Linux system from superuser privileges,which isa direct consequence of their omnipotence (see Section 5.1).Problemof Unfeasible Compartmentation:Linux superuser privileges can-not be divided or split up in order to be valid only within the borders of systemcompartments or subsystems.Thus,it is not possible to protect entities fromsuperuser access within a Linux system.40Chapter 5.The Problem of the Linux Superuser5.7 Degraded ComplianceIn the scope of distributed applications and computing,the potential enforcementof policies concerning e.g.data processing,security measures,or access control isa general functional requirement.As DAC based Linux systems cannot delimitatetheir superuser privileges,they are not able to comply with such requirements.Problem of Degraded Compliance:The existence of superuser privilegesrepresents a hindrance to the introduction and enforcement of mandatory se-curity or access control policies within the operating system Linux.415.7.Degraded Compliance42Chapter 6.Requirements to Secure the CDS Cluster6 Requirements to Securethe CDS ClusterThis chapter describes the fundamental prerequisites and requirements of theapplication CDS with respect to a security enhancement based on the problemsoutlined in Chapter 5.After deﬁning the security goals for the application CDS and its administration,a scenario is presented in order to subsequently derive requirements for a solu-tion.Finally,the chapter outlines the speciﬁcation of an exemplary role designconcerning the administration of CDS.6.1 Security Goals of CDSRegarding the data stored and processed within the application CDS and its func-tion as a data storage service,the general security goals are conﬁdentiality,in-tegrity,and availability.Moreover,concerning the application as a distributedservice the communications between all application entities as well as all inter-actions of users are required to comply with authenticity.436.2.Prerequisites and DependenciesConcerning the access and activity of system administration,the communica-tion between the administrator and the CDS cluster nodes needs to conformwiththe goals conﬁdentiality,integrity,availability,and authenticity.Moreover,theadministrator needs to prove her identity during the process of authorization.6.2 Prerequisites and DependenciesIn order to assess the requirements for a security enhanced CDS cluster with re-spect to superuser privileges,the application CDS is divided into three zones (seeFigure 6.1),which are expected to comply with certain conditions and prerequi-sites.The CDS cluster,its complete SAN including the storage devices,and the privateLAN are assumed as a protected zone (highlighted in green in Figure 6.1) withinthe application CDS.A potential interference or attack in this zone is assumedto have paramount impact and undermines any control or security potentiallysupplied by CDS cluster.This concerns not only the SAN as the applications stor-age platform,but as well the private LAN as the clusters internal communicationmedia.Consequently,the complete SAN including the storage devices and theprivate LAN are explicitly demanded to reside in a physically protected area (seeSection 6.4.7).The zone represented by the public LAN (highlighted in orange in Figure 6.1)is assumed as generally insecure and a priori open to attacks,as all its entitiesare directly accessible at least by all participants of the application CDS.Yet,withrespect to the ongoing assessment the only considered attacking scenarios arebased upon superuser privileges as represented by the seven problems describedin Chapter 5.Accordingly,all communicating entities apart from the CDS cluster44Chapter 6.Requirements to Secure the CDS ClusterFigure 6.1:CDS Protection Scenario Overviewnodes are considered to be neither attacked nor biased and working properly bydeﬁnition.Beyond,attacks within the network infrastructure of the public LANare excluded from the analysis.Moreover,concerning the activity of administration,the utilized SSH protocoland applications are assumed to generally sufﬁce the deﬁned security goals,asthe communicating computer systems are authentic,the communication is en-456.3.CDS Cluster Requirementscrypted,respects both conﬁdentiality and integrity,and the user is required toauthenticate herself by knowledge of a password or the possession of a key.6.3 CDS Cluster RequirementsIn order to assess security mechanisms as potential solutions to the outlined prob-lems in Chapter 5,the problems need to be translated ﬁrst into criteria reﬂectingconcrete requirements with respect to the underlying security goals.The criteriaand their underlying problems are listed as follows:1.Conﬁning the threat of privilege escalations and attacks based on superuserprivileges (Problem of Unavoidable Obtainment).2.Providing the possibility of dis-activation or extinction of superuser privi-leges in Linux (Problem of Resistiveness).3.Offering methods to decompose superuser privileges along a role design,asfor instance the role design presented in Section 6.4 (Problem of Omnipo-tence).4.Supplying methods to introduce and enforce mandatory access control poli-cies that exceed the competencies of all users.The policies need to be bothadaptable and analyzable (Problem of Degraded Compliance).5.The introduced mandatory access control policies need to be analyzable re-garding the information ﬂow and covert channels within the system(Prob-lem of Undermined Conﬁdentiality).46Chapter 6.Requirements to Secure the CDS Cluster6.Providing a tamper-proof logging facility that is capable of giving detailedinformation based on the speciﬁed access control policy (Problem of Cover-up Assistance).7.Supplying methods within the mandatory access control policies to limitthe access of entities regarding a general multi-client capability (Problem ofUnfeasible Compartmentation).Finally,a general criterion that is crucial,but will not be adopted as a functionalrequirement,concerns a potential inﬂuence on the performance of the CDS clus-ter.6.4 A Role Design for AdministrationThe following seven sections present an exemplary role design in order todemonstrate a decomposition of superuser privileges with respect to the adminis-trative responsibilities within CDS.Each role is speciﬁed in an abstract,enumer-ating its function or utility,its view on the system and the system’s data,and itsprivileges.The abstract is followed by a brief description of each role.The system needs to enforce users to have only one active role at a time.Thus,even if one administrator is allowed to use all roles,the effective level of privi-leges at a given time is never provided by more than one role.476.4.A Role Design for Administration6.4.1 Analysis and Reporting Role• Function:Statistics,Logging,and Error Detection• View:Abstract System Information and Meta data• Privileges:System Information Processing and Error SubmissionThis role is responsible for the processing of system statistics,analysis of thesystem’s state,logging maintenance,and error detection.Potential system errorsare assumed to be relayed to the System Maintenance Role described in Section6.4.5.6.4.2 Access Management Role• Function:Add,Delete,and Modify System Users• View:User Meta Data• Privileges:Access to User Management and Meta DataThis role is responsible for the maintenance of the directory service.As the NFSservice utilizes its own access control mechanism based on ﬁxed IP addresses forsubject identiﬁcation,the role has also privileges to trigger these mechanismswithin the CDS cluster.Nevertheless,the role may only access the meta dataconcerning the user authorization and identiﬁcation in both the directory serviceand the CDS cluster.48Chapter 6.Requirements to Secure the CDS Cluster6.4.3 Service Management Role• Function:Add,Delete,and Modify the System’s Storage Conﬁguration• View:Exported Storage Resources and Conﬁguration• Privileges:Service Conﬁguration and Exported Storage LayoutIn order to manage the CDS cluster’s service side,this role is associated with theinternal CTDB application.The privileges comprise the control of the differentservices and the exported storage areas.Regarding a future multi-client capability in CDS,this role along with the Ac-cess Management Role will exist for each client present in the system.6.4.4 Resource Management Role• Function:Add,Delete,and Modify the System’s Storage Conﬁguration• View:Internal Storage Resources and Conﬁguration• Privileges:Modify Storage Conﬁguration and LayoutThis role is designed as the counterpart to the Service Management Role and isresponsible for the conﬁguration of the VLFS storage system.496.4.A Role Design for Administration6.4.5 System Maintenance Role• Function:Error Handling and System Software Updates• View:System Health and Software Status• Privileges:System Interference through deﬁned ProceduresIn order to guarantee the integrity of the CDS cluster,only this role has the privi-leges to change the cluster’s installation and to upgrade or update software pack-ages.Further,the role has the capability of processing system errors by prede-ﬁned procedures.6.4.6 Data Management Role• Function:Backup and Archiving• View:Access on Data and Meta data• Privileges:Data accessAs the ITComp Backup Data Manager (BDM) has a direct access to the CDScluster,this role has read and write access on ﬁles and directories.The accessneeds to be limited to the VLFS ﬁle system and the interconnection between theCDS cluster and the external BDMsystem.50Chapter 6.Requirements to Secure the CDS Cluster6.4.7 Remaining Privileged Access• Utility:Emergency Intervention• View:Unconﬁned system view• Privileges:Superuser privilegesThe availability of a remaining privileged access is reasonable,as it is demandedand required in severe or fatal error,or in emergency situations.As the CDS clus-ter is exposed to physical access,a highly privileged or superuser access linked tophysical access describes no additional threat.Consequently,a reasonable imple-mentation of this access is the involvement of a physical intervention procedure,for instance,the usage of hardware tokens.Another additional or optional ap-proach is the appliance of secret sharing [Buc04].Before administrative intervention,the CDS cluster needs to designate a nodeto switch into a service mode and consequently remain only a passive member ofthe cluster.In this mode the node should be accessible by an exclusive interface,as e.g.a ssh server bound to a proprietary network port.After the administrativeintervention,the node needs to switch back into normal operation and becomeagain an active member of the cluster.Thereupon,the changes triggered by theadministrative intervention become propagated to all other cluster nodes.An approach that conditions the opportunity of superuser access solely to a lo-cal Linux terminal is assumed to be insecure and generally not recommended.As local terminals based on keyboard and screen interactions can be redirectedinto networks by special devices,this approach could be exploited to circumventphysical access.516.4.A Role Design for Administration52Chapter 7.Mechanisms to Conﬁne the Linux Superuser7 Mechanisms to Conﬁnethe Linux SuperuserThis chapter brieﬂy describes four known Linux security extensions and analyzesinformally their technical quality and capability with respect to to the criteria de-scribed in Section 6.3.Beyond,these criteria applied as functional requirements,the analysis accounts also for each extensions development background,its adop-tion and insertion in the scope of existing Linux distributions and the availabilityof commercial support and warranty.The latter is of crucial signiﬁcance,sincetwo mechanisms involve to patch the Linux kernel source and consequently tobuild custom kernels.ITComp CDS runs on a Red Hat Enterprise Linux and it is based on Red Hat’sproduct support and warranty.As the utilization of a custom Linux kernel isnot covered by Red Hat’s support and warranty,this is a major non-functionaldrawback.537.1.Linux Security Modules7.1 Linux Security ModulesLinux Security Modules (LSM) is a security framework that is part of the LinuxKernel since version 2.6.Its development was motivated by the demand of Li-nus Trovalds to enable Linux to utilize different security mechanisms and accesscontrol implementations and make it unnecessary to further change the kernel[WCS+02].Due to the framework,it is possible to load security mechanisms asLinux kernel modules.Figure 7.1:LSMHook Architecture - Source:[WCS+02]The framework provides an interface for a security mechanism to hook into theLinux access control decisions,whereas access requests are intercepted in or-der to include the additional access control logic introduced by the new securitymechanism (see Figure 7.1).Thereby,the original Linux access decisions can beeither combined with or overruled by the new mechanism.54Chapter 7.Mechanisms to Conﬁne the Linux Superuser7.2 AppArmorAppArmor is a security extension that allows to protect certain processes in Linux.The extension is maintained and developed by the company Novell under theGNU General Public License (GPL).AppArmor is included in the Novell Linux dis-tributions SUSE Linux Enterprise Server (SLES) and SUSE Linux Enterprise Desktop(SLED) and is covered by operating system’s support and warranty.The protection offered by AppArmor is reduced to a set of certain programs andconsequently the mechanism separates the Linux system into conﬁned and un-conﬁned processes.The informal idea behind this approach is to secure a set ofprograms which are estimated to be highly vulnerable,such as web browsers ore-mail clients while minimally interfering with the user.AppArmor utilizes the Linux Security Modules interface for intercepting accesscontrol decisions and genuine ﬁle names in order to identify ﬁles.Its rule set isrepresented by a policy,which is composed by a set of modules.The mechanismprovides a given set of modules that can be conﬁgured and further adjusted byend users.Beyond,it is possible for users to assemble newmodules by utilizationof a graphical interface.In the face of the criteria described in Section 6.3,AppArmor is completely un-suited to be utilized in order to make up a solution.It provides no possibility toenforce a general default deny directive and it is not equipped in order to protector conﬁne an entire Linux system.Hence,it is not possible to reason clearly aboutthe extent of achievable security.Further,it provides no mechanism to conﬁnethe Linux root account.Finally,the identiﬁcation of ﬁles by their ﬁle names inthe face of AppArmor’s limited protection scenario is highly questionable,sinceﬁle names might be easily altered.557.3.Grsecurity7.3 GrsecurityThe Grsecurity package is a composition of Linux kernel patches combined witha small set of control programs licensed under the GPL.The primal focus of thepackage is to harden certain known vulnerabilities in the Linux system while es-pecially focusing on privilege escalation and root exploits.The project started in2001,and according to the extensions website (http://www.gresecurity.org) thereis only one contact person,which is also the author of all primary documenta-tion.The extension includes an independent standalone set of patches namedPaX,which supplies memory address space protection and randomization.PaXis also licensed under GPL and developed by an independent developer team,whereas the original author is anonymous.Grsecurity provides a MAC mechanismbased on ACL and RBAC capabilities com-bined with trusted path execution,that allows to limit the right of program ex-ecutions to certain speciﬁed ﬁle names.The set of patches comprises protectionmechanisms for ﬁle systems,executables and networks and additional kernel log-ging features.Grsecurity enables e.g.to harden the chroot environment againstcertain known attacks,prevent unprivileged users from reading kernel informa-tion and is able to limit and isolate the operating system’s process view.Further,also anticipatory counteractive measures are possible,as e.g.to erase the TCPﬁngerprint of a Linux system in order to prevent attackers fromgaining informa-tion about the running operating system in order to particularize an attack.Informally,the concept of Grsecurity can be described as the intention to hardenthe Linux operating systemand its proprietary mechanisms while restraining sys-tementities like users and processes.Accordingly,the underlying idea is not onlyto place additional logic aside of the genuine Linux kernel,but also to alter thekernel’s own mechanisms to comply with the desired behavior.Yet,Grsecuritydoes not follow any formal model of security,but emerged as a composition of56Chapter 7.Mechanisms to Conﬁne the Linux Superusercountermeasures against several known weaknesses,vulnerabilities,or concreteattacks.Grsecurity has only little acceptance within available Linux distributions and itis not adopted by any major Linux distribution as a standard mechanism.Sincethe majority of conﬁguration options needs to be done directly in the Linux ker-nel source,there are also no pre-built Linux kernels available.Consequently,theextension is not included in any commercial Linux distribution’s support or war-ranty.Froma functional perspective,Grsecurity is not a convenient mechanismto meetthe requirements represented in Section 6.3.It lacks a general systematic ap-proach or model,which makes it difﬁcult to meet predeﬁned security goals.Many features can only be generally activated without further qualiﬁcation ordependence on e.g.users,programs,or certain conditions.Further,the exten-sion offers no mechanisms to analyze or reason about the achievement emergingfrom its application.7.4 RSBACA Linux security extension called Rule Set Based Access Control (RSBAC) is basedon an idea for a general security framework named the Generalized Frameworkfor Access Control (GFAC) [ALEO90].RSBAC was started out of a diploma thesisat the University of Hamburg and according to the project’s website(http://www.rsbac.org) the development is still lead by its originator.The exten-sion is licensed under the GPL and had its ﬁrst stable release in the year 2000.The underlying framework is integrated into the Linux kernel as a patch,in-577.4.RSBACtercepts system calls to hook into access decisions during run-time,and providesan interface for registration of so called decision modules.It is possible to ac-tivate multiple modules simultaneously,whereas in that case,all modules haveto approve on an access decision in order to lead to an actual access permission.Amongst others,the decision modules included in RSBAC provide a hardeneduser management,restrictable authorizations,advanced audit features and capa-bility of pseudonymous logging,a jail module in order to conﬁne programs,anda root-user protected ACL implementation.Furthermore,RSBAC comes with amodule called Role Compability that follows the model described in [OFH01].Within the Role Compability module it is possible to deﬁne roles as subjects as-sociated with certain amounts of privileges.Users are entitled to use a speciﬁedset of roles,whereas they have default roles and can only use one role at a time.Objects of access,such as ﬁles,directories,inter process calls,or network devicesare organized into groups of so called types.A rule set deﬁnes for each role whichtypes may be accessed in what way analogue to the concept of ACL.Like Grsecurity,RSBAC is not utilized as a standard mechanism by any ma-jor Linux distribution and it is necessary to alter the Linux kernel source andbuild a custom Linux kernel in order to utilize the extension.As mentioned be-fore,this would have major consequences in the face of product support by e.g.Red Hat.Consequently,commercial support and warranty is only available fromthird-party companies.By combination of the Role Compability and other available decision modules,the capabilities offered by RSBAC nearly sufﬁce the requirements described inSection 6.3.However,RSBAC cannot provide a method to build a rule set in acentralized and integrated manner and there are no known tools or mechanismsto support the analysis of its policies.The extension provides guided conﬁgura-tion by setting of options according to standard use cases,such as service encap-sulation.Yet,this imprecise concept of adjustment and the absence of analysis58Chapter 7.Mechanisms to Conﬁne the Linux Superusertools for the rule set limit the extensions applicability in the face of a complexusage scenarios as the matter in hand.7.5 SELinuxSecurity-Enhanced Linux (SELinux) is a security systemthat is strongly inﬂuencedby the U.S.National Security Agency,which released the code of its early versionsin the year 2000 under the GPL.Whereas at ﬁrst,the kernel source needed to bepatched,SELinux could be used with the mainline Linux kernel due to utilizationof the Linux Security Modules interface by the end of 2003.In 2007,RHEL version 5 became certiﬁed [rhe07] under the Common Criteriafor Information Technology Security Evaluation CC [com06],an internationalstandard for computer security certiﬁcation,by appliance of SELinux as a MACand RBAC mechanism in Linux.The certiﬁcation stated the operating system tobe above the Evaluation Assurance Level 4 (EAL4),which is described as ”me-thodically designed,tested,and reviewed” [com07].Currently,the development is driven by the companies Tresys Technology andRed Hat.SELinux is today part of or available for the mainline distribution re-leases of Debian,Gentoo,Fedora,and Ubuntu,was recently introduced into SUSELinux,and is a mature standard component of the Red Hat Enterprise Linux.Con-sequently,it is covered and actively maintained by the Red Hat product supportand warranty.The design of SELinux follows the idea of the Flux Advanced Security Kernel(FLASK) architecture that describes the ﬂexibility of diverse security policies[SS+99].Depending on the utilized policy,SELinux is able to follow a default597.5.SELinuxdeny directive and consequently protect a complete Linux system,but also tolimit the protection to only selected programs.The actual policies are developedindependently,formulated in a policy language that was designed especially forSELinux,and are getting deployed as a compiled piece of source code.Due to itsmodularized policy layout,it is possible to independently change existing mod-ules or to develop new modules based on an existing policy.SELinux is an implementation of the Type Enforcement approach that suppliesa MAC mechanism while combined with additional RBAC capabilities.The pol-icy language contains both Type Enforcement and RBAC logic and beyond,sup-plies constraints that can be used in order to formulate assertions,whereas theseconstraints dominate the remaining parts of the security policy.Finally,SELinuxpolicies can be analyzed concerning information ﬂow and covert channels.The capabilities of SELinux are considered to fully comply with the requirementsdelineated in Section 6.3.By appliance of SELinux it is possible,to conﬁne theavailability of the Linux superuser root to certain conditions.A Linux system isprotectable as a whole and the policies can be enforced while overruling supe-ruser privileges.Privilege escalations and attacks are limited along the toleranceof the employed policy,whereas the systemsupplies a logging facility that reﬂectspotential violations.Moreover,it is possible to realize a role design due to thecapabilities of RBAC.Finally,SELinux policies are analyzable regarding informa-tion ﬂow and covert channels.Although,the SELinux policy is highly complex,its systematic and mature design enables to develop an access control rule set ina goal-oriented and methodical manner.60Chapter 8.SELinux in Detail8 SELinux in DetailThis chapter describes the functionality and architecture of SELinux in detail anddelineates its realization of Type Enforcement and the creation of roles.The MLSpolicy is discussed shortly,followed by a description of the SELinux ReferencePolicy and an outline of SELinux policy analysis.8.1 Architecture and FunctionalityAlong with the FLASK architecture,the SELinux mechanism consists of two con-ceptional entities,the Object Manager and the Security Server (see Figure 8.1).Whereas,the Object Manager is responsible for the brokerage of access requestsand the enforcement of access decisions,the Security Server has to make the ac-tual decisions by utilization of a rule set called the Security Policy.Together thesetwo components constitute a reference monitor.Beyond that,SELinux introduces a cache component between the Object Man-ager and the Security Server called the Access Vector Cache (AVC),which handlesall communications between the two entities.During system run-time,the AVCstores an amount of derived access decisions that have been requested by the618.1.Architecture and FunctionalityFigure 8.1:SELinux Architecture according to FLASK - Source:[SS+99]Object Manager before.Due to the cache,recurring identical requests may behandled without deriving a decision anew within the Security Server componentand accordingly accelerating the SELinux invocation as a whole.SELinux offers several options concerning the logging of its access control ac-tivity.By declaration of rules it is possible to log all accesses requested by theObject Manager,only requests denied by the Security Server,or speciﬁc subsetsof one of these cases.The log entries will be produced directly by the AVC and thelog ﬁles along with all entities of SELinux within the Linux operating system arespecially protected against any kinds of accesses,including privileged accesses.Currently,SELinux supplies three different policy types,whereas each can becompiled and deployed as a monolithic or a modularized policy.Within the later,the policy is divided into a core unit called the base module and dynamically loadand unload-able modules,which can be developed and deployed independently.The base module comprises the components responsible for the Linux core fea-tures while the modules on top represent the Linux user-space programs (seeSection 8.5).62Chapter 8.SELinux in DetailThe three available standard policies for SELinux are all based on the approach ofType Enforcement while additionally supplying RBAC mechanisms.The policiesare listed below:Targeted PolicyThe targeted policy conﬁnes only certain parts of the system.The fundamental