Analyzing and Comparing the Protection Quality of Security Enhanced Operating Systems

Hong Chen Ninghui Li Ziqing Mao Center for Education and Research in Information Assurance and Security and Department of Computer Science, Purdue University {chen131, ninghui, zmao}@cs.purdue.edu

Abstract been a number of efforts aiming at adding some form of (MAC) to Commercial- Host compromise is a serious computer security Off-The-Shelf (COTS) operating systems. Examples in- problem today. To better protect hosts, several Manda- clude Low Water-Mark Access Control (LOMAC) [6, tory Access Control systems, such as Security Enhanced 7], Security Enhanced (SELinux) [19], AppAr- Linux (SELinux) and AppArmor, have been introduced. mor [5, 1], and Usable Mandatory Integrity Protection In this paper we propose an approach to analyze and (UMIP) [16]. Some of these systems have been widely compare the quality of protection offered by the poli- deployed. For example, SELinux is supported in a num- cies of different mechanisms. We introduce the notion ber of Linux distributions, including Fedora, , of vulnerability surfaces under attack scenarios as the Gentoo, EnGarde and [3], and AppArmor is sup- measurement of protection quality, and implement a tool ported in Linux distributions including SUSE, PLD, Par- called VulSAN for analyzing and comparing protection dus Linux, Annvix, Ubuntu and Mandriva [2]. quality of these MAC systems for Linux. In VulSAN, Given the existence of these protection systems, a we encode security policies, system states, and system natural desire is to understand and compare the qual- rules using logic programs. Given an attack scenario, ity of protection (QoP) offered by them. A system ad- VulSAN computes a host attack graph and the vulner- ministrator would want to know the QoP offered by the ability surface. We apply our approach to compare MAC system he is using. Note that by an MAC system, SELinux and AppArmor policies in several Linux dis- we mean both the mechanism (e.g., SELinux or AppAr- tributions and discuss the results. Our tool can also be mor) and the specific policy being used in the system, used by Linux system administrators as a system hard- because the QoP is determined by both. More specif- ening tool. Because of its ability to analyze SELinux as ically, it would be very useful for an administrator to well as AppArmor policies, it can be used for most en- know: What kinds of attacks are prevented by the MAC terprise Linux distributions and home user distributions. system my host is using? What does it take for an at- tacker to penetrate the defense of the system, e.g., to install a rootkit on my host? Can the attacker leave a Trojan horse program on my host such that when the 1 Introduction program is later accidentally executed by a user, my host is taken over by the attacker? Would it be more secure if I use a competing distribution which has a different Host compromise is one of the most serious computer MAC mechanism or different MAC policy? security problems today. A key reason why hosts can be easily compromised is that the Discretionary Access In this paper, we develop a tool called Vulnerability Control (DAC) mechanism in today’s operating systems Surface ANalyzer (VulSAN) for answering these ques- is vulnerable to Trojan horses and the exploitation of tions. We analyze the QoP by measuring the vulnera- buggy software. Recognizing this limitation of exist- bility surface for attack scenarios. An attack scenario is ing DAC mechanisms, in the past decade there have defined by an attack objective and the attacker’s initial resources. For example, “remote to full control” is an eral Linux distributions with SELinux and AppArmor. attack scenario in which a remote attacker wants to fully Comparing the default policies of SELinux and AppAr- control the system. Other attack scenarios can be “re- mor for the same Linux distribution (namely Ubuntu mote to leaving a trojan”, “local to full control”, etc. A 8.04 Server Edition), we find that AppArmor offers vulnerability surface of a system is a list of minimal at- significantly smaller vulnerability surface, while the tack paths. Each attack path consists of a set of programs SELinux policy with Ubuntu 8.04 offers only slightly such that by compromising those programs the attack smaller vulnerability surface compared with the case scenario can be realized. Vulnerability surface is related when no MAC is used. More specifically, when no MAC to attack surface [11] which is a concept in Microsoft is used, the system has seven length-1 attack paths in Security Development Lifecycle (SDL). Attack surface the scenario when a remote attacker wants to install a uses the resources that might be used to attack a system rootkit. They correspond to the seven network-facing to measure the attackability of the system (details are daemon programs running as root, namely apache2, discussed in Section 2). They are different in that vulner- cupsd, nmbd, rpc.mountd, smbd, sshd, and vsftpd. ability surface provides potential multi-step attack paths Among them, the SELinux policy confines only cupsd. of a system while attack surface considers potential en- This shows that the often claimed strong protection of trypoints of attacks. VulSAN computes the vulnerability SELinux is not realized, at least in some popular Linux surfaces for attack scenarios under SELinux and AppAr- distributions. We also note policies in different distribu- mor. VulSAN encodes the MAC policy, the DAC policy tions offer different levels of protection even when they and the state of the host into Prolog facts, and generates use the same mechanism. For example, the SELinux a host attack graph for each attack scenario, from which policy in Fedora 8, which is a version of the targeted it generates minimal attack paths which constitute the policy, offers tighter protection than that in Ubuntu 8.04, vulnerability surface. which is a version of the reference policy. We also VulSAN can be used by Linux system administrators observe that Ubuntu 8.04 and SUSE Linux Enterprise as a system hardening tool. A system administrator can Server 10 expose different vulnerability surfaces when use VulSAN to compute the host attack graphs for at- they both use AppArmor. Also, one attack scenario that tack scenarios that are of concern. By analyzing these neither SELinux nor AppArmor offers strong protection graphs, the administrator can try to harden the system by is when a remote attacker leaves a malicious executable tweaking the system and policy configurations. For ex- program somewhere in the system and waits for it to be ample, the administrator can disable some network dea- accidentally executed by users, at which point the pro- mon programs, remove some unnecessary setuid-root cess would not be confined by the MAC system. This programs, or tweak the MAC (SELinux or AppArmor) attack is possible for two reasons. First, both SELinux policies to better confine these programs. After mak- and AppArmor confine only a subset of the known pro- ing these changes, the system administrator can re-run grams and leave any program not explicitly identified as the analysis to see whether it achieves the desired objec- unconfined. Second, as neither SELinux nor AppArmor tive. Because VulSAN uses intermediate representation performs information flow tracking, the system cannot of the system state and policy, it is possible to make the tell a program left by a remote attacker from one origi- changes in the representation and to perform analysis, nally in the system. before actually deploying the changes to the real system. The rest of the paper is organized as follows: Sec- Because VulSAN can handle both SELinux and AppAr- tion 2 presents the background and related work. Sec- mor, which are the two MAC systems used by major tion 3 discusses our analysis approach. Section 4 talks Linux distributions, it can be used for most enterprise about the implementation of VulSAN. Section 5 presents Linux distributions and home user distributions. the results of comparing SELinux with AppArmor in VulSAN can also be used to compare the QoP of poli- several Linux distributions. Section 6 concludes the pa- cies between different systems. Such comparison helps per. system hardening. If an administrator knows that an- other Linux distribution with the same services does not 2 Background and Related Work have a particular vulnerability path, then the administra- tor knows that it is possible to remove such a path while Security-Enhanced Linux [19] (SELinux) is a secu- providing the necessary services, and can invest the time rity mechanism in Linux that has been developed to sup- and effort to do so. port a wide range of security policies. SELinux has been We have applied VulSAN to analyze the QoP of sev- integrated into since 2.6. In SELinux, ev- ery process has a domain and every object has a type. policy, and was used to verify that the SELinux MLS ref- Objects are categorized into object security classes, such erence policy satisfies the simple security property and as files, folders, sockets, etc. A set of operations are de- the *-property defined by Bell and LaPadula [4]. fined over each object security class (e.g., read, write, Our work is different in the following ways. First, execute, lock, create, rename, etc for a file). A SELinux VulSAN supports analyzing AppArmor in addition to policy defines processes of which domains can access SELinux. Second, VulSAN utilizes the current system objects of which types with which operations. A policy state (such as which files exist in the system) as well as also defines how to determine the domain of a process DAC policies (such as which users can write to a file and how the domain changes when a process executes according to the DAC permission bits) in addition to another program. the MAC policies. As shown in Section 5.2, consider- AppArmor [1] is an access control system that con- ing DAC is necessary to obtain accurate analysis results. fines the access permissions on a per program basis. It Third, our goal, which is to compute the vulnerability confines programs that are likely to be attacked, e.g., surface under different attack scenarios, is different from server programs that face network and setuid root pro- that of existing tools. In particular we need to be con- grams. For every protected program, AppArmor defines cerned with more than just providing a policy analysis a program profile. A profile is a list of permitted ac- tool; we need to also come up with appropriate ways of cesses, including file accesses and capabilities. The pro- querying the tool and analyzing the result. files of all protected programs constitute an AppArmor Comparing the QoP offered by different systems is policy. If a program does not have a profile, it is by de- challenging because different policy models are used. fault not confined. If a program has a profile, it only has For example, SELinux uses Type Enforcement (TE), and permissions specified in the profile. AppArmor confines security-critical programs with pro- Previous approaches for analyzing SELinux security files. Currently there exists no tool to compare the secu- policies include Gokyo [14, 13], SLAT [8], PAL [21], rity of systems protected using different technologies. APOL [24, 10], SELAC [25], NETRA [18], and There is an ongoing debate about which of SELinux PALMS [9]. Gokyo [14, 13] identifies a set of domains and AppArmor is a better system, but such debate often and types as the implicit Trusted Computing Base (TCB) centers on the mechanism and lacks actual comparison of a SELinux policy. Integrity of the TCB holds if no of the security offered by the standard policies shipped type in it can be written by a domain outside the TCB. with these protection systems. As a result, such com- SLAT [8] verifies if a SELinux policy satisfies certain parison tends to become rhetoric wars. In [15] Cowan information flow goals. It answers questions such as: from and Riek from Red Hat debated about us- Is it true that all information flow paths in a system ability, simplicity, and policy implementation (labels vs. from a starting security context to a final security con- pathnames) between AppArmor and SELinux. QoP is text go through a series of specific steps? PAL [21] pro- not discussed in details. We believe that comparisons vides similar functionalities to SLAT. It differs in that involving actual deployed policies are necessary. It may it is implemented in XSB, a logic programming sys- be theoretically possible to configure a MAC system to tem. This enables PAL to handle other kinds of queries. offer very strong protection, but it is the shipped stan- APOL [24] is a tool to analyze the relationships between dard policy that determines the QoP in reality, since very domains and types in a SELinux policy. In [10] the au- few people change the shipped policy. In our approach, thors augment APOL to find paths from susceptible do- we perform a concrete measurement of QoP for both mains to security sensitive domains. The selection of mechanisms using shipped policies. susceptible and security sensitive domains is manually Attack surface is proposed as a metric to measure the done. The query language is less flexible than SLAT or attackability of a system [11, 12]: “The attack surface of PAL, but it provides a graphical user interface to display an app is the union of code, interfaces, services, proto- the results. SELAC [] is a formal model to describe the cols, and practices available to all users, with a strong fo- semantics of a SELinux policy. The authors develop an cus on what is accessible to unauthenticated users.” The algorithm based on SELAC to verify if a given subject heuristic is that a larger attack surface indicates a less can access a given object in a given mode. NETRA [18] secure system. Reducing the attack surface is part of the is a another tool for analyzing explicit information flow Microsoft Security Development Lifecycle (SDL) [11]. relationships in access control configurations. It has In [17], Manadhata et al. propose to measure a system’s been applied to analyze Windows XP and SELinux poli- attack surface in terms of three kinds of resources used cies. PALMS [9] is a tool for analyzing SELinux MLS in attacks on the system: methods, channels and data. Security Policy

Machine Configuration Fact Collector System Facts

Host Attack Machine State System Rules Host Attack Graph Attack Path Analyzer Minimal Attack Paths Graph Generator

Query: Initial Resources Attack Objective

Figure 1. Solution Overview

Two IMAP and two FTP programs are evaluated using and AppArmor policies. We write scripts to collect this method. information of the file system and running services. Attack graph is used to analyze the security of net- works in existing works [22, 20]. Our approach also 3. Encode what the attacker can do to break into a sys- computes a graph similar to an attack graph. However, tem and escalate privileges in one or more steps. our problem space is different, as we consider control For each security-enhanced mechanism, we define of processes under different access control restrictions, the notion of attack states to describe the attacker’s rather than control of network-connected hosts. Also, current privileges. For each MAC system we write we perform additional analysis on the resulted graph to a library of system rules that describe how an at- generate all minimal attack paths for analysis and com- tacker exploits a program to cause state transition parison purposes. under the MAC system. 4. Encode an attack scenario into a query, and use the 3 Overview of Our Approach query to generate the host attack graph. A host at- tack graph is a directed graph. The graph nodes are To analyze and compare the QoP of MAC systems, attack states, and graph edges correspond to state we need a way to define the QoP first. Lacking such a transitions. Edges are marked by programs, and by definition prevents debates about the virtues of different compromising marked programs the attacker can systems to go beyond subjective and rhetoric arguments. cause state transitions. We call the nodes of the In this paper, we present a first attempt at coming up graph that represent the attacker’s initial resources with a pragmatic definition. initial attack states, and we call the nodes of the The MAC systems are motivated by the threats and graph that represent the attack objective goal attack attacks facing today’s operating systems, thus they states. should be evaluated by their ability to defend against these attacks. Our approach generates all possible at- 5. Analyze the host attack graph. What we care about tack paths that can lead an attacker to control of the sys- are the paths from initial attack states to goal attack tem. We analyze the QoP under multiple attack scenar- states. The most interesting paths are the ones that ios. Each attack scenario has two aspects. One is the are “minimal”. VulSAN generates all the minimal objective of the attacker (e.g., load a kernel module or attack paths. plant a trojan horse). The other is the initial resources the attacker has (e.g., can connect to the machine from Figure 1 shows the overview of our approach. network, or has a local account). Based on the scenario, The interesting result from the host attack graph is the VulSAN gives all possible attack paths. attack paths. An attack path is a path that starts from an Our approach consists of following steps: initial attack state and ends with a goal attack state. Sup- pose there are two attack paths p1 and p2, and we have 1. Establish a running server as the analysis target. V (p1) ⊂ V (p2) (V (p) represents the set of edge labels along the path). Then we are not interested in p2 since it 2. Translate policy rules and system state information is easier to realize p1 than to realize p2. An attack path p into Prolog facts. We write parsers for SELinux is desirable when there does not exist another attack path p0 such that V (p0) ⊂ V (p). We call such paths minimal In the second approach, one views each program paths. as one unit, implicitly assuming that all programs are We define the vulnerability surface of a protection equal. By making this assumption, it is possible to system as the set of all minimal attack paths. Each path come up with a total order among all protection sys- includes the programs that must be exploited to realize tems. However, the drawback is that the validity of the the attack objective. assumption is questionable. In a few head-to-head com- When we compare two protection systems A and B parisons in this paper, we use this approach. Whenever under the same attack scenario, we first generate the sets we do so, we will explicitly state the assumption that all of all minimal attack paths of the two protection sys- programs are considered equal. tems, called PA and PB. For any path p ∈ PA, we say: The ideal solution is to be able to quantify the efforts needed to exploit different programs. However, this is 0 • p is a strong path if there exists a path p ∈ PB such a challenging open problem that appears unlikely to be 0 that V (p) ⊂ V (p ). solved anytime soon. 0 • p is a weak path if there exists a path p ∈ PB such that V (p) ⊃ V (p0). 4 Our Tool 0 • p is a common path if there exists a path p ∈ PB such that V (p) = V (p0). VulSAN consists of the following components: the Fact Collector, the Host Attack Graph Generator, and • p is a unique path otherwise. the Attack Path Analyzer. When comparing A and B, a common path shows a common way to exploit both systems. A strong path p 4.1 Fact Collector of system A suggests that, if the attacker compromises the same programs in p under system B, she will need to Fact Collector retrieves information about the system compromise more programs to achieve the attack objec- state and security policy, and encodes the information as tive in B. A weak path p of A suggests that, compromis- facts in Prolog. ing a subset of the programs in p under B already helps The information about file system consists of facts of the attacker to achieve the objective in B. A unique path all relevant files, system users, system groups and run- p of A suggests that A is more vulnerable than B be- ning processes. Several sample Prolog facts are depicted cause by realizing p, an attacker can compromise A but in Figure 2. We only consider system facts that are rel- not B. By examining the strong, weak, common, and evant to our security analysis. Irrelevant information, unique attack paths in details, we can better understand like CPU/memory consumption of a process, is not con- the differences of QoP between two systems. sidered. Whether a piece of system information is rele- There are two approaches to use the sets of minimal vant to our analysis depends on the system rules (which attack paths to compare the QoP of two systems. In one will be discussed later), and the MAC system to be ana- approach, one makes no assumption about whether one lyzed. Some facts are security-relevant under all protec- program is easier to compromise than another program. tion mechanisms, like uid/gid of a process; while some In this approach, one could only partially order the QoP facts are unique to a particular mechanism, like security as measured by the host vulnerability surfaces of dif- contexts in SELinux and process profiles in AppArmor. ferent systems. PA has higher QoP than PB when all The encoding of Prolog facts for security policies minimal attack paths for PA are either common paths or vary for different security mechanisms. For example, in weak paths. That is, for every minimal attack path p for SELinux policies, there are several kinds of statements, PA, either PB has the same path, or there exists a path e.g., Type Enforcement Access Vector Rules and Type 0 p for PB that contains a strict subset of the programs in Enforcement Transition Rules. We also define all the p, which means that p0 is easier to exploit than p. The domains and types. Figure 3 gives several sample Pro- strength of this approach is that the comparison result re- log facts which are generated based on a SELinux pol- mains valid even when some programs are significantly icy. Our parser for SELinux policy is based on the tool easier to exploit than other programs. The drawback is checkpolicy. that often times two protection systems are not directly In AppArmor, a profile defines the privileges of a comparable. Most of the analysis in this paper use this certain program. A privilege can be a capability, or a approach. set of permissions over a file or file pattern. Figure 4 gives some sample Prolog facts of an AppArmor pol- (1) file_info(path(’/usr/bin/passwd’), icy. Our parser for AppArmor policy is based on appar- type(regular), owner(0), group(0), mor parser. uper(1,1,1), gper(1,0,1), oper(1,0,1), setuid(1), setgid(0), sticky(0), se_user(’system_u’), se_role(’object_r’), 4.2 Host Attack Graph Generator se_type(’bin_t’)). (2) user_info(’root’, 0, 0). (3) group_info(’mail’, 8, [dovecot]). Host Attack Graph Generator takes system facts, a (4) process_running(4412, 0, 0, ’/usr/lib/postfix/master’, library of system rules and the attack scenario as input, system_u, system_r, initrc_t). and generates the host attack graph. We first discuss how (5) process_networking(4412). to define attack states. (1) is the fact for file /usr/bin/passwd. The fact encodes the In our analysis, the basic unit is a process. The file name, type, owner, group, user/group/world permissions, se- tuid/setguid/sticky bit, and security context of the file. (2) is the fact attack state of a process consists of process attributes for root user, which includes the user name, user id and group id. (3) that are related to access control enforcement. Uid is the fact for mail group, which includes the group name, group id and group members. (4) is the fact for the postfix master process. The and gid of a process are used in Linux DAC mech- fact contains the process id(pid), user id(uid), group id(gid), executed anism, which is the default mechanism. MAC sys- program, and the security context of the process. (5) is the fact for the same process as (4), denoting that the process is open to network. tems give additional process attributes. In SELinux, the current domain of a process is a security related at- Figure 2. Sample Facts of System State tribute. Hence the attack state of a process is described as proc(uid, gid, domain). In AppArmor, an attack state is represented as proc(uid, gid, profile) where profile is the profile that confines the process. Given the attack state of a process controlled by the (1) dom_priv(’user_ssh_t’, ’bin_t’, ’file’, [’’, ’read’, ’getattr’, ’lock’, attacker, the privileges available to the attacker is defined ’execute’, ’execute_no_trans’]). by the policy. For example, under SELinux, a process (2) se_typetrans(old_dom(’user_ssh_t’), new_dom(’user_xauth_t’), with a certain domain can only have a certain set of per- type(’xauth_exec_t’)). missions. Permissions also depend on the uid and gid. (3) se_domain(’user_ssh_t’). (4) se_type(’bin_t’). Figure 5 gives some relevant predicates to describe such enforcement. (1) says a process running under domain ‘user ssh t’ has the following Suppose the attacker controls a process p, she may permissions over a file with type ‘bin t’: ioctl, read, getattr, etc. The fact is derived from a TE Access Vector Rule. (2) says if a process run- exploit or launch a program prog to further control an- ning under domain ‘user ssh t’ executes an executable file with type other attack state. We are interested in all the potential ‘xauth exec t’, the domain of the process should transition to domain ‘user xauth t’. The fact is derived from a TE Type Transition Rule. (3) attack states that might be controlled by an attacker. says ‘user ssh t’ is a SELinux domain. (4) says ‘bin t’ is a SELinux In SELinux, we represent the fact that the type. Facts like (3) and (4) are used to enumerate SELinux domains and types. attacker can control a certain attack state as se node(proc(uid, gid, domain)). If the attacker Figure 3. Sample Facts of SELinux Policy controls attack state s1, and after exploiting a program prog she can control attack state s2, the transition is represented as se edge(s1, s2, prog). Here se node(·) and se edge(·, ·, ·) are both dynamic predicates in Prolog. The state transition depends on the current (1) aa_capability(’/usr/lib/postfix/master’, ’net_bind_service’). attack state, the compromised program and the policy. (2) aa_access_mode(’/usr/lib/postfix/master’, As one example of system rules, we now discuss how ’/etc/samba/smb.conf’, r(1), w(0), ux(0), px(0), ix(0), m(0), l(0)). to encode domain transition under SELinux. The logic to decide domain transition is described in [23], and is (1) says the program /usr/lib/postfix/master has the capability of non-trivial. Suppose the current domain is OldDom, the net bind service. (2) says the program can read samba configure file /etc/samba/smb.conf. Facts like (2) define the privileges of a program type of the executable is Type and the new domain is over a certain file or file pattern. NewDom. We summarize the logic as follows: Figure 4. Sample Facts of AppArmor Policy 1. If OldDom doesn’t have file execute permission on Type, the access is denied. 2. If there is a type transition rule: ‘type transition dac can execute(Uid, Gid, Program) : Decide if a process with net_init(proc(Uid,Gid,Domain), [Program]) :- certain uid and gid can execute a program. process_networking(Pid), process_running(Pid, Uid, Gid, Program, dac execve(Uid, Gid, NewUid, NewGid, Program) : Decide the _, _, Domain). new uid and gid of a process after executing a program. (a) Initial resources: the attacker can connect to the machine from se can execute prog(Domain, Program, NewDomain) : Decide if a network process with certain domain can execute a program, and what the new domain is after execution. load_module_goal(proc(0, _Gid, Domain)) :- se_domain_privilege(domain(Domain), _, aa file privilege(Profile, File, Mode) : Decide if a process with a class(capability), op(sys_module)). certain profile can access a file with a certain mode, e.g., read, write, execute. (b) Attack objective: to load a kernel module aa new profile(Profile, Program, NewProfile) : Get the new profile of a process after executing a program. A profile can be ‘none’ meaning there is no profile confining the process. Figure 7. Predicates for Initial Attack States and Goal Attack States

Figure 5. Sample System Rules se_can_execute_type(Domain, Type, NewDomain) :- 1: function GENERATE GRAPH NODE(s) se_typetrans(old_dom(Domain), 2: if s is already a graph node then new_dom(NewDomain), type(Type)), !, 3: return se_domain_privilege(domain(Domain), 4: Add s as a graph node type(Type), class(file), op(execute)), se_domain_privilege(domain(Domain), 5: if s is a goal attack state then type(NewDomain), class(process), 6: return op(transition)), se_domain_privilege(domain(NewDomain), 7: for all program prog that s can execute do type(Type), class(file), op(entrypoint)). 8: s0 ← the attack state after executing prog 0 se_can_execute_type(Domain, Type, NewDomain) :- 9: Add (s, s ) as a graph edge with label prog se_domain_privilege(domain(Domain), 10: Generate Graph Node(s0) type(Type), class(file), op(execute)), se_domain_privilege(domain(Domain), type(Type), 1: function GENERATE HOST ATTACK GRAPH class(file), op(execute_no_trans)), NewDomain = Domain. 2: for all Initial attack state s do 3: Generate Graph Node(s)

Figure 6. Rules for Domain Transition Figure 8. Algorithm for Host Attack Graph Generation OldDom Type: process NewDom’, the access is granted only when OldDom has process transition permission on Type and NewDom has file entry- point permission on Type. Otherwise the access is larly, we use a set of goal attack states to represent the denied. If the access is granted, the process runs on objective of the attacker. The encoding of the objective the domain NewDom after executing the program. to load a kernel module is depicted in Figure 7(b). Given the initial attack states and the goal attack 3. If there isn’t such a type transition rule, the ac- states, we can generate the host attack graph that con- cess is granted only when OldDom has file exe- tains all the potential states that the attacker can control. cute no trans permission on Type. Otherwise the The pseudo code is depicted in Figure 8. access is denied. If the access is granted, the pro- cess runs on the original domain OldDom after ex- ecuting the program. 4.3 Attack Path Analyzer Using logic programming the domain transition logic can be encoded naturally. Related Prolog code is shown in Figure 6. Attack Path Analyzer finds all the minimal attack The initial resources of the attacker can be repre- paths in a host attack graph. Figure 9 describes the it- sented as a set of initial attack states. Suppose the at- erative algorithm used by Attack Path Analyzer. The al- tacker can connect to the machine from the network, the gorithm repeatedly updates a set of paths for each node initial attack states are encoded in Figure 7(a). Simi- until all the sets are stablized. 1: function GENERATE MINIMAL ATTACK PATHS both cases, after the trojan program is executed the pro- 2: V ← V ∪ vg 3: for all goal attack state node v do cess should be unconfined. We call (1) a strong trojan 4: add an edge from v to vg, 5: the exploited program for the edge is empty case and (2) a weak trojan case. The third is for a local 6: for all v ∈ V do attacker to install a rootkit. 7: MP(v) ← φ We analyze the QoP under several configurations: 8: for all initial attack state node v do 9: MP(v) ← {φ} 1. Ubuntu 8.04 (we use the Server Edition for all the 10: repeat 11: stable ← true test cases) with SELinux and Ubuntu 8.04 with Ap- 12: for all e ∈ E do pArmor. To understand what additional protec- 13: for all p ∈ MP(e.v1) do 14: p0 ← append(p, e) tion MAC offers on top of DAC, we also evalu- 0 15: if ∃p0 ∈ MP(e.v2) s.t. V (p ) ⊂ V (p0) then ate Ubuntu 8.04 with DAC protection only (without 16: Remove all such paths from MP(e.v2) 0 MAC protection). 17: if not ∃p1 ∈ MP(e.v2) s.t. V (p ) ⊃ V (p1) then 0 18: MP(e.v2) ← MP(e.v2) ∪ {p } 19: stable ← false 2. Fedora 8 with SELinux and SUSE Linux Enterprise 20: until stable Server 10 with AppArmor. We compare the results 21: return MP(v ) g with Ubuntu 8.04/SELinux and Ubuntu 8.04/Ap- pArmor to show that different distributions with the Symbols Meaning same mechanism provide different levels of protec- V The set of host attack graph nodes E The set of host attack graph edges tion. vg The virtual “goal” node added such that each goal attack state has an edge to vg 3. Ubuntu 8.04 with SELinux. In the evaluation, we MP MP(v) stores the set of minimal attack paths to node v only analyze the SELinux policy. We use the result e.v1, e.v2 The starting node and ending node of an edge e to show that only considering MAC policy without V (p) The set of all exploited programs along the path p append(p, e) Append edge e to the end of path p DAC policy and system state is not sufficient. The active services include: sshd, vsftp, apache2, Figure 9. Minimal Attack Paths Generation samba, mysql-server, postfix, nfsd, named, etc. In Fe- dora 8, the SELinux policy is the targeted policy that shipped with the distribution. In Ubuntu 8.04, the SELinux policy is the reference policy that comes with 4.4 Tool Status the selinux package. The AppArmor policy is the one that comes with the apparmor-profiles package. We have implemented VulSAN in Linux. VulSAN has been used to evaluate SELinux and AppArmor in 5.1 SELinux vs. AppArmor vs. DAC only on several Linux distributions. We plan to further improve Ubuntu 8.04 the tool and release it to the public in the future (possi- bly under the terms and conditions of the GNU General Ubuntu 8.04 Server Edition supports both SELinux Public License (GPL)). and AppArmor. This offers an opportunity for us to compare the QoP of SELinux and AppArmor head to 5 Comparing SELinux with AppArmor head. We also include the case in which only DAC is used in the comparison. We use three attack scenarios to evaluate our ap- A Remote Attacker to Install a Rootkit In this attack proach. The first is for a remote attacker to install a scenario, the attacker has network access to the host, and rootkit. We assume the rootkit is installed by loading the objective is to install a rootkit via loading a kernel a kernel module. The second is for a remote attacker to module. The host attack graphs for DAC only, AppAr- plant a Trojan horse. We use two definitions of trojan mor and SELinux are shown in Figure 10, Figure 11 and attacks: (1) the attacker can create an executable in a Figure 12, respectively. The comparison of minimal at- folder on the executable search path or user’s home di- tack paths between SELinux and AppArmor is shown in rectory (2) the attacker can create an executable in any Figure 13. folder such that a normal user process (with a user’s uid Among the three cases, AppArmor has the small- and runs under unconfined domain in SELinux or is not est vulnerability surface. SELinux has all the minimal confined by any profile in AppArmor) can execute. In attack paths AppArmor has and some additional ones. init

/sbin/portmap /sbin/rpc.statd /usr/sbin/named /usr/sbin/mysqld /sbin/dhclient

/usr/sbin/apache2 /usr/sbin/cupsd /usr/sbin/nmbd proc(1, 1) /usr/sbin/rpc.mountd proc(106, 0) proc(108, 117) proc(110, 119) proc(101, 102) /usr/sbin/smbd /usr/sbin/sshd /usr/sbin/vsftpd

/bin/mount /bin/mount /bin/mount /bin/mount /bin/mount /bin/ping /bin/ping /bin/ping /bin/ping /bin/ping /bin/ping6 /bin/ping6 /bin/ping6 /bin/ping6 /bin/ping6 /bin/su /bin/su /bin/su /bin/su /bin/su /bin/umount /bin/umount /bin/umount /bin/umount /bin/umount /lib/dhcp3-client/call-dhclient-script /sbin/mount.nfs /sbin/mount.nfs /sbin/mount.nfs /sbin/mount.nfs /sbin/mount.nfs /usr/bin/arping /usr/bin/arping /usr/bin/arping /usr/bin/arping /usr/bin/arping /usr/bin/chfn /usr/bin/chfn /usr/bin/chfn /usr/bin/chfn /usr/bin/chfn /usr/bin/chsh /usr/bin/chsh /usr/bin/chsh /usr/bin/chsh /usr/bin/chsh /usr/bin/gpasswd /usr/bin/gpasswd /usr/bin/gpasswd /usr/bin/gpasswd /usr/bin/gpasswd /usr/bin/mtr /usr/bin/mtr /usr/bin/mtr /usr/bin/mtr /usr/bin/mtr /usr/bin/newgrp /usr/bin/newgrp /usr/bin/newgrp /usr/bin/newgrp /usr/bin/newgrp /usr/bin/passwd /usr/bin/passwd /usr/bin/passwd /usr/bin/passwd /usr/bin/passwd /usr/bin/sudo /usr/bin/sudo /usr/bin/sudo /usr/bin/sudo /usr/bin/sudo /usr/bin/sudoedit /usr/bin/sudoedit /usr/bin/sudoedit /usr/bin/sudoedit /usr/bin/sudoedit /usr/bin/traceroute6.iputils /usr/bin/traceroute6.iputils /usr/bin/traceroute6.iputils /usr/bin/traceroute6.iputils /usr/bin/traceroute6.iputils /usr/lib/eject/dmcrypt-get-device /usr/lib/eject/dmcrypt-get-device /usr/lib/eject/dmcrypt-get-device /usr/lib/eject/dmcrypt-get-device /usr/lib/eject/dmcrypt-get-device /usr/lib/openssh/ssh-keysign /usr/lib/openssh/ssh-keysign /usr/lib/openssh/ssh-keysign /usr/lib/openssh/ssh-keysign /usr/lib/openssh/ssh-keysign /usr/lib/pt_chown /usr/lib/pt_chown /usr/lib/pt_chown /usr/lib/pt_chown /usr/lib/pt_chown

proc(0, 1) proc(0, 0) proc(0, 117) proc(0, 119) proc(0, 102)

Figure 10. Host Attack Graph for a Remote Attacker to Install a Rootkit (Ubuntu 8.04 with DAC only)

init

/usr/sbin/sshd /usr/sbin/mysqld /usr/sbin/named

/usr/sbin/apache2 proc(0, 0, /usr/sbin/sshd) proc(108, 117, none) proc(109, 118, none) /usr/sbin/rpc.mountd

/bin/mount /bin/mount /bin/ping6 /bin/ping6 /bin/su /bin/su /bin/umount /bin/umount /sbin/mount.nfs /sbin/mount.nfs /usr/bin/arping /usr/bin/arping /usr/bin/chfn /usr/bin/chfn /usr/bin/chsh /usr/bin/chsh /bin/bash /usr/bin/gpasswd /usr/bin/gpasswd /usr/bin/mtr /usr/bin/mtr /usr/bin/newgrp /usr/bin/newgrp /usr/bin/sudo /usr/bin/sudo /usr/bin/sudoedit /usr/bin/sudoedit /usr/bin/traceroute6.iputils /usr/bin/traceroute6.iputils /usr/lib/eject/dmcrypt-get-device /usr/lib/eject/dmcrypt-get-device /usr/lib/openssh/ssh-keysign /usr/lib/openssh/ssh-keysign /usr/lib/pt_chown /usr/lib/pt_chown

proc(0, 0, none) proc(0, 117, none) proc(0, 118, none)

Figure 11. Host Attack Graph for a Remote Attacker to Install a Rootkit (Ubuntu 8.04 with AppArmor) takrt ntl oti Uut 8.04 (Ubuntu Rootkit SELinux) with a Install Remote to a for Attacker Graph Attack Host 12. Figure

init

/sbin/rpc.statd /sbin/portmap /usr/sbin/named /usr/sbin/cupsd /usr/sbin/sshd /usr/sbin/mysqld /sbin/dhclient

/usr/sbin/apache2 /usr/sbin/nmbd /usr/sbin/rpc.mountd proc(106, 0, unconfined_t) proc(1, 1, unconfined_t) proc(108, 117, unconfined_t) proc(0, 0, cupsd_t) proc(0, 0, sshd_t) proc(110, 119, unconfined_t) proc(101, 102, dhcpc_t) /usr/sbin/smbd /usr/sbin/vsftpd

/bin/mount /bin/ping /bin/ping /bin/ping /bin/ping /bin/ping /bin/ping6 /bin/ping6 /bin/ping6 /bin/ping6 /bin/ping6 /bin/su /bin/su /bin/su /bin/su /bin/su /bin/umount /sbin/mount.nfs /sbin/mount.nfs /sbin/mount.nfs /sbin/mount.nfs /lib/dhcp3-client/call-dhclient-script /usr/bin/arping /usr/bin/arping /usr/bin/arping /usr/bin/arping /sbin/mount.nfs /usr/bin/chfn /usr/bin/chfn /usr/bin/chfn /usr/bin/chfn /usr/bin/arping /usr/bin/chsh /usr/bin/chsh /usr/bin/chsh /usr/bin/chsh /usr/bin/chfn /usr/bin/gpasswd /usr/bin/gpasswd /usr/bin/gpasswd /usr/bin/gpasswd /bin/mount /bin/mount /bin/mount /bin/mount /usr/bin/chsh /usr/bin/mtr /usr/bin/mtr /usr/bin/mtr /sbin/unix_chkpwd /usr/bin/mtr /bin/umount /bin/umount /bin/umount /bin/umount /usr/bin/gpasswd /usr/bin/newgrp /usr/bin/newgrp /usr/bin/newgrp /usr/bin/newgrp /usr/bin/mtr /usr/bin/passwd /usr/bin/passwd /usr/bin/passwd /usr/bin/passwd /usr/bin/newgrp /usr/bin/sudo /usr/bin/sudo /usr/bin/sudo /usr/bin/sudo /usr/bin/passwd /usr/bin/sudoedit /usr/bin/sudoedit /usr/bin/sudoedit /usr/bin/sudoedit /usr/bin/sudo /usr/bin/traceroute6.iputils /usr/bin/traceroute6.iputils /usr/bin/traceroute6.iputils /usr/bin/traceroute6.iputils /usr/bin/sudoedit /usr/lib/eject/dmcrypt-get-device /usr/lib/eject/dmcrypt-get-device /usr/lib/eject/dmcrypt-get-device /usr/lib/eject/dmcrypt-get-device /usr/bin/traceroute6.iputils /usr/lib/openssh/ssh-keysign /usr/lib/openssh/ssh-keysign /usr/lib/openssh/ssh-keysign /usr/lib/openssh/ssh-keysign /usr/lib/eject/dmcrypt-get-device /usr/lib/pt_chown /usr/lib/pt_chown /usr/lib/pt_chown /usr/lib/pt_chown /usr/lib/openssh/ssh-keysign /usr/lib/pt_chown

proc(0, 0, unconfined_t) proc(0, 0, unconfined_mount_t) proc(0, 1, unconfined_t) proc(0, 1, unconfined_mount_t) proc(0, 117, unconfined_t) proc(0, 117, unconfined_mount_t) proc(0, 42, system_chkpwd_t) proc(0, 119, unconfined_t) proc(0, 119, unconfined_mount_t) proc(0, 102, dhcpc_t) u sro.(lhuhsh srnigi sshd in running is sshd the (Although to root. due which as sshd are run and paths rpc.mountd apache2, profiles length-1 programs by The daemon confined not con- AppArmor. are not under and is SELinux) program by the strained that domain (meaning unconfined in SELinux run under that programs daemon to due and paths has SELinux these, to More and paths SELinux path. paths has attack minimal attack AppArmor additional specifically, the one all has has and has, case only DAC The rgasaernigi h unconfined the Some in (1) running reasons: are three programs to due are have doesn’t pArmor escalation. attacker privilege the local another them, do of to and one needs mysqld compromising programs After daemon named. unprivileged to a due paths load length-2 are The to indirectly). process the or the AppArmor, directly allow module in kernel both profile profile the a and by domain confined and SELinux aigporm unn sro nUut .4Server 8.04 Ubuntu in root as running programs facing rootkit. a install /bin/unix exploit to program privilege additionally root to setuid has cupsd the she exploits enabled, attacker SELinux the with When the by SELinux. confined of is and domain root The as path runs /usr/sbin/cupsd. daemon is attack cupsd path The minimal SELinux. length-1 to compared (strong) additional one named esca- mysqld. compromising or further after privileges to attackers’ used the be in late can confined but they SELinux therefore Ping in AppArmor, unconfined programs. are root passwd setuid and some because of SELinux confinement for the paths of attack mod- unique kernel a are load There to attacker ule. the enable compromis- not DAC, do under them ing root) ac- the unprivileged to with opposed (as AppAr- run counts or they SELinux because However, in either mor. confined and not (named are programs mysqld) Some (3) loading. allow module doesn’t kernel /sbin/dhclient profile category. the while this module nel into dhcpc domain fall example, dhclient, TwoFor and profiles. cupsd AppArmor corresponding programs, as are tight programs are as confinements Some not the but (2) domains, SELinux vs- by rpc.statd. smbd, confined and nmbd, e.g., has portmap, include, AppArmor ftpd, these while them; policy, for SELinux profiles of version this takptscmo oaltrecssaemainly are cases three all to common paths Attack h iia takptsta Eiu a u Ap- but has SELinux that paths attack minimal The u nlsssosta mn h ee network- seven the among that shows analysis Our only has case only DAC the surprisingly, Somewhat 63 34 oelnt- iia takpaths. attack minimal length-2 more egh2mnmlatc ah.I addition In paths. attack minimal length-2 3 oelnt- iia attack minimal length-1 more 3 salwdt odaker- a load to allowed is t egh1mnmlattack minimal length-1 hpdt anthe gain to chkpwd oanunder domain t under t t SELinux compared to AppArmor SUID* represents a set of setuid root programs: common /usr/sbin/apache2 /bin/ping6 /usr/sbin/rpc.mountd /bin/su /usr/sbin/named SUID* /sbin/mount.nfs /usr/sbin/mysqld SUID* /usr/bin/arping /usr/sbin/sshd /usr/bin/chfn unique /usr/sbin/nmbd /usr/bin/chsh /usr/sbin/smbd /usr/bin/gpasswd /usr/sbin/vsftpd /usr/bin/mtr /sbin/portmap SUID** /usr/bin/newgrp /sbin/rpc.statd SUID** /usr/bin/sudo /usr/bin/sudoedit /usr/sbin/cupsd /sbin/unix chkpwd /usr/bin/traceroute6.iputils /sbin/dhclient SUID** /usr/lib/eject/dmcrypt-get-device /sbin/dhclient /lib/dhcp3-client/call- /usr/lib/openssh/ssh-keysign dhclient-script /usr/lib/pt chown /bin/mount /usr/sbin/named /bin/ping /bin/umount /usr/sbin/named /usr/bin/passwd /usr/sbin/mysqld /bin/ping SUID** includes all programs in SUID* and also /usr/sbin/mysqld /usr/bin/passwd /bin/ping and /usr/bin/passwd

Figure 13. Minimal Attack Paths Comparison for a Remote Attacker to Install a Rootkit

Edition, namely apache2, cupsd, nmbd, rpc.mountd, as neither SELinux nor AppArmor performs informa- smbd, sshd, and vsftpd, only one of them is confined in tion flow tracking, the system cannot tell a program left any meaningful way by the SELinux policy. Hence one by a remote attacker from one originally in the system. can argue that the additional protection provided by the A Local Attacker to Install a Rootkit SELinux reference policy in Ubuntu 8.04 is quite lim- In the third attack scenario, the attacker has a local ac- ited. count. The objective is to install a rootkit (load a kernel Remote Attacker to Leave a Trojan Horse module). Figure 15 and Figure 16 shows the host attack We consider a scenario in which the attacker is re- graphs for Ubuntu 8.04 with SELinux and AppArmor, mote and wants to leave a Trojan horse. We consider respectively. both the strong Trojan horse case and the weak Trojan Again, AppArmor has a smaller vulnerability horse case. We observe that performing a strong trojan surface. All minimal exploit paths in AppArmor attack is always not more difficult than installing a ker- also occur in SELinux, which has some additional nel module. exploit paths. There are 19 common minimal attack For Ubuntu 8.04 with AppArmor, compared to load- paths, they are all of length 1. They are due to 19 ing kernel module, there is one extra attack path in setuid root programs that have sufficient privileges. strong trojan attack: /usr/sbin/smbd. For Ubuntu 8.04 These programs are /bin/fusermount, /bin/ping6, with SELinux, the host attack graph is the same as the /bin/su, /sbin/mount.nfs, /usr/bin/arping, /usr/bin/chfn, graph for a remote attacker to install a rootkit. /usr/bin/chsh, /usr/bin/gpasswd, /usr/bin/mtr, It’s significantly easier to perform weak trojan at- /usr/bin/newgrp, /usr/bin/sudo, /usr/bin/sudoedit, tacks. Figure 14 shows the host attack graph to leave /usr/bin/traceroute6.iputils, /usr/lib/eject/dmcrypt-get- a weak trojan in Ubuntu 8.04 with SELinux. Every net- device, /usr/lib/openssh/ssh-keysign, /usr/lib/pt chown, work faced program, if compromised, can be used di- /usr/sbin/pppd, /bin/mount, /bin/umount. rectly to leave a weak Trojan horse. This is so due to The programs in the common paths are setuid root two reasons. First, both SELinux and AppArmor con- programs. The result shows that the way for a local fine only a subset of the known programs and leave any user to load a kernel module is to exploit one of the se- program not explicitly identified as confined. Second, tuid root programs. SELinux has 2 unique minimal at- init

/usr/sbin/apache2 /usr/sbin/nmbd /usr/sbin/rpc.mountd /sbin/portmap /sbin/rpc.statd /usr/sbin/named /usr/sbin/cupsd /usr/sbin/sshd /usr/sbin/mysqld /sbin/dhclient /usr/sbin/smbd /usr/sbin/vsftpd

proc(0, 0, unconfined_t) proc(1, 1, unconfined_t) proc(106, 0, unconfined_t) proc(108, 117, unconfined_t) proc(0, 0, cupsd_t) proc(0, 0, sshd_t) proc(110, 119, unconfined_t) proc(101, 102, dhcpc_t)

Figure 14. Host Attack Graph for a Remote Attacker to Leave a Weak Trojan (Ubuntu 8.04 with SELinux)

init init

proc(1000, 1000, unconfined_t) proc(1000, 1000, none)

/bin/fusermount /bin/fusermount /bin/ping /bin/mount /bin/ping6 /bin/ping6 /bin/su /bin/su /bin/umount /sbin/mount.nfs /sbin/mount.nfs /usr/bin/arping /usr/bin/arping /usr/bin/chfn /usr/bin/chfn /usr/bin/chsh /usr/bin/chsh /usr/bin/gpasswd /bin/mount /usr/bin/gpasswd /usr/bin/mtr /bin/umount /usr/bin/mtr /usr/bin/newgrp /usr/bin/newgrp /usr/bin/passwd /usr/bin/sudo /usr/bin/sudo /usr/bin/sudoedit /usr/bin/sudoedit /usr/bin/traceroute6.iputils /usr/bin/traceroute6.iputils /usr/lib/eject/dmcrypt-get-device /usr/lib/eject/dmcrypt-get-device /usr/lib/openssh/ssh-keysign /usr/lib/openssh/ssh-keysign /usr/lib/pt_chown /usr/lib/pt_chown /usr/sbin/pppd /usr/sbin/pppd

proc(0, 1000, none) proc(0, 1000, unconfined_t) proc(0, 1000, unconfined_mount_t)

Figure 16. Host Attack Graph for a Local Figure 15. Host Attack Graph for a Local Attacker to Install a Rootkit (Ubuntu 8.04 Attacker to Install a Rootkit (Ubuntu 8.04 with AppArmor) with SELinux)

tack paths for SELinux: /bin/ping and /usr/bin/passwd. which is the SELinux targeted policy, offers signifi- They are due to the same reason in the first scenario, cantly better protection than the SELinux in Ubuntu 8.04 that SELinux does not confine ping and passwd while Server Edition, which uses a version of the SELinux ref- AppArmor confines them. erence policy. In addition, the most current version of the SELinux reference policy is also tighter than the pol- icy shipped with Ubuntu 8.04. 5.2 Other Comparisons Figure 17 shows the host attack graph for a remote attacker to install a rootkit in Fedora 8 with SELinux. In this subsection we compare the QoP offered by The vulnerability surface is not directly comparable with different Linux distributions with a same MAC mech- that of Ubuntu 8.04 (shown in Figure 12) because each anism. We also discuss why considering MAC policy has some unique attack paths. If we assume that all alone is not enough. programs are equal, the vulnerability surface of Fe- Different Versions of SELinux dora 8/SELinux is smaller because there is 1 length- We have found that the SELinux policy in Fedora 8, 1 minimal attack path and 13 length-2 minimal attack paths in Fedora 8/SELinux, while there are 6 length- We have analyzed the vulnerability surface of SUSE 1 minimal attack paths and 97 length-2 minimal attack Linux Enterprise Server 10 (SLES 10) with AppArmor paths in Ubuntu 8.04/SELinux. protection. To keep the services in SLES 10 the same as in Ubuntu 8.04, some services that are up by default in SLES 10 are turned off, e.g., slpd and zmd. init The vulnerability surface of SLES 10/AppArmor un- /usr/sbin/sshd /sbin/dhclient der the scenario that a remote attacker wants to install

proc(0, 0, sshd_t) /usr/sbin/rpc.rquotad proc(0, 0, dhcpc_t) a rootkit (as shown in Figure 19) is not directly com- parable with that of Ubuntu 8.04/AppArmor. The two /sbin/ethtool /sbin/insmod /sbin/ifconfig distributions expose different vulnerability surfaces. /bin/bash /sbin/insmod.static /sbin/ip /etc/rc.d/init.d/ntpd /bin/zsh /sbin/modprobe /sbin/iwconfig /sbin/rmmod /sbin/mii-tool /sbin/tc init

proc(0, 0, unconfined_t) proc(0, 0, initrc_t) proc(0, 0, insmod_t) proc(0, 0, ifconfig_t) /usr/sbin/cupsd /usr/sbin/sshd

proc(4, 7, none) /usr/sbin/rpc.mountd proc(0, 0, /usr/sbin/sshd)

/bin/eject /bin/mount /bin/ping6 /bin/su Figure 17. Host Attack Graph for a Remote /bin/umount /opt/gnome/lib/libgnomesu/gnomesu-pam-backend /opt/gnome/sbin/change-passwd Attacker to Install a Rootkit (Fedora 8 with /opt/kde3/bin/kpac_dhcp_helper /sbin/unix2_chkpwd /usr/X11R6/bin/Xorg SELinux) /usr/bin/at /usr/bin/chage /bin/ash /usr/bin/chfn /bin/bash /usr/bin/chsh /usr/lib/news/bin/inews /bin/tcsh /usr/bin/crontab /bin/zsh /usr/bin/expiry /sbin/nologin /usr/bin/gpasswd Figure 18 shows the host attack graph for a remote at- /usr/bin/gpg /usr/bin/mandb /usr/bin/newgrp tacker to leave a strong trojan in Fedora 8 with SELinux. /usr/bin/opiepasswd /usr/bin/opiesu /usr/bin/rcp Compared to the kernel module loading scenario, tro- /usr/bin/rlogin /usr/bin/rsh /usr/bin/sudo jan attack scenario has three additional minimal attack /usr/lib/pt_chown /usr/sbin/suexec2 paths: proc(0, 7, none) proc(4, 13, none) proc(0, 0, none)

/usr/lib/news/bin/inndstart /usr/sbin/rpc.mountd /usr/lib/news/bin/startinnfeed /usr/sbin/smbd proc(0, 13, none) /usr/sbin/sendmail /usr/bin/procmail

Two paths are related to file sharing and the other is due Figure 19. Host Attack Graph for a Remote to sendmail. Those programs are confined, but they have Attacker to Install a Rootkit (SUSE Linux privileges to write to the user’s home directory or di- Enterprise Server 10 with AppArmor) rectories in the executable search path. Under the as- sumption that all programs are equal, the vulnerabil- ity surface of Fedora 8/SELinux is smaller than that of The common attack paths are through sshd and Ubuntu 8.04/SELinux for the remote trojan attack sce- rpc.mountd (NFS mount daemon). The unique paths for nario. Ubuntu 8.04 are through apache2, mysqld and named, due to that those programs are not confined. The unique

init paths for SLES 10 are through cupsd since cupsd is not

/usr/sbin/rpc.mountd /usr/sbin/smbd /usr/sbin/sendmail /sbin/dhclient /usr/sbin/sshd confined. Sshd also contributes to some unique paths

proc(0, 0, nfsd_t) proc(0, 0, smbd_t) proc(0, 51, sendmail_t) proc(0, 0, dhcpc_t) /usr/sbin/rpc.rquotad proc(0, 0, sshd_t) since there are more shells installed in SLES 10.

/bin/bash /usr/bin/procmail /etc/rc.d/init.d/ntpd In SLES 10, the host attack graph for a remote at- /bin/zsh

proc(0, 51, procmail_t) proc(0, 0, initrc_t) proc(0, 0, unconfined_t) tacker to plant a strong Trojan horse is the same as the graph for a remote attacker to install a rootkit. For a lo- cal attacker to install a rootkit, the host attack graph for Figure 18. Host Attack Graph for a Remote SLES 10 is shown in Figure 20. There are 10 common Attacker to Leave a Strong Trojan (Fedora attack paths due to unconfined set uid root programs. 8 with SELinux) There are 9 unique attack paths for Ubuntu 8.04 and 20 unique attack paths for SLES 10. The Need to Consider DAC Policy Different Versions of AppArmor Our approach considers both the MAC policy and init init

proc(1000, 100, none) /sbin/portmap /sbin/rpc.statd /bin/eject /usr/sbin/apache2 /bin/mount /usr/sbin/mysqld /bin/ping6 /bin/su /usr/sbin/named /usr/sbin/cupsd /usr/sbin/sshd /sbin/dhclient /bin/umount /usr/sbin/nmbd /opt/gnome/lib/libgnomesu/gnomesu-pam-backend /usr/sbin/rpc.mountd /opt/gnome/sbin/change-passwd /opt/kde3/bin/kpac_dhcp_helper /usr/sbin/smbd /sbin/unix2_chkpwd /usr/sbin/vsftpd /usr/X11R6/bin/Xorg /usr/bin/at /usr/bin/chage unconfined_t cupsd_t sshd_t dhcpc_t /usr/bin/chfn /usr/bin/chsh /usr/lib/news/bin/inews /usr/bin/crontab /sbin/unix_chkpwd /usr/bin/expiry /usr/bin/gpasswd /usr/bin/gpg /usr/bin/mandb system_chkpwd_t /usr/bin/newgrp /usr/bin/opiepasswd /usr/bin/opiesu /usr/bin/rcp /usr/bin/rlogin /usr/bin/rsh /usr/bin/sudo Figure 21. Host Attack Graph for a Remote /usr/lib/pt_chown /usr/sbin/suexec2 Attacker to Install a Rootkit (Ubuntu 8.04

proc(0, 100, none) proc(1000, 13, none) with SELinux – only Considering SELinux Policy) /usr/lib/news/bin/inndstart /usr/lib/news/bin/startinnfeed

proc(0, 13, none) 5.3 Performance

Figure 20. Host Attack Graph for a Local In our experiments, the targeted operating systems Attacker to Install a Rootkit (SUSE Linux (Ubuntu, Fedora and SUSE Linux) are installed in vir- Enterprise Server 10 with AppArmor) tual machines using VMWare. The host attack graph generation and attack path analysis are performed on a laptop with Intel(R) Pentium(R) M processor 1.80GHz and 1G memory. The Prolog engine is swi-prolog 5.6.14. The running time for the fact collector is less than 10 minutes for every test case. The running time for the host attack graph generation and analysis is less than 10 the DAC policy. If we only consider MAC policy, e.g., minutes for every test case. SELinux policy, the result may not be accurate. Fig- ure 21 shows the host attack graph for a remote attacker to install a rootkit, when we only consider SELinux pol- 6 Conclusions icy but not DAC policy. Compared to the host attack graph that considers both DAC and MAC policy (shown In this paper, we propose an approach to analyze in Figure 12), we observe that without considering and compare the protection quality offered by policies DAC policies, there are following extra length-1 attack of different Mandatory Access Control mechanisms in paths: /sbin/portmap, /sbin/rpc.statd, /usr/sbin/mysqld, security-enhanced operating systems. Our analysis is /usr/sbin/named, /sbin/dhclient. They are not accurate. based on the security policy, system state and system For example, mysqld is running with uid 110 and un- configuration. We develop a tool to generate the host at- confined t. By compromising mysqld the attacker can tack graph for a given attack scenario. We propose to control unconfined t, but she still cannot load a kernel use vulnerability surface to measure the protection qual- module because the uid is unprivileged. To control root ity of a system. We evaluate our approach by analyz- uid the attacker needs to do another exploit, e.g., by ex- ing and comparing SELinux and AppArmor in several ploiting a setuid root program. Linux distributions. 6.1 Acknowledgements [11] M. Howard. Mitigate security risks by minimiz- ing the code you expose to untrusted users. MSDN This work is supported by NSF CNS-0448204 (CA- Magazine, November 2004. REER: Access Control Policy Verification Through Se- [12] M. Howard, J. Pincus, and J. M. Wing. Measuring curity Analysis And Insider Threat Assessment), and by relative attack surfaces. In Proceedings of Work- sponsors of CERIAS. We also thank the anonymous re- shop on Advanced Developments in Software and viewers for NDSS and the shepherd of our paper Crispin Systems Security, December 2003. Cowan for valuable comments that have greatly im- proved the paper. [13] T. Jaeger, R. Sailer, and X. Zhang. Analyzing in- tegrity protection in the SELinux example policy. References In Proceedings of the 12th USENIX Security Sym- posium, pages 59–74, August 2003. [1] Apparmor application security for linux. [14] T. Jaeger, X. Zhang, and F. Cacheda. Policy man- http://www.novell.com/linux/security/apparmor/. agement using access control spaces. ACM Trans. Inf. Syst. Secur., 6(3):327–364, 2003. [2] Apparmor development. http://developer.novell.com/wiki/index.php/Apparmor. [15] A. Leitner. Novell and red hat security experts face off on apparmor and selinux counterpoint. Linux [3] Selinux for distributions. Magazine, (69), 2006. http://selinux.sourceforge.net. [16] N. Li, Z. Mao, and H. Chen. Usable manda- [4] D. E. Bell and L. J. LaPadula. Secure computer tory integrity protection for operating systems. In systems: Unified exposition and Multics interpre- Proc. IEEE Symposium on Security and Privacy, tation. Technical Report ESD-TR-75-306, Mitre May 2007. Corporation, Mar. 1976. [17] P. K. Manadhata, K. M. . Tan, R. A. Maxion, and [5] C. Cowan, S. Beattie, G. Kroah-Hartman, C. Pu, J. M. Wing. An approach to measuring a system’s P. Wagle, and V. D. Gligor. Subdomain: Parsi- attack surface. Technical Report CMU-CS-07-146, monious server security. In Proceedings of the CMU, August 2007. 14th Conference on Systems Administration (LISA [18] P. Naldurg, S. Schwoon, S. K. Rajamani, and 2000), pages 355–368, Dec. 2000. J. Lambert. NETRA: : seeing through access con- [6] T. Fraser. LOMAC: Low water-mark integrity pro- trol. In FMSE, pages 55–66, 2006. tection for COTS environments. In Proc. IEEE [19] NSA. Security enhanced linux. Symposium on Security and Privacy, May 2000. http://www.nsa.gov/selinux/. [7] T. Fraser. LOMAC: MAC you can live with. In [20] X. Ou, W. F. Boyer, and M. A. McQueen. A Proceedings of the FREENIX Track: USENIX An- scalable approach to attack graph generation. In nual Technical Conference, June 2001. Proceedings of the 13th ACM conference on Com- puter and communications security, pages 336– [8] J. D. Guttman, A. L. Herzog, J. D. Ramsdell, and 345, New York, NY, USA, 2006. ACM. C. W. Skorupka. Verifying information flow goals in security-enhanced linux. Journal of Computer [21] B. Sarna-Starosta and S. D. Stoller. Policy analysis Security, 13(1):115–134, 2005. for security-enhanced linux. In Proceedings of the 2004 Workshop on Issues in the Theory of Security [9] B. Hicks, S. Rueda, L. S. Clair, T. Jaeger, and P. D. (WITS), pages 1–12, April 2004. McDaniel. A logical specification and analysis for selinux mls policy. In SACMAT, pages 91–100, [22] O. Sheyner, J. Haines, S. Jha, R. Lippmann, and 2007. J. M. Wing. Automated generation and analysis of attack graphs. In Proceedings of the 2002 IEEE [10] S. Hinrichs and P. Naldurg. Attack-based domain Symposium on Security and Privacy, page 273, transition analysis. In Annual Security Enhanced Washington, DC, USA, 2002. IEEE Computer So- Linux Symposium, 2006. ciety. [23] S. Smalley, C. Vance, and W. Salamon. Im- plementing SELinux as a Linux security module. Technical Report 01-043, NAI Labs, December 2001. [24] Tresys technology, setools - policy anal- ysis tools for selinux. Available at http://oss.tresys.com/projects/setools. [25] G. Zanin and L. V. Mancini. Towards a formal model for security policies specification and vali- dation in the selinux system. In Proc. ACM Sympo- sium on Access Control Models and Technologies (SACMAT), pages 136–145, 2004.