Analyzing and Comparing the Protection Quality ofSecurity Enhanced Operating Systems

Hong Chen Ninghui Li Ziqing MaoCenter for Education and Research in Information Assurance and Security

and Department of Computer Science, Purdue University{chen131, ninghui, zmao}@cs.purdue.edu

Abstract

Host compromise is a serious computer securityproblem today. To better protect hosts, several Manda-tory Access Control systems, such as Security EnhancedLinux (SELinux) and AppArmor, have been introduced.In this paper we propose an approach to analyze andcompare the quality of protection offered by the poli-cies of different mechanisms. We introduce the notionof vulnerability surfaces under attack scenarios as themeasurement of protection quality, and implement a toolcalled VulSAN for analyzing and comparing protectionquality of these MAC systems for Linux. In VulSAN,we encode security policies, system states, and systemrules using logic programs. Given an attack scenario,VulSAN computes a host attack graph and the vulner-ability surface. We apply our approach to compareSELinux and AppArmor policies in several Linux dis-tributions and discuss the results. Our tool can also beused by Linux system administrators as a system hard-ening tool. Because of its ability to analyze SELinux aswell as AppArmor policies, it can be used for most en-terprise Linux distributions and home user distributions.

1 Introduction

Host compromise is one of the most serious computersecurity problems today. A key reason why hosts canbe easily compromised is that the Discretionary AccessControl (DAC) mechanism in today’s operating systemsis vulnerable to Trojan horses and the exploitation ofbuggy software. Recognizing this limitation of exist-ing DAC mechanisms, in the past decade there have

been a number of efforts aiming at adding some formof Mandatory Access Control (MAC) to Commercial-Off-The-Shelf (COTS) operating systems. Examples in-clude Low Water-Mark Access Control (LOMAC) [6,7], Security Enhanced Linux (SELinux) [19], AppAr-mor [5, 1], and Usable Mandatory Integrity Protection(UMIP) [16]. Some of these systems have been widelydeployed. For example, SELinux is supported in a num-ber of Linux distributions, including Fedora, Debian,Gentoo, EnGarde and Ubuntu [3], and AppArmor is sup-ported in Linux distributions including SUSE, PLD, Par-dus Linux, Annvix, Ubuntu and Mandriva [2].

Given the existence of these protection systems, anatural desire is to understand and compare the qual-ity of protection (QoP) offered by them. A system ad-ministrator would want to know the QoP offered by theMAC system he is using. Note that by an MAC system,we mean both the mechanism (e.g., SELinux or AppAr-mor) and the specific policy being used in the system,because the QoP is determined by both. More specif-ically, it would be very useful for an administrator toknow: What kinds of attacks are prevented by the MACsystem my host is using? What does it take for an at-tacker to penetrate the defense of the system, e.g., toinstall a rootkit on my host? Can the attacker leave aTrojan horse program on my host such that when theprogram is later accidentally executed by a user, my hostis taken over by the attacker? Would it be more secureif I use a competing distribution which has a differentMAC mechanism or different MAC policy?

In this paper, we develop a tool called VulnerabilitySurface ANalyzer (VulSAN) for answering these ques-tions. We analyze the QoP by measuring the vulnera-bility surface for attack scenarios. An attack scenario isdefined by an attack objective and the attacker’s initial

resources. For example, “remote to full control” is anattack scenario in which a remote attacker wants to fullycontrol the system. Other attack scenarios can be “re-mote to leaving a trojan”, “local to full control”, etc. Avulnerability surface of a system is a list of minimal at-tack paths. Each attack path consists of a set of programssuch that by compromising those programs the attackscenario can be realized. Vulnerability surface is relatedto attack surface [11] which is a concept in MicrosoftSecurity Development Lifecycle (SDL). Attack surfaceuses the resources that might be used to attack a systemto measure the attackability of the system (details arediscussed in Section 2). They are different in that vulner-ability surface provides potential multi-step attack pathsof a system while attack surface considers potential en-trypoints of attacks. VulSAN computes the vulnerabilitysurfaces for attack scenarios under SELinux and AppAr-mor. VulSAN encodes the MAC policy, the DAC policyand the state of the host into Prolog facts, and generatesa host attack graph for each attack scenario, from whichit generates minimal attack paths which constitute thevulnerability surface.

VulSAN can be used by Linux system administratorsas a system hardening tool. A system administrator canuse VulSAN to compute the host attack graphs for at-tack scenarios that are of concern. By analyzing thesegraphs, the administrator can try to harden the system bytweaking the system and policy configurations. For ex-ample, the administrator can disable some network dea-mon programs, remove some unnecessary setuid-rootprograms, or tweak the MAC (SELinux or AppArmor)policies to better confine these programs. After mak-ing these changes, the system administrator can re-runthe analysis to see whether it achieves the desired objec-tive. Because VulSAN uses intermediate representationof the system state and policy, it is possible to make thechanges in the representation and to perform analysis,before actually deploying the changes to the real system.Because VulSAN can handle both SELinux and AppAr-mor, which are the two MAC systems used by majorLinux distributions, it can be used for most enterpriseLinux distributions and home user distributions.

VulSAN can also be used to compare the QoP of poli-cies between different systems. Such comparison helpssystem hardening. If an administrator knows that an-other Linux distribution with the same services does nothave a particular vulnerability path, then the administra-tor knows that it is possible to remove such a path whileproviding the necessary services, and can invest the timeand effort to do so.

We have applied VulSAN to analyze the QoP of sev-

eral Linux distributions with SELinux and AppArmor.Comparing the default policies of SELinux and AppAr-mor for the same Linux distribution (namely Ubuntu8.04 Server Edition), we find that AppArmor offerssignificantly smaller vulnerability surface, while theSELinux policy with Ubuntu 8.04 offers only slightlysmaller vulnerability surface compared with the casewhen no MAC is used. More specifically, when no MACis used, the system has seven length-1 attack paths inthe scenario when a remote attacker wants to install arootkit. They correspond to the seven network-facingdaemon programs running as root, namely apache2,cupsd, nmbd, rpc.mountd, smbd, sshd, and vsftpd.Among them, the SELinux policy confines only cupsd.This shows that the often claimed strong protection ofSELinux is not realized, at least in some popular Linuxdistributions. We also note policies in different distribu-tions offer different levels of protection even when theyuse the same mechanism. For example, the SELinuxpolicy in Fedora 8, which is a version of the targetedpolicy, offers tighter protection than that in Ubuntu 8.04,which is a version of the reference policy. We alsoobserve that Ubuntu 8.04 and SUSE Linux EnterpriseServer 10 expose different vulnerability surfaces whenthey both use AppArmor. Also, one attack scenario thatneither SELinux nor AppArmor offers strong protectionis when a remote attacker leaves a malicious executableprogram somewhere in the system and waits for it to beaccidentally executed by users, at which point the pro-cess would not be confined by the MAC system. Thisattack is possible for two reasons. First, both SELinuxand AppArmor confine only a subset of the known pro-grams and leave any program not explicitly identified asunconfined. Second, as neither SELinux nor AppArmorperforms information flow tracking, the system cannottell a program left by a remote attacker from one origi-nally in the system.

The rest of the paper is organized as follows: Sec-tion 2 presents the background and related work. Sec-tion 3 discusses our analysis approach. Section 4 talksabout the implementation of VulSAN. Section 5 presentsthe results of comparing SELinux with AppArmor inseveral Linux distributions. Section 6 concludes the pa-per.

2 Background and Related Work

Security-Enhanced Linux [19] (SELinux) is a secu-rity mechanism in Linux that has been developed to sup-port a wide range of security policies. SELinux has beenintegrated into Linux Kernel since 2.6. In SELinux, ev-

ery process has a domain and every object has a type.Objects are categorized into object security classes, suchas files, folders, sockets, etc. A set of operations are de-fined over each object security class (e.g., read, write,execute, lock, create, rename, etc for a file). A SELinuxpolicy defines processes of which domains can accessobjects of which types with which operations. A policyalso defines how to determine the domain of a processand how the domain changes when a process executesanother program.

AppArmor [1] is an access control system that con-fines the access permissions on a per program basis. Itconfines programs that are likely to be attacked, e.g.,server programs that face network and setuid root pro-grams. For every protected program, AppArmor definesa program profile. A profile is a list of permitted ac-cesses, including file accesses and capabilities. The pro-files of all protected programs constitute an AppArmorpolicy. If a program does not have a profile, it is by de-fault not confined. If a program has a profile, it only haspermissions specified in the profile.

Previous approaches for analyzing SELinux securitypolicies include Gokyo [14, 13], SLAT [8], PAL [21],APOL [24, 10], SELAC [25], NETRA [18], andPALMS [9]. Gokyo [14, 13] identifies a set of domainsand types as the implicit Trusted Computing Base (TCB)of a SELinux policy. Integrity of the TCB holds if notype in it can be written by a domain outside the TCB.SLAT [8] verifies if a SELinux policy satisfies certaininformation flow goals. It answers questions such as:Is it true that all information flow paths in a systemfrom a starting security context to a final security con-text go through a series of specific steps? PAL [21] pro-vides similar functionalities to SLAT. It differs in thatit is implemented in XSB, a logic programming sys-tem. This enables PAL to handle other kinds of queries.APOL [24] is a tool to analyze the relationships betweendomains and types in a SELinux policy. In [10] the au-thors augment APOL to find paths from susceptible do-mains to security sensitive domains. The selection ofsusceptible and security sensitive domains is manuallydone. The query language is less flexible than SLAT orPAL, but it provides a graphical user interface to displaythe results. SELAC [] is a formal model to describe thesemantics of a SELinux policy. The authors develop analgorithm based on SELAC to verify if a given subjectcan access a given object in a given mode. NETRA [18]is a another tool for analyzing explicit information flowrelationships in access control configurations. It hasbeen applied to analyze Windows XP and SELinux poli-cies. PALMS [9] is a tool for analyzing SELinux MLS

policy, and was used to verify that the SELinux MLS ref-erence policy satisfies the simple security property andthe *-property defined by Bell and LaPadula [4].

Our work is different in the following ways. First,VulSAN supports analyzing AppArmor in addition toSELinux. Second, VulSAN utilizes the current systemstate (such as which files exist in the system) as well asDAC policies (such as which users can write to a fileaccording to the DAC permission bits) in addition tothe MAC policies. As shown in Section 5.2, consider-ing DAC is necessary to obtain accurate analysis results.Third, our goal, which is to compute the vulnerabilitysurface under different attack scenarios, is different fromthat of existing tools. In particular we need to be con-cerned with more than just providing a policy analysistool; we need to also come up with appropriate ways ofquerying the tool and analyzing the result.

Comparing the QoP offered by different systems ischallenging because different policy models are used.For example, SELinux uses Type Enforcement (TE), andAppArmor confines security-critical programs with pro-files. Currently there exists no tool to compare the secu-rity of systems protected using different technologies.There is an ongoing debate about which of SELinuxand AppArmor is a better system, but such debate oftencenters on the mechanism and lacks actual comparisonof the security offered by the standard policies shippedwith these protection systems. As a result, such com-parison tends to become rhetoric wars. In [15] Cowanfrom Novell and Riek from Red Hat debated about us-ability, simplicity, and policy implementation (labels vs.pathnames) between AppArmor and SELinux. QoP isnot discussed in details. We believe that comparisonsinvolving actual deployed policies are necessary. It maybe theoretically possible to configure a MAC system tooffer very strong protection, but it is the shipped stan-dard policy that determines the QoP in reality, since veryfew people change the shipped policy. In our approach,we perform a concrete measurement of QoP for bothmechanisms using shipped policies.

Attack surface is proposed as a metric to measure theattackability of a system [11, 12]: “The attack surface ofan app is the union of code, interfaces, services, proto-cols, and practices available to all users, with a strong fo-cus on what is accessible to unauthenticated users.” Theheuristic is that a larger attack surface indicates a lesssecure system. Reducing the attack surface is part of theMicrosoft Security Development Lifecycle (SDL) [11].In [17], Manadhata et al. propose to measure a system’sattack surface in terms of three kinds of resources usedin attacks on the system: methods, channels and data.

Security Policy

Fact CollectorMachine Configuration

Machine State

System Facts

Host Attack 

 Graph GeneratorSystem Rules

Query:

Initial Resources

Attack Objective

Host Attack Graph Attack Path Analyzer Minimal Attack Paths

Figure 1. Solution Overview

Two IMAP and two FTP programs are evaluated usingthis method.

Attack graph is used to analyze the security of net-works in existing works [22, 20]. Our approach alsocomputes a graph similar to an attack graph. However,our problem space is different, as we consider controlof processes under different access control restrictions,rather than control of network-connected hosts. Also,we perform additional analysis on the resulted graph togenerate all minimal attack paths for analysis and com-parison purposes.

3 Overview of Our Approach

To analyze and compare the QoP of MAC systems,we need a way to define the QoP first. Lacking such adefinition prevents debates about the virtues of differentsystems to go beyond subjective and rhetoric arguments.In this paper, we present a first attempt at coming upwith a pragmatic definition.

The MAC systems are motivated by the threats andattacks facing today’s operating systems, thus theyshould be evaluated by their ability to defend againstthese attacks. Our approach generates all possible at-tack paths that can lead an attacker to control of the sys-tem. We analyze the QoP under multiple attack scenar-ios. Each attack scenario has two aspects. One is theobjective of the attacker (e.g., load a kernel module orplant a trojan horse). The other is the initial resourcesthe attacker has (e.g., can connect to the machine fromnetwork, or has a local account). Based on the scenario,VulSAN gives all possible attack paths.

Our approach consists of following steps:

1. Establish a running server as the analysis target.

2. Translate policy rules and system state informationinto Prolog facts. We write parsers for SELinux

and AppArmor policies. We write scripts to collectinformation of the file system and running services.

3. Encode what the attacker can do to break into a sys-tem and escalate privileges in one or more steps.For each security-enhanced mechanism, we definethe notion of attack states to describe the attacker’scurrent privileges. For each MAC system we writea library of system rules that describe how an at-tacker exploits a program to cause state transitionunder the MAC system.

4. Encode an attack scenario into a query, and use thequery to generate the host attack graph. A host at-tack graph is a directed graph. The graph nodes areattack states, and graph edges correspond to statetransitions. Edges are marked by programs, and bycompromising marked programs the attacker cancause state transitions. We call the nodes of thegraph that represent the attacker’s initial resourcesinitial attack states, and we call the nodes of thegraph that represent the attack objective goal attackstates.

5. Analyze the host attack graph. What we care aboutare the paths from initial attack states to goal attackstates. The most interesting paths are the ones thatare “minimal”. VulSAN generates all the minimalattack paths.

Figure 1 shows the overview of our approach.The interesting result from the host attack graph is the

attack paths. An attack path is a path that starts from aninitial attack state and ends with a goal attack state. Sup-pose there are two attack paths p1 and p2, and we haveV (p1) ⊂ V (p2) (V (p) represents the set of edge labelsalong the path). Then we are not interested in p2 since itis easier to realize p1 than to realize p2. An attack path pis desirable when there does not exist another attack path

p′ such that V (p′) ⊂ V (p). We call such paths minimalpaths.

We define the vulnerability surface of a protectionsystem as the set of all minimal attack paths. Each pathincludes the programs that must be exploited to realizethe attack objective.

When we compare two protection systems A and Bunder the same attack scenario, we first generate the setsof all minimal attack paths of the two protection sys-tems, called PA and PB . For any path p ∈ PA, we say:

• p is a strong path if there exists a path p′ ∈ PB suchthat V (p) ⊂ V (p′).

• p is a weak path if there exists a path p′ ∈ PB suchthat V (p) ⊃ V (p′).

• p is a common path if there exists a path p′ ∈ PB

such that V (p) = V (p′).

• p is a unique path otherwise.

When comparing A and B, a common path shows acommon way to exploit both systems. A strong path pof system A suggests that, if the attacker compromisesthe same programs in p under system B, she will need tocompromise more programs to achieve the attack objec-tive in B. A weak path p of A suggests that, compromis-ing a subset of the programs in p under B already helpsthe attacker to achieve the objective in B. A unique pathp of A suggests that A is more vulnerable than B be-cause by realizing p, an attacker can compromise A butnot B. By examining the strong, weak, common, andunique attack paths in details, we can better understandthe differences of QoP between two systems.

There are two approaches to use the sets of minimalattack paths to compare the QoP of two systems. In oneapproach, one makes no assumption about whether oneprogram is easier to compromise than another program.In this approach, one could only partially order the QoPas measured by the host vulnerability surfaces of dif-ferent systems. PA has higher QoP than PB when allminimal attack paths for PA are either common paths orweak paths. That is, for every minimal attack path p forPA, either PB has the same path, or there exists a pathp′ for PB that contains a strict subset of the programs inp, which means that p′ is easier to exploit than p. Thestrength of this approach is that the comparison result re-mains valid even when some programs are significantlyeasier to exploit than other programs. The drawback isthat often times two protection systems are not directlycomparable. Most of the analysis in this paper use thisapproach.

In the second approach, one views each programas one unit, implicitly assuming that all programs areequal. By making this assumption, it is possible tocome up with a total order among all protection sys-tems. However, the drawback is that the validity of theassumption is questionable. In a few head-to-head com-parisons in this paper, we use this approach. Wheneverwe do so, we will explicitly state the assumption that allprograms are considered equal.

The ideal solution is to be able to quantify the effortsneeded to exploit different programs. However, this isa challenging open problem that appears unlikely to besolved anytime soon.

4 Our Tool

VulSAN consists of the following components: theFact Collector, the Host Attack Graph Generator, andthe Attack Path Analyzer.

4.1 Fact Collector

Fact Collector retrieves information about the systemstate and security policy, and encodes the information asfacts in Prolog.

The information about file system consists of facts ofall relevant files, system users, system groups and run-ning processes. Several sample Prolog facts are depictedin Figure 2. We only consider system facts that are rel-evant to our security analysis. Irrelevant information,like CPU/memory consumption of a process, is not con-sidered. Whether a piece of system information is rele-vant to our analysis depends on the system rules (whichwill be discussed later), and the MAC system to be ana-lyzed. Some facts are security-relevant under all protec-tion mechanisms, like uid/gid of a process; while somefacts are unique to a particular mechanism, like securitycontexts in SELinux and process profiles in AppArmor.

The encoding of Prolog facts for security policiesvary for different security mechanisms. For example, inSELinux policies, there are several kinds of statements,e.g., Type Enforcement Access Vector Rules and TypeEnforcement Transition Rules. We also define all thedomains and types. Figure 3 gives several sample Pro-log facts which are generated based on a SELinux pol-icy. Our parser for SELinux policy is based on the toolcheckpolicy.

In AppArmor, a profile defines the privileges of acertain program. A privilege can be a capability, or aset of permissions over a file or file pattern. Figure 4

(1) file_info(path(’/usr/bin/passwd’),type(regular), owner(0), group(0),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’),se_type(’bin_t’)).

(2) user_info(’root’, 0, 0).(3) group_info(’mail’, 8, [dovecot]).(4) process_running(4412, 0, 0,

’/usr/lib/postfix/master’,system_u, system_r, initrc_t).

(5) process_networking(4412).

(1) is the fact for file /usr/bin/passwd. The fact encodes thefile name, type, owner, group, user/group/world permissions, se-tuid/setguid/sticky bit, and security context of the file. (2) is the factfor root user, which includes the user name, user id and group id. (3)is the fact for mail group, which includes the group name, group idand group members. (4) is the fact for the postfix master process. Thefact contains the process id(pid), user id(uid), group id(gid), executedprogram, and the security context of the process. (5) is the fact for thesame process as (4), denoting that the process is open to network.

Figure 2. Sample Facts of System State

(1) dom_priv(’user_ssh_t’, ’bin_t’, ’file’,[’ioctl’, ’read’, ’getattr’, ’lock’,’execute’, ’execute_no_trans’]).

(2) se_typetrans(old_dom(’user_ssh_t’),new_dom(’user_xauth_t’),type(’xauth_exec_t’)).

(3) se_domain(’user_ssh_t’).(4) se_type(’bin_t’).

(1) says a process running under domain ‘user ssh t’ has the followingpermissions over a file with type ‘bin t’: ioctl, read, getattr, etc. Thefact is derived from a TE Access Vector Rule. (2) says if a process run-ning under domain ‘user ssh t’ executes an executable file with type‘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)says ‘user ssh t’ is a SELinux domain. (4) says ‘bin t’ is a SELinuxtype. Facts like (3) and (4) are used to enumerate SELinux domainsand types.

Figure 3. Sample Facts of SELinux Policy

(1) aa_capability(’/usr/lib/postfix/master’,’net_bind_service’).

(2) aa_access_mode(’/usr/lib/postfix/master’,’/etc/samba/smb.conf’, r(1), w(0),ux(0), px(0), ix(0), m(0), l(0)).

(1) says the program /usr/lib/postfix/master has the capability ofnet bind service. (2) says the program can read samba configure file/etc/samba/smb.conf. Facts like (2) define the privileges of a programover a certain file or file pattern.

Figure 4. Sample Facts of AppArmor Policy

gives some sample Prolog facts of an AppArmor pol-icy. Our parser for AppArmor policy is based on appar-mor parser.

4.2 Host Attack Graph Generator

Host Attack Graph Generator takes system facts, alibrary of system rules and the attack scenario as input,and generates the host attack graph. We first discuss howto define attack states.

In our analysis, the basic unit is a process. Theattack state of a process consists of process attributesthat are related to access control enforcement. Uidand gid of a process are used in Linux DAC mech-anism, which is the default mechanism. MAC sys-tems give additional process attributes. In SELinux,the current domain of a process is a security related at-tribute. Hence the attack state of a process is describedas proc(uid, gid, domain). In AppArmor, an attack stateis represented as proc(uid, gid, profile) where profile isthe profile that confines the process.

Given the attack state of a process controlled by theattacker, the privileges available to the attacker is definedby the policy. For example, under SELinux, a processwith a certain domain can only have a certain set of per-missions. Permissions also depend on the uid and gid.Figure 5 gives some relevant predicates to describe suchenforcement.

Suppose the attacker controls a process p, she mayexploit or launch a program prog to further control an-other attack state. We are interested in all the potentialattack states that might be controlled by an attacker.

In SELinux, we represent the fact that theattacker can control a certain attack state asse node(proc(uid, gid, domain)). If the attackercontrols attack state s1, and after exploiting a programprog she can control attack state s2, the transition isrepresented as se edge(s1, s2, prog). Here se node(·)and se edge(·, ·, ·) are both dynamic predicates inProlog. The state transition depends on the currentattack state, the compromised program and the policy.

As one example of system rules, we now discuss howto encode domain transition under SELinux. The logicto decide domain transition is described in [23], and isnon-trivial. Suppose the current domain is OldDom, thetype of the executable is Type and the new domain isNewDom. We summarize the logic as follows:

1. If OldDom doesn’t have file execute permission onType, the access is denied.

2. If there is a type transition rule: ‘type transition

dac can execute(Uid, Gid, Program) : Decide if a process withcertain uid and gid can execute a program.

dac execve(Uid, Gid, NewUid, NewGid, Program) : Decide thenew uid and gid of a process after executing a program.

se can execute prog(Domain, Program, NewDomain) : Decide if aprocess with certain domain can execute a program, and what the newdomain is after execution.

aa file privilege(Profile, File, Mode) : Decide if a process with acertain profile can access a file with a certain mode, e.g., read, write,execute.

aa new profile(Profile, Program, NewProfile) : Get the new profileof a process after executing a program. A profile can be ‘none’meaning there is no profile confining the process.

Figure 5. Sample System Rules

se_can_execute_type(Domain, Type, NewDomain) :-se_typetrans(old_dom(Domain),

new_dom(NewDomain), type(Type)),!,se_domain_privilege(domain(Domain),

type(Type), class(file), op(execute)),se_domain_privilege(domain(Domain),

type(NewDomain), class(process),op(transition)),

se_domain_privilege(domain(NewDomain),type(Type), class(file), op(entrypoint)).

se_can_execute_type(Domain, Type, NewDomain) :-se_domain_privilege(domain(Domain),

type(Type), class(file), op(execute)),se_domain_privilege(domain(Domain), type(Type),

class(file), op(execute_no_trans)),NewDomain = Domain.

Figure 6. Rules for Domain Transition

OldDom Type: process NewDom’, the access isgranted only when OldDom has process transitionpermission on Type and NewDom has file entry-point permission on Type. Otherwise the access isdenied. If the access is granted, the process runs onthe domain NewDom after executing the program.

3. If there isn’t such a type transition rule, the ac-cess is granted only when OldDom has file exe-cute no trans permission on Type. Otherwise theaccess is denied. If the access is granted, the pro-cess runs on the original domain OldDom after ex-ecuting the program.

Using logic programming the domain transition logiccan be encoded naturally. Related Prolog code is shownin Figure 6.

The initial resources of the attacker can be repre-sented as a set of initial attack states. Suppose the at-tacker can connect to the machine from the network, theinitial attack states are encoded in Figure 7(a). Simi-

net_init(proc(Uid,Gid,Domain), [Program]) :-process_networking(Pid),process_running(Pid, Uid, Gid, Program,

_, _, Domain).

(a) Initial resources: the attacker can connect to the machine fromnetwork

load_module_goal(proc(0, _Gid, Domain)) :-se_domain_privilege(domain(Domain), _,

class(capability), op(sys_module)).

(b) Attack objective: to load a kernel module

Figure 7. Predicates for Initial AttackStates and Goal Attack States

1: function GENERATE GRAPH NODE(s)2: if s is already a graph node then3: return4: Add s as a graph node5: if s is a goal attack state then6: return7: for all program prog that s can execute do8: s′ ← the attack state after executing prog9: Add (s, s′) as a graph edge with label prog

10: Generate Graph Node(s′)

1: function GENERATE HOST ATTACK GRAPH2: for all Initial attack state s do3: Generate Graph Node(s)

Figure 8. Algorithm for Host Attack GraphGeneration

larly, we use a set of goal attack states to represent theobjective of the attacker. The encoding of the objectiveto load a kernel module is depicted in Figure 7(b).

Given the initial attack states and the goal attackstates, we can generate the host attack graph that con-tains all the potential states that the attacker can control.The pseudo code is depicted in Figure 8.

4.3 Attack Path Analyzer

Attack Path Analyzer finds all the minimal attackpaths in a host attack graph. Figure 9 describes the it-erative algorithm used by Attack Path Analyzer. The al-gorithm repeatedly updates a set of paths for each nodeuntil all the sets are stablized.

1: function GENERATE MINIMAL ATTACK PATHS2: V ← V ∪ vg3: for all goal attack state node v do4: add an edge from v to vg ,5: the exploited program for the edge is empty6: for all v ∈ V do7: MP(v)← φ8: for all initial attack state node v do9: MP(v)← {φ}

10: repeat11: stable← true12: for all e ∈ E do13: for all p ∈ MP(e.v1) do14: p′ ← append(p, e)15: if ∃p0 ∈ MP(e.v2) s.t. V (p′) ⊂ V (p0) then16: Remove all such paths from MP(e.v2)

17: if not ∃p1 ∈ MP(e.v2) s.t. V (p′) ⊃ V (p1) then18: MP(e.v2)←MP(e.v2) ∪ {p′}19: stable← false20: until stable21: return MP(vg)

Symbols MeaningV The set of host attack graph nodesE The set of host attack graph edgesvg The virtual “goal” node added such that each goal

attack state has an edge to vgMP MP(v) stores the set of minimal attack paths to

node ve.v1, e.v2 The starting node and ending node of an edge eV (p) The set of all exploited programs along the path pappend(p, e) Append edge e to the end of path p

Figure 9. Minimal Attack Paths Generation

4.4 Tool Status

We have implemented VulSAN in Linux. VulSANhas been used to evaluate SELinux and AppArmor inseveral Linux distributions. We plan to further improvethe tool and release it to the public in the future (possi-bly under the terms and conditions of the GNU GeneralPublic License (GPL)).

5 Comparing SELinux with AppArmor

We use three attack scenarios to evaluate our ap-proach. The first is for a remote attacker to install arootkit. We assume the rootkit is installed by loadinga kernel module. The second is for a remote attacker toplant a Trojan horse. We use two definitions of trojanattacks: (1) the attacker can create an executable in afolder on the executable search path or user’s home di-rectory (2) the attacker can create an executable in anyfolder such that a normal user process (with a user’s uidand runs under unconfined domain in SELinux or is notconfined by any profile in AppArmor) can execute. In

both cases, after the trojan program is executed the pro-cess should be unconfined. We call (1) a strong trojancase and (2) a weak trojan case. The third is for a localattacker to install a rootkit.

We analyze the QoP under several configurations:

1. Ubuntu 8.04 (we use the Server Edition for all thetest cases) with SELinux and Ubuntu 8.04 with Ap-pArmor. To understand what additional protec-tion MAC offers on top of DAC, we also evalu-ate Ubuntu 8.04 with DAC protection only (withoutMAC protection).

2. Fedora 8 with SELinux and SUSE Linux EnterpriseServer 10 with AppArmor. We compare the resultswith Ubuntu 8.04/SELinux and Ubuntu 8.04/Ap-pArmor to show that different distributions with thesame mechanism provide different levels of protec-tion.

3. Ubuntu 8.04 with SELinux. In the evaluation, weonly analyze the SELinux policy. We use the resultto show that only considering MAC policy withoutDAC policy and system state is not sufficient.

The active services include: sshd, vsftp, apache2,samba, mysql-server, postfix, nfsd, named, etc. In Fe-dora 8, the SELinux policy is the targeted policy thatshipped with the distribution. In Ubuntu 8.04, theSELinux policy is the reference policy that comes withthe selinux package. The AppArmor policy is the onethat comes with the apparmor-profiles package.

5.1 SELinux vs. AppArmor vs. DAC only onUbuntu 8.04

Ubuntu 8.04 Server Edition supports both SELinuxand AppArmor. This offers an opportunity for us tocompare the QoP of SELinux and AppArmor head tohead. We also include the case in which only DAC isused in the comparison.

A Remote Attacker to Install a Rootkit In this attackscenario, the attacker has network access to the host, andthe objective is to install a rootkit via loading a kernelmodule. The host attack graphs for DAC only, AppAr-mor and SELinux are shown in Figure 10, Figure 11 andFigure 12, respectively. The comparison of minimal at-tack paths between SELinux and AppArmor is shown inFigure 13.

Among the three cases, AppArmor has the small-est vulnerability surface. SELinux has all the minimalattack paths AppArmor has and some additional ones.

init

proc(0, 0)

/usr/sbin/apache2

/usr/sbin/cupsd

/usr/sbin/nmbd

/usr/sbin/rpc.mountd

/usr/sbin/smbd

/usr/sbin/sshd

/usr/sbin/vsftpd

proc(1, 1)

/sbin/portmap

proc(106, 0)

/sbin/rpc.statd

proc(108, 117)

/usr/sbin/named

proc(110, 119)

/usr/sbin/mysqld

proc(101, 102)

/sbin/dhclient

proc(0, 1)

/bin/mount

/bin/ping

/bin/ping6

/bin/su

/bin/umount

/sbin/mount.nfs

/usr/bin/arping

/usr/bin/chfn

/usr/bin/chsh

/usr/bin/gpasswd

/usr/bin/mtr

/usr/bin/newgrp

/usr/bin/passwd

/usr/bin/sudo

/usr/bin/sudoedit

/usr/bin/traceroute6.iputils

/usr/lib/eject/dmcrypt-get-device

/usr/lib/openssh/ssh-keysign

/usr/lib/pt_chown

/bin/mount

/bin/ping

/bin/ping6

/bin/su

/bin/umount

/sbin/mount.nfs

/usr/bin/arping

/usr/bin/chfn

/usr/bin/chsh

/usr/bin/gpasswd

/usr/bin/mtr

/usr/bin/newgrp

/usr/bin/passwd

/usr/bin/sudo

/usr/bin/sudoedit

/usr/bin/traceroute6.iputils

/usr/lib/eject/dmcrypt-get-device

/usr/lib/openssh/ssh-keysign

/usr/lib/pt_chown

proc(0, 117)

/bin/mount

/bin/ping

/bin/ping6

/bin/su

/bin/umount

/sbin/mount.nfs

/usr/bin/arping

/usr/bin/chfn

/usr/bin/chsh

/usr/bin/gpasswd

/usr/bin/mtr

/usr/bin/newgrp

/usr/bin/passwd

/usr/bin/sudo

/usr/bin/sudoedit

/usr/bin/traceroute6.iputils

/usr/lib/eject/dmcrypt-get-device

/usr/lib/openssh/ssh-keysign

/usr/lib/pt_chown

proc(0, 119)

/bin/mount

/bin/ping

/bin/ping6

/bin/su

/bin/umount

/sbin/mount.nfs

/usr/bin/arping

/usr/bin/chfn

/usr/bin/chsh

/usr/bin/gpasswd

/usr/bin/mtr

/usr/bin/newgrp

/usr/bin/passwd

/usr/bin/sudo

/usr/bin/sudoedit

/usr/bin/traceroute6.iputils

/usr/lib/eject/dmcrypt-get-device

/usr/lib/openssh/ssh-keysign

/usr/lib/pt_chown

proc(0, 102)

/bin/mount

/bin/ping

/bin/ping6

/bin/su

/bin/umount

/lib/dhcp3-client/call-dhclient-script

/sbin/mount.nfs

/usr/bin/arping

/usr/bin/chfn

/usr/bin/chsh

/usr/bin/gpasswd

/usr/bin/mtr

/usr/bin/newgrp

/usr/bin/passwd

/usr/bin/sudo

/usr/bin/sudoedit

/usr/bin/traceroute6.iputils

/usr/lib/eject/dmcrypt-get-device

/usr/lib/openssh/ssh-keysign

/usr/lib/pt_chown

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

init

proc(0, 0, none)

/usr/sbin/apache2

/usr/sbin/rpc.mountdproc(0, 0, /usr/sbin/sshd)

/usr/sbin/sshd

proc(108, 117, none)

/usr/sbin/mysqld

proc(109, 118, none)

/usr/sbin/named

/bin/bash

proc(0, 117, none)

/bin/mount

/bin/ping6

/bin/su

/bin/umount

/sbin/mount.nfs

/usr/bin/arping

/usr/bin/chfn

/usr/bin/chsh

/usr/bin/gpasswd

/usr/bin/mtr

/usr/bin/newgrp

/usr/bin/sudo

/usr/bin/sudoedit

/usr/bin/traceroute6.iputils

/usr/lib/eject/dmcrypt-get-device

/usr/lib/openssh/ssh-keysign

/usr/lib/pt_chown

proc(0, 118, none)

/bin/mount

/bin/ping6

/bin/su

/bin/umount

/sbin/mount.nfs

/usr/bin/arping

/usr/bin/chfn

/usr/bin/chsh

/usr/bin/gpasswd

/usr/bin/mtr

/usr/bin/newgrp

/usr/bin/sudo

/usr/bin/sudoedit

/usr/bin/traceroute6.iputils

/usr/lib/eject/dmcrypt-get-device

/usr/lib/openssh/ssh-keysign

/usr/lib/pt_chown

Figure 11. Host Attack Graph for a Remote Attacker to Install a Rootkit (Ubuntu 8.04 withAppArmor)

init

proc

(0,

0, u

ncon

fine

d_t)

/usr

/sbi

n/ap

ache

2

/usr

/sbi

n/nm

bd

/usr

/sbi

n/rp

c.m

oun

td

/usr

/sbi

n/s

mbd

/usr

/sbi

n/v

sftp

d

pro

c(1,

1,

unc

onfi

ned_

t)

/sbi

n/po

rtm

ap

proc

(106

, 0,

unco

nfin

ed_t

)

/sbi

n/r

pc.s

tatd

proc

(108

, 11

7, u

ncon

fine

d_t

)

/usr

/sbi

n/na

med

proc

(0,

0, c

upsd

_t)

/usr

/sbi

n/c

upsd

pro

c(0,

0,

sshd

_t)

/usr

/sbi

n/ss

hd

pro

c(11

0, 1

19,

unc

onfi

ned_

t)

/usr

/sbi

n/m

ysql

d

proc

(101

, 1

02,

dhcp

c_t)

/sbi

n/dh

clie

nt

proc

(0,

1, u

nco

nfin

ed_t

)

/bin

/pin

g

/bin

/pin

g6

/bin

/su

/sbi

n/m

oun

t.nf

s

/usr

/bin

/arp

ing

/usr

/bin

/ch

fn

/usr

/bin

/ch

sh

/usr

/bin

/gpa

ssw

d

/usr

/bin

/mtr

/usr

/bin

/new

grp

/usr

/bin

/pas

swd

/usr

/bin

/su

do

/usr

/bin

/sud

oedi

t

/usr

/bin

/tra

cero

ute6

.ipu

tils

/usr

/lib

/eje

ct/d

mcr

ypt-

get-

devi

ce

/usr

/lib

/ope

nssh

/ssh

-key

sign

/usr

/lib

/pt_

chow

n

proc

(0,

1, u

ncon

fin

ed_m

oun

t_t)

/bin

/mou

nt

/bin

/um

ount

/bin

/pin

g

/bin

/pin

g6

/bin

/su

/sbi

n/m

ount

.nfs

/usr

/bin

/arp

ing

/usr

/bin

/chfn

/usr

/bin

/chsh

/usr

/bin

/gpa

ssw

d

/usr

/bin

/mtr

/usr

/bin

/new

grp

/usr

/bin

/pas

swd

/usr

/bin

/sud

o

/usr

/bin

/sud

oed

it

/usr

/bin

/tra

cero

ute6

.iput

ils

/usr

/lib

/eje

ct/d

mcr

ypt

-get

-dev

ice

/usr

/lib

/ope

nssh

/ssh

-key

sign

/usr

/lib

/pt_

chow

n

proc

(0,

0, u

ncon

fine

d_m

oun

t_t)

/bin

/mou

nt

/bin

/um

ount

pro

c(0

, 1

17,

unco

nfin

ed_t

)

/bin

/pin

g

/bin

/pin

g6

/bin

/su

/sbi

n/m

ount

.nfs

/usr

/bin

/arp

ing

/usr

/bin

/chf

n

/usr

/bin

/chs

h

/usr

/bin

/gpa

ssw

d

/usr

/bin

/mtr

/usr

/bin

/new

grp

/usr

/bin

/pas

swd

/usr

/bin

/sud

o

/usr

/bin

/sud

oedi

t

/usr

/bin

/tra

cero

ute6

.ipu

tils

/usr

/lib

/eje

ct/d

mcr

ypt-

get-

devi

ce

/usr

/lib

/ope

nssh

/ssh

-key

sign

/usr

/lib

/pt_

chow

n

proc

(0,

117,

unc

onfi

ned_

mou

nt_t

)

/bin

/mou

nt

/bin

/um

ount

proc

(0,

42,

syst

em_

chkp

wd_

t)

/sbi

n/u

nix_

chkp

wd

proc

(0,

119,

unc

onfi

ned_

t)/bin

/pin

g

/bin

/pin

g6

/bin

/su

/sbi

n/m

ount

.nfs

/usr

/bin

/arp

ing

/usr

/bin

/chf

n

/usr

/bin

/chs

h

/usr

/bin

/gpa

ssw

d

/usr

/bin

/mtr

/usr

/bin

/new

grp

/usr

/bin

/pas

swd

/usr

/bin

/sud

o

/usr

/bin

/sud

oedi

t

/usr

/bin

/tra

cero

ute6

.ipu

tils

/usr

/lib

/eje

ct/d

mcr

ypt-

get-

devi

ce

/usr

/lib

/ope

nssh

/ssh

-key

sign

/usr

/lib

/pt_

chow

n

proc

(0,

119,

unc

onfi

ned_

mou

nt_t

)

/bin

/mou

nt

/bin

/um

ount

proc

(0,

102,

dhc

pc_t

)/bin

/mou

nt

/bin

/pin

g

/bin

/pin

g6

/bin

/su

/bin

/um

ount

/lib

/dh

cp3-

clie

nt/c

all-

dhcl

ient

-scr

ipt

/sbi

n/m

ount

.nfs

/usr

/bin

/arp

ing

/usr

/bin

/ch

fn

/usr

/bin

/ch

sh

/usr

/bin

/gpa

ssw

d

/usr

/bin

/mtr

/usr

/bin

/new

grp

/usr

/bin

/pas

swd

/usr

/bin

/sud

o

/usr

/bin

/sud

oedi

t

/usr

/bin

/tra

cero

ute6

.ipu

tils

/usr

/lib

/eje

ct/d

mcr

ypt-

get-

dev

ice

/usr

/lib

/op

enss

h/ss

h-ke

ysig

n

/usr

/lib

/pt_

chow

n

Figure 12. Host Attack Graph for a RemoteAttacker to Install a Rootkit (Ubuntu 8.04with SELinux)

The DAC only case has all the attack paths SELinuxhas, and has one additional minimal attack path. Morespecifically, AppArmor has 3 length-1 minimal attackpaths and 34 length-2 minimal attack paths. In additionto these, SELinux has 3 more length-1 minimal attackpaths and 63 more length-2 minimal attack paths.

Attack paths common to all three cases are mainlydue to daemon programs that run in unconfined domainunder SELinux (meaning that the program is not con-strained by SELinux) and are not confined by profilesunder AppArmor. The length-1 paths are due to thedaemon programs apache2, rpc.mountd and sshd whichrun as root. (Although sshd is running in sshd t underSELinux and confined by a profile in AppArmor, thedomain and the profile both allow the process to load akernel module directly or indirectly). The length-2 pathsare due to unprivileged daemon programs mysqld andnamed. After compromising one of them, the attackerneeds to do another local privilege escalation.

The minimal attack paths that SELinux has but Ap-pArmor doesn’t have are due to three reasons: (1) Someprograms are running in the unconfined t domain underthis version of SELinux policy, while AppArmor hasprofiles for them; these include, e.g., nmbd, smbd, vs-ftpd, portmap, and rpc.statd. (2) Some programs areconfined by SELinux domains, but the confinements arenot as tight as corresponding AppArmor profiles. Twoprograms, cupsd and dhclient, fall into this category.For example, domain dhcpc t is allowed to load a ker-nel module while the profile /sbin/dhclient doesn’t allowkernel module loading. (3) Some programs (named andmysqld) are not confined either in SELinux or AppAr-mor. However, because they run with unprivileged ac-counts (as opposed to the root) under DAC, compromis-ing them do not enable the attacker to load a kernel mod-ule. There are unique attack paths for SELinux becauseof the confinement of some setuid root programs. Pingand passwd are unconfined in SELinux but confined inAppArmor, therefore they can be used to further esca-late the attackers’ privileges after compromising namedor mysqld.

Somewhat surprisingly, the DAC only case has onlyone additional (strong) length-1 minimal attack pathcompared to SELinux. The path is /usr/sbin/cupsd. Thecupsd daemon runs as root and is confined by the cups tdomain of SELinux. When the attacker exploits cupsdwith SELinux enabled, she has to additionally exploitthe setuid root program /bin/unix chkpwd to gain theprivilege to install a rootkit.

Our analysis shows that among the seven network-facing programs running as root in Ubuntu 8.04 Server

SELinux compared to AppArmorcommon /usr/sbin/apache2

/usr/sbin/rpc.mountd/usr/sbin/named SUID*/usr/sbin/mysqld SUID*/usr/sbin/sshd

unique /usr/sbin/nmbd/usr/sbin/smbd/usr/sbin/vsftpd/sbin/portmap SUID**/sbin/rpc.statd SUID**

/usr/sbin/cupsd /sbin/unix chkpwd/sbin/dhclient SUID**/sbin/dhclient /lib/dhcp3-client/call-dhclient-script

/usr/sbin/named /bin/ping/usr/sbin/named /usr/bin/passwd/usr/sbin/mysqld /bin/ping/usr/sbin/mysqld /usr/bin/passwd

SUID* represents a set of setuid root programs:/bin/ping6/bin/su/sbin/mount.nfs/usr/bin/arping/usr/bin/chfn/usr/bin/chsh/usr/bin/gpasswd/usr/bin/mtr/usr/bin/newgrp/usr/bin/sudo/usr/bin/sudoedit/usr/bin/traceroute6.iputils/usr/lib/eject/dmcrypt-get-device/usr/lib/openssh/ssh-keysign/usr/lib/pt chown/bin/mount/bin/umount

SUID** includes all programs in SUID* and also/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,smbd, sshd, and vsftpd, only one of them is confined inany meaningful way by the SELinux policy. Hence onecan argue that the additional protection provided by theSELinux reference policy in Ubuntu 8.04 is quite lim-ited.

Remote Attacker to Leave a Trojan HorseWe consider a scenario in which the attacker is re-

mote and wants to leave a Trojan horse. We considerboth the strong Trojan horse case and the weak Trojanhorse case. We observe that performing a strong trojanattack is always not more difficult than installing a ker-nel module.

For Ubuntu 8.04 with AppArmor, compared to load-ing kernel module, there is one extra attack path instrong trojan attack: /usr/sbin/smbd. For Ubuntu 8.04with SELinux, the host attack graph is the same as thegraph for a remote attacker to install a rootkit.

It’s significantly easier to perform weak trojan at-tacks. Figure 14 shows the host attack graph to leavea weak trojan in Ubuntu 8.04 with SELinux. Every net-work faced program, if compromised, can be used di-rectly to leave a weak Trojan horse. This is so due totwo reasons. First, both SELinux and AppArmor con-fine only a subset of the known programs and leave anyprogram not explicitly identified as confined. Second,

as neither SELinux nor AppArmor performs informa-tion flow tracking, the system cannot tell a program leftby a remote attacker from one originally in the system.

A Local Attacker to Install a RootkitIn the third attack scenario, the attacker has a local ac-

count. The objective is to install a rootkit (load a kernelmodule). Figure 15 and Figure 16 shows the host attackgraphs for Ubuntu 8.04 with SELinux and AppArmor,respectively.

Again, AppArmor has a smaller vulnerabilitysurface. All minimal exploit paths in AppArmoralso occur in SELinux, which has some additionalexploit paths. There are 19 common minimal attackpaths, they are all of length 1. They are due to 19setuid root programs that have sufficient privileges.These programs are /bin/fusermount, /bin/ping6,/bin/su, /sbin/mount.nfs, /usr/bin/arping, /usr/bin/chfn,/usr/bin/chsh, /usr/bin/gpasswd, /usr/bin/mtr,/usr/bin/newgrp, /usr/bin/sudo, /usr/bin/sudoedit,/usr/bin/traceroute6.iputils, /usr/lib/eject/dmcrypt-get-device, /usr/lib/openssh/ssh-keysign, /usr/lib/pt chown,/usr/sbin/pppd, /bin/mount, /bin/umount.

The programs in the common paths are setuid rootprograms. The result shows that the way for a localuser to load a kernel module is to exploit one of the se-tuid root programs. SELinux has 2 unique minimal at-

init

proc(0, 0, unconfined_t)

/usr/sbin/apache2

/usr/sbin/nmbd

/usr/sbin/rpc.mountd

/usr/sbin/smbd

/usr/sbin/vsftpd

proc(1, 1, unconfined_t)

/sbin/portmap

proc(106, 0, unconfined_t)

/sbin/rpc.statd

proc(108, 117, unconfined_t)

/usr/sbin/named

proc(0, 0, cupsd_t)

/usr/sbin/cupsd

proc(0, 0, sshd_t)

/usr/sbin/sshd

proc(110, 119, unconfined_t)

/usr/sbin/mysqld

proc(101, 102, dhcpc_t)

/sbin/dhclient

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

init

proc(1000, 1000, unconfined_t)

proc(0, 1000, unconfined_t)

/bin/fusermount

/bin/ping

/bin/ping6

/bin/su

/sbin/mount.nfs

/usr/bin/arping

/usr/bin/chfn

/usr/bin/chsh

/usr/bin/gpasswd

/usr/bin/mtr

/usr/bin/newgrp

/usr/bin/passwd

/usr/bin/sudo

/usr/bin/sudoedit

/usr/bin/traceroute6.iputils

/usr/lib/eject/dmcrypt-get-device

/usr/lib/openssh/ssh-keysign

/usr/lib/pt_chown

/usr/sbin/pppd

proc(0, 1000, unconfined_mount_t)

/bin/mount

/bin/umount

Figure 15. Host Attack Graph for a LocalAttacker to Install a Rootkit (Ubuntu 8.04with SELinux)

tack paths for SELinux: /bin/ping and /usr/bin/passwd.They are due to the same reason in the first scenario,that SELinux does not confine ping and passwd whileAppArmor confines them.

5.2 Other Comparisons

In this subsection we compare the QoP offered bydifferent Linux distributions with a same MAC mech-anism. We also discuss why considering MAC policyalone is not enough.

Different Versions of SELinuxWe have found that the SELinux policy in Fedora 8,

init

proc(1000, 1000, none)

proc(0, 1000, none)

/bin/fusermount

/bin/mount

/bin/ping6

/bin/su

/bin/umount

/sbin/mount.nfs

/usr/bin/arping

/usr/bin/chfn

/usr/bin/chsh

/usr/bin/gpasswd

/usr/bin/mtr

/usr/bin/newgrp

/usr/bin/sudo

/usr/bin/sudoedit

/usr/bin/traceroute6.iputils

/usr/lib/eject/dmcrypt-get-device

/usr/lib/openssh/ssh-keysign

/usr/lib/pt_chown

/usr/sbin/pppd

Figure 16. Host Attack Graph for a LocalAttacker to Install a Rootkit (Ubuntu 8.04with AppArmor)

which is the SELinux targeted policy, offers signifi-cantly better protection than the SELinux in Ubuntu 8.04Server Edition, which uses a version of the SELinux ref-erence policy. In addition, the most current version ofthe SELinux reference policy is also tighter than the pol-icy shipped with Ubuntu 8.04.

Figure 17 shows the host attack graph for a remoteattacker to install a rootkit in Fedora 8 with SELinux.The vulnerability surface is not directly comparable withthat of Ubuntu 8.04 (shown in Figure 12) because eachhas some unique attack paths. If we assume that allprograms are equal, the vulnerability surface of Fe-dora 8/SELinux is smaller because there is 1 length-1 minimal attack path and 13 length-2 minimal attack

paths in Fedora 8/SELinux, while there are 6 length-1 minimal attack paths and 97 length-2 minimal attackpaths in Ubuntu 8.04/SELinux.

init

proc(0, 0, initrc_t)

/usr/sbin/rpc.rquotadproc(0, 0, sshd_t)

/usr/sbin/sshd

proc(0, 0, dhcpc_t)

/sbin/dhclient

proc(0, 0, unconfined_t)

/bin/bash

/bin/zsh/etc/rc.d/init.d/ntpd

proc(0, 0, ifconfig_t)

/sbin/ethtool

/sbin/ifconfig

/sbin/ip

/sbin/iwconfig

/sbin/mii-tool

/sbin/tc

proc(0, 0, insmod_t)

/sbin/insmod

/sbin/insmod.static

/sbin/modprobe

/sbin/rmmod

Figure 17. Host Attack Graph for a RemoteAttacker to Install a Rootkit (Fedora 8 withSELinux)

Figure 18 shows the host attack graph for a remote at-tacker to leave a strong trojan in Fedora 8 with SELinux.Compared to the kernel module loading scenario, tro-jan attack scenario has three additional minimal attackpaths:

/usr/sbin/rpc.mountd/usr/sbin/smbd/usr/sbin/sendmail /usr/bin/procmail

Two paths are related to file sharing and the other is dueto sendmail. Those programs are confined, but they haveprivileges to write to the user’s home directory or di-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 ofUbuntu 8.04/SELinux for the remote trojan attack sce-nario.

init

proc(0, 0, nfsd_t)

/usr/sbin/rpc.mountd

proc(0, 0, smbd_t)

/usr/sbin/smbd

proc(0, 0, initrc_t)

/usr/sbin/rpc.rquotadproc(0, 51, sendmail_t)

/usr/sbin/sendmail

proc(0, 0, sshd_t)

/usr/sbin/sshd

proc(0, 0, dhcpc_t)

/sbin/dhclient

proc(0, 51, procmail_t)

/usr/bin/procmail

proc(0, 0, unconfined_t)

/bin/bash

/bin/zsh/etc/rc.d/init.d/ntpd

Figure 18. Host Attack Graph for a RemoteAttacker to Leave a Strong Trojan (Fedora8 with SELinux)

Different Versions of AppArmor

We have analyzed the vulnerability surface of SUSELinux Enterprise Server 10 (SLES 10) with AppArmorprotection. To keep the services in SLES 10 the same asin Ubuntu 8.04, some services that are up by default inSLES 10 are turned off, e.g., slpd and zmd.

The vulnerability surface of SLES 10/AppArmor un-der the scenario that a remote attacker wants to installa rootkit (as shown in Figure 19) is not directly com-parable with that of Ubuntu 8.04/AppArmor. The twodistributions expose different vulnerability surfaces.

init

proc(4, 7, none)

/usr/sbin/cupsd

proc(0, 0, none)

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

/usr/sbin/sshd

proc(0, 7, none)

/bin/eject

/bin/mount

/bin/ping6

/bin/su

/bin/umount

/opt/gnome/lib/libgnomesu/gnomesu-pam-backend

/opt/gnome/sbin/change-passwd

/opt/kde3/bin/kpac_dhcp_helper

/sbin/unix2_chkpwd

/usr/X11R6/bin/Xorg

/usr/bin/at

/usr/bin/chage

/usr/bin/chfn

/usr/bin/chsh

/usr/bin/crontab

/usr/bin/expiry

/usr/bin/gpasswd

/usr/bin/gpg

/usr/bin/mandb

/usr/bin/newgrp

/usr/bin/opiepasswd

/usr/bin/opiesu

/usr/bin/rcp

/usr/bin/rlogin

/usr/bin/rsh

/usr/bin/sudo

/usr/lib/pt_chown

/usr/sbin/suexec2

proc(4, 13, none)

/usr/lib/news/bin/inews

proc(0, 13, none)

/usr/lib/news/bin/inndstart

/usr/lib/news/bin/startinnfeed

/bin/ash

/bin/bash

/bin/tcsh

/bin/zsh

/sbin/nologin

Figure 19. Host Attack Graph for a RemoteAttacker to Install a Rootkit (SUSE LinuxEnterprise Server 10 with AppArmor)

The common attack paths are through sshd andrpc.mountd (NFS mount daemon). The unique paths forUbuntu 8.04 are through apache2, mysqld and named,due to that those programs are not confined. The uniquepaths for SLES 10 are through cupsd since cupsd is notconfined. Sshd also contributes to some unique pathssince there are more shells installed in SLES 10.

In SLES 10, the host attack graph for a remote at-tacker to plant a strong Trojan horse is the same as thegraph for a remote attacker to install a rootkit. For a lo-cal attacker to install a rootkit, the host attack graph forSLES 10 is shown in Figure 20. There are 10 commonattack paths due to unconfined set uid root programs.There are 9 unique attack paths for Ubuntu 8.04 and 20unique attack paths for SLES 10.

The Need to Consider DAC PolicyOur approach considers both the MAC policy and

init

proc(1000, 100, none)

proc(0, 100, none)

/bin/eject

/bin/mount

/bin/ping6

/bin/su

/bin/umount

/opt/gnome/lib/libgnomesu/gnomesu-pam-backend

/opt/gnome/sbin/change-passwd

/opt/kde3/bin/kpac_dhcp_helper

/sbin/unix2_chkpwd

/usr/X11R6/bin/Xorg

/usr/bin/at

/usr/bin/chage

/usr/bin/chfn

/usr/bin/chsh

/usr/bin/crontab

/usr/bin/expiry

/usr/bin/gpasswd

/usr/bin/gpg

/usr/bin/mandb

/usr/bin/newgrp

/usr/bin/opiepasswd

/usr/bin/opiesu

/usr/bin/rcp

/usr/bin/rlogin

/usr/bin/rsh

/usr/bin/sudo

/usr/lib/pt_chown

/usr/sbin/suexec2

proc(1000, 13, none)

/usr/lib/news/bin/inews

proc(0, 13, none)

/usr/lib/news/bin/inndstart

/usr/lib/news/bin/startinnfeed

Figure 20. Host Attack Graph for a LocalAttacker to Install a Rootkit (SUSE LinuxEnterprise Server 10 with AppArmor)

the DAC policy. If we only consider MAC policy, e.g.,SELinux policy, the result may not be accurate. Fig-ure 21 shows the host attack graph for a remote attackerto install a rootkit, when we only consider SELinux pol-icy but not DAC policy. Compared to the host attackgraph that considers both DAC and MAC policy (shownin Figure 12), we observe that without consideringDAC policies, there are following extra length-1 attackpaths: /sbin/portmap, /sbin/rpc.statd, /usr/sbin/mysqld,/usr/sbin/named, /sbin/dhclient. They are not accurate.For example, mysqld is running with uid 110 and un-confined t. By compromising mysqld the attacker cancontrol unconfined t, but she still cannot load a kernelmodule because the uid is unprivileged. To control rootuid the attacker needs to do another exploit, e.g., by ex-ploiting a setuid root program.

init

unconfined_t

/sbin/portmap

/sbin/rpc.statd

/usr/sbin/apache2

/usr/sbin/mysqld

/usr/sbin/named

/usr/sbin/nmbd

/usr/sbin/rpc.mountd

/usr/sbin/smbd

/usr/sbin/vsftpd

cupsd_t

/usr/sbin/cupsd

sshd_t

/usr/sbin/sshd

dhcpc_t

/sbin/dhclient

system_chkpwd_t

/sbin/unix_chkpwd

Figure 21. Host Attack Graph for a RemoteAttacker to Install a Rootkit (Ubuntu 8.04with SELinux – only Considering SELinuxPolicy)

5.3 Performance

In our experiments, the targeted operating systems(Ubuntu, Fedora and SUSE Linux) are installed in vir-tual machines using VMWare. The host attack graphgeneration and attack path analysis are performed on alaptop with Intel(R) Pentium(R) M processor 1.80GHzand 1G memory. The Prolog engine is swi-prolog5.6.14.

The running time for the fact collector is less than 10minutes for every test case. The running time for thehost attack graph generation and analysis is less than 10minutes for every test case.

6 Conclusions

In this paper, we propose an approach to analyzeand compare the protection quality offered by policiesof different Mandatory Access Control mechanisms insecurity-enhanced operating systems. Our analysis isbased on the security policy, system state and systemconfiguration. We develop a tool to generate the host at-tack graph for a given attack scenario. We propose touse vulnerability surface to measure the protection qual-ity of a system. We evaluate our approach by analyz-ing and comparing SELinux and AppArmor in severalLinux distributions.

6.1 Acknowledgements

This work is supported by NSF CNS-0448204 (CA-REER: Access Control Policy Verification Through Se-curity Analysis And Insider Threat Assessment), and bysponsors of CERIAS. We also thank the anonymous re-viewers for NDSS and the shepherd of our paper CrispinCowan for valuable comments that have greatly im-proved the paper.

References

[1] Apparmor application security for linux.http://www.novell.com/linux/security/apparmor/.

[2] Apparmor development.http://developer.novell.com/wiki/index.php/Apparmor.

[3] Selinux for distributions.http://selinux.sourceforge.net.

[4] D. E. Bell and L. J. LaPadula. Secure computersystems: Unified exposition and Multics interpre-tation. Technical Report ESD-TR-75-306, MitreCorporation, Mar. 1976.

[5] C. Cowan, S. Beattie, G. Kroah-Hartman, C. Pu,P. Wagle, and V. D. Gligor. Subdomain: Parsi-monious server security. In Proceedings of the14th Conference on Systems Administration (LISA2000), pages 355–368, Dec. 2000.

[6] T. Fraser. LOMAC: Low water-mark integrity pro-tection for COTS environments. In Proc. IEEESymposium on Security and Privacy, May 2000.

[7] T. Fraser. LOMAC: MAC you can live with. InProceedings of the FREENIX Track: USENIX An-nual Technical Conference, June 2001.

[8] J. D. Guttman, A. L. Herzog, J. D. Ramsdell, andC. W. Skorupka. Verifying information flow goalsin security-enhanced linux. Journal of ComputerSecurity, 13(1):115–134, 2005.

[9] B. Hicks, S. Rueda, L. S. Clair, T. Jaeger, and P. D.McDaniel. A logical specification and analysis forselinux mls policy. In SACMAT, pages 91–100,2007.

[10] S. Hinrichs and P. Naldurg. Attack-based domaintransition analysis. In Annual Security EnhancedLinux Symposium, 2006.

[11] M. Howard. Mitigate security risks by minimiz-ing the code you expose to untrusted users. MSDNMagazine, November 2004.

[12] M. Howard, J. Pincus, and J. M. Wing. Measuringrelative attack surfaces. In Proceedings of Work-shop on Advanced Developments in Software andSystems Security, December 2003.

[13] T. Jaeger, R. Sailer, and X. Zhang. Analyzing in-tegrity protection in the SELinux example policy.In Proceedings of the 12th USENIX Security Sym-posium, pages 59–74, August 2003.

[14] T. Jaeger, X. Zhang, and F. Cacheda. Policy man-agement using access control spaces. ACM Trans.Inf. Syst. Secur., 6(3):327–364, 2003.

[15] A. Leitner. Novell and red hat security experts faceoff on apparmor and selinux counterpoint. LinuxMagazine, (69), 2006.

[16] N. Li, Z. Mao, and H. Chen. Usable manda-tory integrity protection for operating systems. InProc. IEEE Symposium on Security and Privacy,May 2007.

[17] P. K. Manadhata, K. M. C. Tan, R. A. Maxion, andJ. M. Wing. An approach to measuring a system’sattack surface. Technical Report CMU-CS-07-146,CMU, August 2007.

[18] P. Naldurg, S. Schwoon, S. K. Rajamani, andJ. Lambert. NETRA: : seeing through access con-trol. In FMSE, pages 55–66, 2006.

[19] NSA. Security enhanced linux.http://www.nsa.gov/selinux/.

[20] X. Ou, W. F. Boyer, and M. A. McQueen. Ascalable approach to attack graph generation. InProceedings of the 13th ACM conference on Com-puter and communications security, pages 336–345, New York, NY, USA, 2006. ACM.

[21] B. Sarna-Starosta and S. D. Stoller. Policy analysisfor security-enhanced linux. In Proceedings of the2004 Workshop on Issues in the Theory of Security(WITS), pages 1–12, April 2004.

[22] O. Sheyner, J. Haines, S. Jha, R. Lippmann, andJ. M. Wing. Automated generation and analysis ofattack graphs. In Proceedings of the 2002 IEEESymposium on Security and Privacy, page 273,Washington, DC, USA, 2002. IEEE Computer So-ciety.

[23] S. Smalley, C. Vance, and W. Salamon. Im-plementing SELinux as a Linux security module.Technical Report 01-043, NAI Labs, December2001.

[24] Tresys technology, setools - policy anal-ysis tools for selinux. Available athttp://oss.tresys.com/projects/setools.

[25] G. Zanin and L. V. Mancini. Towards a formalmodel 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.