Application-Defined Decentralized Access Control · 2018-10-30 · Application-Deﬁned Decentralized Access Control Yuanzhong Xu Alan M. Dunn Owen S. Hofmann Michael Z. Lee Syed

Application-Defined Decentralized Access ControlYuanzhong Xu Alan M Dunn Owen S Hofmann lowast Michael Z Lee

Syed Akbar Mehdi Emmett WitchelThe University of Texas at Austin Google Inclowast

AbstractDCAC is a practical OS-level access control system thatsupports application-defined principals It allows normalusers to perform administrative operations within theirprivilege enabling isolation and privilege separation forapplications It does not require centralized policy spec-ification or management giving applications freedom tomanage their principals while the policies are still en-forced by the OS DCAC uses hierarchically-named at-tributes as a generic framework for user-defined policiessuch as groups defined by normal users For both localand networked file systems its execution time overheadis between 0ndash9 on file system microbenchmarks andunder 1 on applications

This paper shows the design and implementation ofDCAC as well as several real-world use cases includ-ing sandboxing applications enforcing server applica-tionsrsquo security policies supporting NFS and authenticat-ing user-defined sub-principals in SSH all with minimalcode changes

1 IntroductionContinued high-profile computer security failures anddata breaches demonstrate that computer security for ap-plications is abysmal While there is extensive researchinto novel security and access control models little ofthis work has an impact on practice Instead of appli-cations consistently reimplementing security vulnerabili-ties they need a practical and expressive way to use thor-oughly debugged system-level primitives to achieve bestsecurity practices

DCAC (DeCentralized Access Control) is our attemptto make modern security mechanisms practical for ac-cess control It has three distinguishing characteristics itis decentralized in privilege decentralized in policy spec-ification and allows application-defined principals andsynchronization requirements Although DCAC greatlyincreases the flexibility of access control it retains afamiliar model of operation with per-process metadatachecked against per-object ACLs to determine the al-lowed access It relies on the standard OS infrastructureof a hierarchical file namespace extended file attributesand file descriptors It is practical for distributed envi-ronments because it avoids requiring centralized storageconsistency or management

lowast Work completed while at the University of Texas at Austin

Decentralized privilege In Linux and Windows usersand groups are principals and can be assigned privilegesA user might consider creating another user (a ldquosub-principalrdquo) and assigning it a subset of her privilegesThis allows an application to run as the sub-principaland thus with restricted privileges compared to the casewhere the user directly runs the application However onLinux and Windows administrative functions on usersand groups require root privilege As a result current OS-level access control does not allow many applications torun with least privilege

DCAC decentralizes administrator privilege a nor-mal user can perform administrative operations withinher privilege like creating principals with subsets of herprivilege Privilege separation makes complex applica-tions more difficult to exploit But current systems re-quire administrative involvement to install and deployprivilege-separated software

For example the suEXEC feature of Apache HTTPServer allows it to run CGI and SSI programs under UIDsdifferent from the UID of the calling web server by usingsetuid binaries However creating UIDs for CGISSIprograms and setting up the setuid binaries requiresadministrator privilege Not only can use of administra-tive privilege require human involvement it also adds op-portunities for configuration mistakes that can actuallyharm security The suEXEC documentation1 warns theuser ldquoif suEXEC is improperly configured it can causeany number of problems and possibly create new holesin your computerrsquos security If you arenrsquot familiar withmanaging setuid root programs and the security issuesthey present we highly recommend that you not con-sider using suEXECrdquo By contrast DCAC allows formsof privilege separation like delegating user privileges tosub-principals that even in the case of a configurationmistake limit the effect of a compromise to the privi-leges of the original user

Decentralized policy specification OS-level accesscontrol typically defines its principals and policies in acentralized secure location such as the etcgroup

file the policyconf file in SELinux or a central pol-icy server (eg a Lightweight Directory Access Protocol(LDAP) server) DCAC decentralizes policy specifica-tion policies are stored in files and file metadata at arbi-trary locations DCAC generalizes the setuid mecha-nism of Unix allowing processes to use the file system

1 httphttpdapacheorgdocs24suexechtml

to gain fine-grained user-defined privileges (ie not justroot) With DCAC applications control their privilegeswith a mechanism implemented and enforced by the op-erating system but without central coordination

DCAC is particularly practical for distributed environ-ments eg where machines share a file system via NFSIn such an environment applications simply use the filesystem to express access control policy and any host thatmounts the file system will enforce identical access con-trol rules DCAC does not add its own synchronizationrequirements such as entries in a central database Ap-plications make all access control decisions with accessonly to their own files In contrast a centralized policyserver might become a bottleneck when policy queriesand updates are frequent as in many server applications

Application-defined principals attributes Attributesmake applications simpler and more secure by allowingthem to use access control implemented by the operatingsystem rather than reimplementing their own TraditionalOS principals such as users are heavy-weight abstrac-tions that cannot be directly used by applications eg aweb application that manages its own users

DCAC attributes are hierarchically named stringsStrings are separated into components by the ldquordquo char-acter The string ualice can represent the user Alicebut applications are free to define their own encodingsand even their own principals For example the stringp3871357771171 might be a principal referring to aprocess with identifier 387 started about 14 billion sec-onds after January 1 1970 appbrowserpasswordmight be a component of a browser that is responsiblefor storing and retrieving the userrsquos passwords A pro-cess may carry multiple attributes simultaneously

Practicality DCAC combines ideas from mandatoryaccess control (MAC) systems [7 16] sandboxing [6]and decentralized information flow control (DIFC) [915 17 21 29] into a practical access control system thatis fully backward compatible with current Linux WhileMAC and DIFC systems can provide stronger guaranteesthan DCAC they require far more effort to use and oftenstruggle with backward compatibility We believe thatapplication developers will incrementally improve thesecurity of their applications if presented with a simplesecurity programming model that introduces a minimumof new concepts and that can implement security idiomscommon in modern web-connected applications

The next section (sect2) provides motivating scenariosfor DCAC followed by an extended discussion of design(sect3) and relationship to Linux DAC (sect4) We describeour DCAC prototype (sect5) with a discussion of severalapplications we modified to use DCAC (sect6) We evaluateDCAC (sect7) discuss related work (sect8) and conclude (sect9)

2 Modern access control idiomsWe discuss three access control idioms common in to-dayrsquos web-connected applications that are difficult toachieve in modern systems sandboxing ad hoc shar-ing and managing users Because these idioms are notwell served by current system security abstractions ap-plications constantly reimplement these idioms and im-plement them poorly Section 32 shows how DCAC sup-ports them more naturally than current systems

Privilege separationSandboxing Suppose Alice wish-es to run a photo management program By default herprogram will run with the same privileges as her useraccount However routines for interpreting file formatsare often subject to exploitable bugs (such as in the zliblibrary used to decompress png files [1]) If Alice re-ceives photos from untrusted sources or even if Alicemakes a mistake all of her potentially sensitive files areendangered rather than just those that should be man-aged by her photo management application Runninguntrusted or partially-trusted applications has becomecommonplace as users frequently download applicationsfrom less than trusted sources or run applications that areoften exploitable such as pdf viewers

In order to separate her application into a separateprivilege domain Alice must contact an administrator tocreate a new user (eg alice-photos) potentially create anew group containing both her and alice-photos so thatshe may easily share files and install support for runningher desired application as the new user such as via asetuid binary While it is possible to enforce privilegerestriction without superuser support solutions that do sorequire complex application-level support (such as in theChromium web browser [6]) that are easy to get wrongwith disastrous results (eg the frequent exploits enabledby bugs in the Java VMrsquos sandboxing mechanism [2 3])

This scenario is an example of privilege separationa well-known technique for building secure applica-tions [20] where each component has only the minimalset of privileges necessary to operate Privilege separa-tion with OS support is coarse-grained such as user-controlled namespaces [13] (eg namespaces can con-trol access to mount points but not files or directories)

Ad hoc sharing Existing systems provide limited fa-cilities for sharing between users Suppose Alice wishesto share a file or directory with Bob She can directlysend the relevant data to Bob but if both users wish to beable to update the data they must manually communicateeach change She might change file or directory permis-sions to allow readwrite access to a group that containsboth Alice and Bob Unless this specific group alreadyexists Alice must rely on a system administrator to cre-ate a new group containing both users If she wishes toadd or remove users she must also rely on a superuser

Object (FileIPC object)

Processattribute setualice modifyubobphoto read

pmask 0555

Linux processcredentialsUID GIDs

default ACL

Attributegateway

Linux objectcredentialsUID GID permission bits

attribute ACL

attribute nameualicegmygrp

read= ualiceV gstudent

write = exec = modify =

read = modify =

UID-bit 0

Figure 1 Overview of processes objects and attribute gateways inDCAC

If the need to share files expires an administrator mustclean up stale groups

Facilities such as POSIX ACLs [4] allow users tocreate more expressive access control lists by specifyingmultiple users and groups who may read and write afile If Alice wishes to share with many users howevershe must either add each user to an ACL for each fileto be shared or again use a group whose membershipmay only be modified by the superuser Users should beable to define new groups of users without administratorsupport and use those groups in access control on theirfiles

Managing users Server applications often have ac-cess control requirements similar to those of operatingsystems with multiple users having different privilegesHowever such applications usually implement accesscontrol with manual checks in their own code Customsecurity code is a common source of security bugs asingle missed access check can expose sensitive data tounprivileged users However most non-trivial applica-tions leveraging OS access control for application se-curity must execute as different OS-level principals andhence require superuser privilege Such an applicationmust reserve user or group identifiers for its use duringinstallation and possibly during maintenance

3 DesignIn DCAC the OS enforces simple rules about hierar-chical strings (called attributes) that are stored in OS-managed process and file metadata Applications defineconventions for what attributes mean to them allowingthem to create access control abstractions that are en-forced by the OS

Hierarchical strings are a self-describing mechanismto express decentralized privilege where any extensionof an existing string represents a subset of the par-entrsquos privileges DCAC attributes have components sep-arated by a ldquordquo character ualice is a parent attribute

of ualicephoto The hierarchy allows regular usersto manage principals and policies without requiring asystem administrator For example Alice may define anew principal for running her photo application (egualicephoto) because she owns and controls ualice

Each process carries an attribute set which is inher-ited across process control events such as fork() andexec() A process also maintains a default ACL Simi-lar to Linuxrsquos umask files created by the process havetheir access control lists set to the processrsquo default ACL

Each object (such as a file or shared memory seg-ment) has an access control list containing rules that al-low processes to access the object based on attributes inthe processesrsquo attribute sets An access control list spec-ifies four access modes read write execute and mod-ify Each mode has an attribute expression and a pro-cess may access a file in a given mode if the processrsquo at-tribute set satisfies the attribute expression for that accessmode For example the read access mode might specifyualiceor gstudent which provides read access to userAlice and members of group student (see the read accessmode of the object in Figure 1)

Read write and execute access modes represent therwx permission bits in UNIX-like file systems The mod-ify mode specifies the permission to modify the filersquos ac-cess control list In UNIX-like systems the filersquos ownerimplicitly has the right to modify a filersquos access control

In DCAC each access mode has an attribute expres-sion in disjunctive normal form (DNF) without nega-tions For example a jpg file may have the followingaccess modes

read = (ualicephoto) or (ubobphoto)

write = (ualicephoto and ualiceedit)

exec = emptymodify = (ualice)

If a process has attribute set ubobphoto it can readthis jpg file but cannot write to it or modify its ACL

Broadly DCAC defines rules similar to existing dis-cretionary access control (DAC) in Linux and other sys-tems A processrsquo attribute set specifies the acting prin-cipal similar to a processrsquo UID and GID A filersquos accesscontrol list specifies which principals may access the filesimilar to permission bits which in conjunction with afilersquos owner and group specify access rights for a UIDand GID However DCAC is significantly more flexibleand decentralized A process can have many attributesin its attribute set without differentiating between usersand groups files can specify formulae for allowing pro-cesses access and there is no central mapping betweenstring identifiers understandable by the user and integersunderstandable by the system

Note that although we use u〈user〉 and g〈group〉throughout the paper to couch our discussion in terms ofusers and groups DCAC does not enforce any attribute

naming scheme Users and groups in DCAC exist onlyby convention

31 Adding and dropping attributes

DCAC allows a process to change its access control stateby modifying its attribute set Attribute set modificationallows users and applications to run different processeswith different privileges A process p can always drop anattribute from its attribute set but to add an attribute itmust satisfy one of the following rulesbull p has the parent of the requested attribute (eg ualice

is the parent of ualicephoto)bull p has permission to use an attribute gateway (dis-

cussed later in this section)A process can add attributes to its attribute set in

one of two modes read or modify depending on its at-tribute set and the configuration of attribute gatewaysRead mode enables a process to use an attribute Mod-ify mode adds control over granting the attribute to otherprocesses A process with an attribute in modify modecan always downgrade that attribute to read mode A pro-cess cannot upgrade an attribute to modify mode withouta gateway or a parent attribute in modify mode Whenextending an attribute by adding a new component theextended attribute has the same mode as the parent

Allowing a process to create and add attributes basedon hierarchy permits regular users to create new prin-cipals without requiring administrator privileges To en-able flexible application-defined resource sharing pro-cesses use attribute gateways to acquire attributes basedon user-defined rules

Decentralized policy via attribute gateways A pri-mary design goal for DCAC is decentralization Insteadof centralized credentials (eg etcgroup) or cen-tralized access policy (eg SELinuxrsquos policyconf)DCAC distributes credentials and access policy using at-tribute gateways which are a new type of file (in ourLinux implementation they are empty regular files withspecific extended attributes) An attribute gateway al-lows a process to add new attributes to its attribute setbased on its current attribute set An attribute gateway isa rights amplification mechanism like a setuid binarybut more flexible

An attribute gateway has only two access modes readand modify (execute and write are not used) If a pro-cessrsquo attributes fulfill an access mode for a gatewaythen the process may add the attribute to its set in thatmode For example Alice might tell her colleagues thatshe is starting a group with attribute ualicegatc fordocuments related to a submission to USENIX ATCShe sends email to the members of the group explain-ing that there is a gateway for the group in a file called˜alicegroupsatcgate Her collaborators modifytheir login scripts to open that attribute gateway as part

of their login process The gatewayrsquos read access modeconsists of a disjunction listing the user attributes for thegrouprsquos members (eg read = (ualice)or(ubob) )

Gateways decentralize credentials and access policyMultiple gateways (or no gateways) may exist for anyattribute with the location of the gateways and theiraccess controlled by users and convention DCAC doesnot force use of a central repository of credentials oraccess policy though users may choose to create and usecentralized repositories

Having an attribute in modify mode allows a processto decide which other principals can obtain the attributejust as having modify access to a file allows a process tocontrol which principals can access the file Specificallyhaving an attribute in modify mode allows a process tochange the access control list for any gateway for theattribute or to create new gateways for the attribute

Access policies should incur performance penaltiesonly for features they actually use [26] With a hierarchi-cal attribute namespace and decentralized attribute gate-ways different users and applications can perform ad-ministration in their own domains without contentionin contrast any administrative operations on UIDs andetcpasswd (for example) require central coordina-tion across the system

Gateway management Gateway management is upto users and their applications Since DCAC is a generickernel-level mechanism it does not impose requirementsfor gateway locations however specific system deploy-ments or applications can follow conventions such asa central repository of gateways (Similarly the Linuxkernel does not enforce the use of the etcpasswd

file making it general enough to support Androidrsquosapplication-based access control) While users can harmthemselves with incorrectly set gateway permissionsgateways do not add problems beyond those of currentsystems as there are already opportunities for self-harmwith standard file permissions For example a user canmake his or her ssh private key file world readable

DCAC allows gateways to be in any location whichcould result in a less regulated environment than in cen-tralized systems With current file permissions it is rela-tively easy (modulo perhaps setuid binaries) to determineexactly which users and groups may (transitively) accessa file Attribute gateways require an exhaustive searchof the filesystem to find all attributes that might allow agiven process access to a file On the other hand becauseit is easier to run processes with reduced privilege a usercould restrict her programs to only create gateways inspecific relevant directories

Summary We believe DCAC achieves a new balanceof expressivity and simplicity due to the featuresbull The attribute abstraction is generic An attribute can

represent a user a group a capability an application

or a category of files depending on the user or theapplicationrsquos need

bull Attributes are hierarchically named making privilegedelegation possible by extending existing attributes

bull Decentralized attribute gateways allow processes toacquire attributes that they would otherwise not beable to acquire strictly from attribute hierarchy Cre-ation of and policy for gateways is controlled by usersand applications

bull Attributes are self-explaining strings There is noneed to map attributes to other OS-level identifierslike UIDs Identical strings from different machinesrefer to the same attribute making attributes directlysharable This enables DCAC to support NFS (sect63)with minimal development effort

bull There is no rigid distinction between ldquotrustedrdquo andldquountrustedrdquo processes Instead process access bound-aries can be flexibly defined and flexibly delegated

32 DCAC supports modern access control idioms

Here we describe how DCAC supports the modern ac-cess control idioms described in sect2

Privilege separationSandboxing Suppose Alice wishesto run her photo manager in a separate restricted envi-ronment Alice invokes her photo manager with a simplewrapper that does the following1 Adds a ualicephoto attribute (allowed because Al-

icersquos process runs with the ualice attribute)2 Drops the ualice attribute3 Executes her photo applicationShe may similarly run her PDF reader in a separate re-stricted environment by following the same steps witha ualicepdf attribute Alice then sets up ACLs to al-low processes running with ualicephoto to access herphoto managerrsquos files and ualicepdf to access her pdfreaderrsquos files Each application may now access only itsown set of files In sect62 we show how DCAC helps tosandbox an application (Evince) with vulnerabilities

A DCAC-aware application may also enable finerprivilege separation between different components Sup-pose Alicersquos photo application wishes to isolate its filedecoding routines It may run those routines in a sep-arate process which carries the ualicephotoreaderattribute and drops the ualicephoto attribute The pro-gram can grant ualicephotoreader read-only accessto the photo files but nothing else to prevent an exploitfrom reading other files or writing any file

Ad hoc sharing Hierarchical attributes combined withpolicies for adding attributes to a processrsquo attribute setallow regular users to customize how they share filesSuppose that Alice (whose processes carry the ualiceattribute) wishes to share a file or set of files with agroup of users including Bob (see Figure 2) Rather than

gateway ACLFiles to share

attribute name

ualicegmygrpwrite =

read= ualicegmygrp

exec = modify =

read = ubobmodify =

Figure 2 Ad hoc sharing with DCAC Alice shares files by allowingualicegmygrp read access She then creates an attribute gatewayallowing ubob to add the attribute

updating each file every time she wants to share with anew user like Bob Alice instead does the following1 She creates a new attribute ualicegmygrp2 Alice creates a new attribute gateway for ualiceg-

mygrp (eg ˜alicegroupsmygrpgate) andsets its attribute formula for the read access mode to(ubob) Bob must learn the location of this file

3 Processes running as Bob can use Alicersquos new groupby locating the attribute gateway and using it to addthe attribute ualicegmygrp to their attribute setThese processes will be allowed the relevant access toany file with an ACL that matches ualicegmygrp

Alice can change membership of her group via ACLson the attribute gateway Note that the ad hoc group isa set of attributes besides OS users they may also repre-sent any application-defined principals Ad hoc sharingis used in our modified DokuWiki server in sect61

Managing users Consider a server application thatruns processes for multiple users and stores user datain files The server can use DCAC to implement ac-cess control by assigning different attributes to differentusersrsquo processes allowing application-level security re-quirements to be easily expressed as string attributes Forexample Linux user Alice runs myserver A user on theserver webuser is assigned an attribute set that has onlyualicemyserveruwebuser A server process servingwebuserrsquos requests can only access files which allow ac-cess to ualicemyserveruwebuser If the processesneed to share some common files the server can add acommon attribute ualicemyservercommon to theirattribute sets and add the attribute to the filesrsquo ACLsOur modified DokuWiki server (sect61) manages user andgroup permissions this way

If a server application executes on multiple machinesit only needs to synchronize on relevant policies underits management instead of updating them for the wholesystem Server applications do not need to synchronizeon a map between application-level users and OS-levelaccess control state

We apply DCAC to NFS (see sect63) While differentmachines still share a set of OS users and groups thatare already under centralized management application-defined principals and policies do not require centraliza-tion

Sub-principals delegating to sub-principals DCACallows flexible delegation to sub-principles address-ing one of the most vexing problems created by manyapplication-specific user management systems (such assshd and apache)

Consider the following Professor X and Professor Ywish to collaborate Y sends a credential (like a publickey) to X and X uses it to add Y as a sub-principal Y cannow access resources shared by X such as a subversionrepository holding a joint publication However Profes-sor Y recruits graduate student Z to actually do the workMost sub-principal systems are not flexible enough to al-low Y to delegate to Z without giving Z his credentialTherefore Y must talk to X and make him aware of ZXrsquos list is a centrally administered bottleneck

DCAC allows principals in a service to define andmanage their sub-principals without registering themwith the service in a centralized way Using DCAC Pro-fessor Y can provide Z a login without involving Profes-sor X and without revealing his credential to Z

We let a local user X have his own program sub-authto authenticate his sub-users The program is located at aknown per-user location in the system such as ˜Xsub-userssub-auth Xrsquos sub-auth program can definewhere the credentials of his sub-users are stored andhow to authenticate sub-sub-users For example it mayuse a file to store sub-usersrsquo credentials and delegateauthentication to the sub-user Thus Y a sub-user of Xwould have his own sub-auth program to authenticateYrsquos sub-users sect64 shows a detailed example of delega-tion for sub-users using sshd

DCAC does not require sub-auth programs nordoes it require particular naming conventions for themA user may authenticate sub-users with a chain of cer-tificates provided during login A sub-user would requirea certificate chain of length one a local user vouchingfor the sub-user A sub-sub-user must provide a chain oflength two and so on Such a scheme does not require lo-cal storage for credentials and each user must only vouchfor (and know about) their direct sub-users

4 Harmonious coexistence of DCAC andDAC

DCAC is designed to work harmoniously with Linuxrsquosexisting discretionary access control system (DAC) butit has mandatory access control (MAC) mechanisms toexpress policies more nuanced than what can be ex-pressed by DAC alone DCAC can augment a processrsquorights (eg allow Alicersquos calendar process to read a fileBobrsquos process wrote and shared with Alice) but it canalso restrict rights (eg limit Alicersquos photo reader fromreading her email)

Augmenting Linux DAC A DCAC system is permis-sive by default allowing access if DAC or DCAC checks

succeed By default files have empty ACLs so accesschecks reduce to DAC checks As a result all valid Linuxdisk images are valid DCAC disk images By preserv-ing DAC permissions DCAC can be deployed incremen-tally

Allowing access if DAC or DCAC checks succeedmakes sharing easy For example Alice may share a filewith Bob by simply adding ubob to the filersquos ACLIf instead we required DAC and DCAC access checksto succeed Alice would have to adjust permissions onmany of her files to start using DCAC (eg she wouldhave to make her authorized keys readable by sshd)

Restricting Linux DAC Using DCAC for restrictingLinux DAC permissions requires two additional pieces ofstate a pmask (permissions mask) and a UID-bit Eachprocess has a pmask and a UID-bit that are inheritedby child processes after a fork() and are maintainedacross exec() A process can only change its pmask bymaking it more restrictive (ie by clearing bits) and itcan only clear the UID-bit

The permissions mask is intended to prevent a processfrom reading or writing resources that Linuxrsquos DAC per-missions allow (eg because the UID of a process andfile owner match and the file owner has read access) Thepermissions mask is ANDed with standard DAC permis-sions bits before each permissions check So a DCACsystem will check (perms amp pmask) instead of permsTherefore pmask = 0777 does not restrict Linux DACwhile pmask = 0755 restricts write access to other usersrsquofiles and pmask = 0 causes all DAC permission checksto fail

Each process has a UID-bit which is intended tolimit the ambient authority granted to a process whenits UID matches the UID of a resource For examplecurrently in Linux a process may change the permissionson a file or directory with matching UID even if it hasno permissions on the file or its containing directoryIf the UID-bit is clear the process is restricted in thefollowing ways1 It can only change the DAC permissions and DCAC

ACLs of files with matching UID if it satisfies themodify access mode

2 kill and ptrace are restricted to child processes3 It cannot remove an IPC object change permissions

on it or lockunlock a shared memory segment un-less the DCAC check for the objectrsquos modify accessmode succeedsA process with the UID-bit set may modify DAC

permissions and ACLs for files and directories withmatching UIDs An unrestricted process (eg runningas root) with the UID-bit set can change DAC permis-sions and DCAC ACLs on any file or directory It canalso can send signals to any process

5 Prototype implementationWe implement a DCAC prototype by modifying Linux354

51 Programming interface

In DCAC attributes are managed through file descrip-tors When a process successfully adds an attribute it re-ceives a file descriptor for that attribute The correspond-ing kernel file object is a wrapper for the attribute Weuse system calls open openat and close to add anddrop attributes

bull int openat(int fd char suffix

int flags)If fd represents an attribute attr in the attribute setthis call adds attr〈suffix〉 and returns the asso-ciated file descriptor flags can be O RDONLY orO RDMOD representing that the requested access modeis read or modify (which subsumes read) If the par-ent attribute has only read mode requests for modifyaccess mode on the new attribute will be denied

bull int open(char pathname flags)If the file at pathname is an attribute gateway DCACwill evaluate the access modes according to flags

(O RDONLY or O RDMOD) On success the attributeis added and the corresponding file descriptor is re-turned Note that this operation does not open the ac-tual gateway file

bull int close(int fd)If fd represents an attribute that attribute is dropped

A potential issue with using file descriptors is compat-ibility with applications which are not aware of DCACSometimes applications close all open file descriptors asa clean-up step (since file descriptors persist on fork andexec) which results in unintended dropping of attributesTo address this problem we add a lock flag to eachprocessrsquo DCAC state When the flag is set the processrsquoDCAC state cannot be changed until the flag is clearedOne can set this flag in a wrapper and then invoke theapplication (see sect62) The lock flag is intended solely toease backward compatibility

A related complication of using file descriptors to rep-resent attributes is that programs may set the close on -

exec flag on their open file descriptors For instance ifbash is started as a login shell (where it needs to load theuserrsquos custom settings) it sets the close on exec flagon all file descriptors except the standard IO streamsThis can causes attributes to be dropped unintentionallyDCAC ignores close on exec for attributes

Besides open openat and close all other opera-tions are encoded into 4 new system calls Table 1 showsthe DCAC API

We additionally wrote a 274-line2 SWIG3 wrapper tomake DCAC functionality available in PHP

52 Processes and Objects

The core functionality of DCAC is implemented as aLinux security module (LSM [28])

Processes LSMs use a security field in the Linuxper kernel thread task struct structure to store thesecurity context of a process The DCAC state for akernel thread includes the attribute set default ACLpmask and the UID-bit all of which are stored in astructure pointed to by the security field (see sect4)

In a multi-threaded application each thread can haveits own DCAC state Threads can thus run on behalfof different principals and access control decisions arebased on their individual DCAC state which would beuseful for a trusted uncompromised server applicationHowever running untrusted code in a thread can lead toloss of isolation between principals in case of a compro-mise as threads share the same address space

Files For persistent file systems DCAC requires sup-port for extended attributes File permission (read writeexecute and modify) ACLs are stored in filesrsquo extendedattributes with the entire ACL encoded in a single ex-tended attribute For attribute gateways the attribute con-trolled by the gateway and its ACLs (read and modify)are encoded in a single extended attribute

Permission checks happen only when files are openedand not on subsequent readswrites The permissioncheck occurs in the inode permission LSM hook Theinode permission hook is a restrictive hook whichmeans it cannot grant access if a request is already deniedby the Linux DAC However DCAC allows access if ei-ther DAC or DCAC is satisfied (sect4) Therefore in addi-tion to LSM we modify 4 lines of code in fsnameic

to achieve DCACrsquos semantics

ACL cache DCAC keeps a generic in-memory ACLcache for each file in the VFS layer There are two mo-tivations for such a cache First it reduces performanceoverhead for remote file systems (eg NFS) Secondit makes DCAC usable for non-persistent file systems(eg sysfs) The in-memory inode structure contains ani security field where DCAC stores the ACL cacheThe cache is initialized (from the filersquos extended at-tributes) when the ACL is first needed when a DACpermission check fails The cache also records each filersquoschange time (ctime) when the ACL is fetched The cacheprovides a mechanism for file systems to invalidate ACLentries to enforce filesystem coherence semantics Thectime value in each cache entry can be used to deter-

2 All line counts httpwwwdwheelercomsloccount3 httpwwwswigorg

Sys call API Functionality

dcac addint dcac add any attr

Add the the attribute attr for root user only(const char attr int flags)

dcac acl

int dcac set def acl Set an access mode specified by mode in the(const char dnf int mode) processrsquo default ACL to dnfint dcac set file acl(const char file Set one access mode in the filersquos ACL to dnfconst char dnf int mode)int dcac set attr acl(int afd int ffd Createchange a gateway afd and ffd are fileconst char read const char mod) descriptors of the attribute and the gateway file

dcac info

int dcac get attr fd(const char attr) Get the file descriptor of the attribute attrint dcac get attr name Get the string representation of the attribute(int fd char buf int bufsize) associated with fdint dcac get attr list Store the file descriptors of all the attributes of(int buf int bufsize) the process to buf

dcac mask

int dcac set pmask(short mask) Set pmask to (pmask amp mask)void dcac clear uid enable(void) Clear the UID-bitvoid dcac lock(void) Lock the processrsquo DCAC statesvoid dcac unlock(void) Unlock the processrsquo DCAC states

Table 1 DCAC API

mine whether the entry needs to be invalidated becausechanging the extended attribute causes a ctime change

IPC objects The Linux kernelrsquos IPC object data struc-tures share a common credential structure kern ipc -

perm [28] where the DCAC ACL is stored DCACchecks permissions to access these objects in LSM multi-ple hooks We changed 6 lines in ipcutilsc to allowaccess if DAC or DCAC allows it

53 Attribute management

Using the rules described in sect31 a process can only addnew attributes based on existing attributes in its attributeset To initialize attribute state our Linux DCAC imple-mentation allows processes running as root to add anyattribute to their attribute sets with arbitrary modes (reador modify) We then modify system binaries such aslogin to initialize the attribute state for user processeslogin is already responsible for initializing a processrsquoUID and GID state by reading the etcpasswd andetcgroup files and invoking system calls such assetuid and setgroups We extend this responsibilityto include attributes

Our examples use ualice to represent an attributecorresponding to a specific Linux user We encode thisconvention in our prototype by changing login toadd the u〈username〉 attribute with both read andmodify access modes to user login shells Similarlyg〈grpname〉 attributes represent Linux groups andthey are added with only read mode since only roothas administrative control of them Modifying login

required a 28 line change to the shadow 4151 packageWe also modify sshd and the LightDM desktop man-

ager4 to set up the attribute state when the user logs in

4 httpwikigentooorgwikiLightDM

remotely or via a graphical user interface We changed37 lines of code in OpenSSH 59 and 20 lines of code inLightDM 121

6 DCAC application implementationWe demonstrate several use cases of DCAC in real appli-cations

61 Application-defined permissions in DokuWiki

DokuWiki5 is a wiki written in PHP that stores individualpages as separate files in the filesystem As a resultOS file-level permissions suffice for wiki access controlIn fact access control only requires setting attributesand default file ACLs on login Then the OS ensuresthat all ACL checks occur properly without need forapplication-level logic

We add a 246-line DCAC module to DokuWikirsquoscollection of authentication modules DokuWiki withDCAC executes in a webserver initialized with theappsdokuwiki attribute Upon user login the web-server process acquires a user-specific attribute apps-dokuwikiu〈username〉 and drops appsdokuwikiDefault ACLs on all created files are set to the user-specific attribute The server permits anonymous pagecreation and access through a common attribute apps-dokuwikicommon DokuWiki runs as a CGI script toensure a new process with the appsdokuwiki attributehandles each request restricting the impact of a compro-mise during a request to the logged in user Otherwisea reused compromised process could affect other userswhen it acquires their attributes during a new request

DokuWiki has a built-in ACL system that is onlycontrollable by superusers We modify DokuWiki tosupport user-created groups To do this we create a

5 httpwwwdokuwikiorg

new directory to hold gateway files with a directoryper wiki user When a user creates a group she alsocreates a gateway file to attribute appsdokuwiki-u〈username〉g〈groupname〉 with the name of thegroup in a per-user location defined by a DokuWiki nam-ing convention The gateway file has read permissionfor the members of the group Each userrsquos group direc-tory is traversable (has execute permission) by all usersWhen a user is informed (out of band) that she has beenadded to a new group she records the group name andgateway path name in her groups file We have a usermodify her own groups file to ensure that her groups arenot disclosed by arbitrary access to a common file Dur-ing login the DCAC authentication module reads theuserrsquos groups file and attempts to access gateways andadd group attributes

We add calls to DokuWikirsquos XML RPC interfaceto use this group functionality setPerms(pageNameperms) allows the DCAC permissions of wiki files to beadjusted setGroup(groupName members) modifiesthe membership of the group named groupName Fi-nally getMyGroups and setMyGroups allow a user toactivate the additional privileges given to her by groupsby modifying her groups file

62 Sandboxing Evince

We implement an application wrapper that sets up DCACstate for an application such as the default ACL UID-bitpmask and attribute set The wrapper can perform user-specified work (via scripts) before application execution(eg granting a sandboxed application permissions toa specific file) and after application termination Witha wrapper DCAC can sandbox unmodified applicationsbecause DCAC state is inherited across fork and exec

We port a simple stack-based buffer overflow target-ing an old version of Evince (evince-061) to test thesandboxing ability of DCAC Since document viewersgenerally do not need write permission we can sand-box Evince by clearing its UID-bit and setting itspmask = 0115 by using the application wrapper Weallow execute permission for directory traversal and al-low read for world-readable files so Evince can load itsshared libraries Additionally to allow evince to openthe target pdf file the wrapper keeps ualiceevince inthe attribute set and adds it to the pdf filersquos ACL Thewrapper can reset the filersquos ACL after Evince terminatesUpon triggering the exploit the attacker only has accessto world readable files and even a shell opened via anexploit remains confined

63 NFS

In a normal NFS environment machines are withinthe same trust domain and share a common set of OSusers and groups which usually requires centralizedmanagement By adopting an attribute naming conven-

tion for users and groups (such as u〈username〉 andg〈grpname〉) DCAC eliminates centralized manage-ment A user can define her own sub-principals and man-age them in her own way on all machines

The Linux NFS implementation does not support ex-tended attributes but we ported a patch for NFSv3 [18] toadd extended attribute support In addition to the patchwe also modified 326 lines of code for NFS in the Linuxkernel source

The NFSv3 specification [24] does not define how aserver should check permissions In the NFS implemen-tation in Linux a client OS checks permissions when afile is opened but the server does not check permissionfor subsequent read calls or for write calls on the filesthat belong to the processrsquo user It only checks permis-sion for write calls on files that belong to a differentuser We remove this extra check in DCAC We believethat this change is sensible since under this change NFSfiles still obey the standard UNIX convention where per-missions are checked only on open

Clients must make DCAC access control decisionsas they have access to a processrsquo attributes as well asthe resourcersquos (eg filersquos) attributes However creatingor removing files and directories requires write access tothe parent directory and in Linux NFS the client simplyforwards these operations to the server without checkingpermissions In DCAC if a client uses attributes to de-termine that a create or remove operation is legal itappends a hash of the cached ACL for the parent direc-tory in its RPC to the server The server checks the hashagainst the ACL and if they match it knows the clienthas an up-to-date copy and can trust the clientrsquos deci-sion to allow the operation While NFS servers trust theirclients this check is to ensure that clients do not makewrong decisions based on stale permissions In additionDCAC appends the processrsquo default ACL to create andmkdir calls to initialize ACLs on newly created files anddirectories

For regular files DCAC also uses the ACL cache todetermine permission when they are opened To guaran-tee close-to-open consistency [24] the cache is invali-dated when a ctime change is observed

64 Managing sub-users in SSHD

We modify 81 lines of sshd to support the access controlmodel described in Section 32

Modern versions of sshd support a forced commandoption which allows unprivileged users to authenticatesub-principals with public keys via the svnserve pro-gram Arguments to svnserve control details like theuser name for sub-principals (because sub-principalsdo not have user names in etcpasswd) Howeversvnserve does not allow the kind of flexible delegationdescribed in the next example

Authentication example When sshd receives a loginrequest for XY it invokes Xrsquos sub-auth program withonly Xrsquos privilege and passes to it the sub-user name ldquoYrdquoand the credentials the request provides If the sub-authprogram returns successfully sshd approves this requestand restricts XYrsquos privilege by properly setting the at-tribute set pmask and UID-bit

For a more concrete example consider a hierarchy ofusers XYZ described here and illustrated in Figure 3

1 When XYZ tries to login using ssh he providesusername ldquoXYZrdquo and some credential

2 sshd invokes Xrsquos sub-auth program passing sub-username ldquoYZrdquo and the credential to it with UID setto Xrsquos and only uX in the attribute set

(a) Xrsquos sub-auth finds that it is one-level down itkeeps only uXY in the attribute set and restrictspmask and UID-bit

(b) It execrsquos Yrsquos sub-auth passing sub-usernameldquoZrdquo and the credential to it Yrsquos sub-auth verifiesthe credential and returns successfully

3 Now sshd knows the request is authenticated Beforeexecrsquoing the shell sshd keeps only uXYZ in theattribute set and restricts pmask and UID-bit

Note that another OS user A can have a completelydifferent sub-auth program His sub-auth programmay be based on certificate chains and does not needfurther lower-layer sub-auth programs For exampleA can sign a certificate for Brsquos public key as AB and Bcan sign another certificate for Crsquos public key as ABCWhen ABC logs in he needs to provide the two certifi-cates to be verified by Arsquos sub-auth as well as a proofthat he has Crsquos private key such as a signature

7 EvaluationWe measure the performance overhead of DCAC throughboth targeted benchmark programs and representativeapplications Our benchmarking systems had quad-coreIntel Core2 266 GHz CPUs 8 GB of RAM and a 160GB 7200 RPM disk All servers and clients were con-nected by gigabit Ethernet

71 Microbenchmarks

Filesystem We run the Reimplemented Andrew Bench-mark (RAB) [19] a version of the Andrew benchmarkscaled for modern systems on both a local ext4 filesys-tem and NFSv3

RAB initially creates 100 files of 1 KB each and mea-sures the time for the following operations (1) creationof a number of directories (2) copying each of the 100initial files to some of these directories (3) executing thedu command to calculate disk usage of the files and di-rectories and (4) using grep to search all file copies for

Login requestUsername XYZPassword

sshdroot privilege

fork and exec

Xs sub-authWith Xs UID

XYs sub-auth

With Xs UID

Search in file ~XsubusersYsubuserssubusersdbfor entry username=Z password=password matches

exec parametersProgram ~Xsubuserssub-authUsername YZPassword

exec parametersProgram ~XsubusersYsubuserssub-authUsername ZPassword

DCAC stateAttributes uXYpmask = 0005UID-bit = 0

DCAC stateAttributes uXpmask = 0777UID-bit = 1

sshdroot privilege

exits successfully

With Xs UID

DCAC stateAttributes uXYZpmask = 0005UID-bit = 0

fork and exec

Figure 3 Authentication of sub-users in our modified sshd supportfor arbitrary nesting of sub-principals

mkdir copy du grep amp sum

DCAC no check check wr 32B ACL check wr 256B ACLcheck rd+wr 32B ACL check rd+wr 256B ACL

Figure 4 RAB results on local ext4 and NFSv3 20000 directories arecreated in the mkdir phase and 100 files of 1 KB each are copied to 500directories in the copy phase The slowdown is relative to unmodifiedLinux

a short string and checksumming all the files The exactnumber of operations varied depending on category (ext4or NFS) and is described with the corresponding figuresResults are shown in Figure 4

We compare the results for the following casesbull The baseline which uses an unmodified Linux kernel

FSTime (micros)

chmodChanging DCAC file ACL32B ACL 256B ACL

ext4 124 219 427NFSv3 224 228 238

Table 2 Time to change the ACL of a file compared to chmod

bull DCAC kernel where the default ACL is empty andACLs on files are not checked DCAC adds at most1 overhead on local ext4 and NFS

bull DCAC kernel where the default ACL only containsthe write access mode DCAC ACL checks occur forevery write access On local ext4 the overhead is 0to 4 for a 32B ACL and 0 to 8 for a 256B ACLOn NFS the overhead is below 4

bull DCAC kernel like the prior case but DCAC ACLchecks occur for both read and write accesses Onlocal ext4 the overhead is 1 to 4 for a 32B ACLand 2 to 9 for a 256B ACL On NFS the overheadis below 5On ext4 the kernel stores extended attributes within

inodes if they are below a certain size threshold With256-byte inodes 32 bytes is below this threshold 256bytes is not so extra disk blocks must be allocated re-sulting in larger overhead in the mkdir and copy phaseswhere new files are created For the du phase and thegrep and sum phase observed differences correspond towhether read ACLs are being checked and differ littlefor ACL sizes This is likely because DCAC reads ACLsfrom ACL caches for most of the time

On NFS the number of round trips per operationdominates the performance overhead for disk storage forextended attributes on the server is negligible in compar-ison Most of the time DCAC reads ACLs from the ACLcaches which does not incur network communicationOn the creation of a file or directory DCAC appends theinitial ACL to the create or mkdir RPC instead of us-ing a separate setxattr RPC As a result DCAC addsvery small overhead on NFS

ACL manipulation We compare the time it takes tochange the ACL of a file to chmod in Linux Table 2shows that on a local ext4 changing ACLs can be 17timesto 34times slower than chmod depending on the size ofthe ACL on NFSv3 ACL size has a small impact onperformance and the time spent for changing ACLs iscomparable to chmod (under 65)

IPC DAC and DCAC check permission for sharedmemory segments and named pipes only when theyare attached to the processrsquo address space or openedhowever every up or down operation on a System Vsemaphore requires a permission check We measure theoverhead induced on semaphore operations by DCACACL checks The baseline comes from the DCAC kernel

Setup Baseline DCACTime (ns) 279 355 (127times)

Table 3 Overhead for a semaphore operation

FS Time (s)baseline check wr check rdampwr

ext4 1973 1983 (101times) 2012 (102times)NFSv3 3221 3254 (101times) 3257 (101times)

Table 4 Kernel compile time averaged over 5 trials ldquocheck wrrdquomeans the DCAC write access modes on output files and directoriesare checked ldquocheck rdrdquo means the DCAC read access modes on thesource files are checked ldquobaselinerdquo means using unmodified kernelThe size of each ACL is 256 bytes

where DAC permission checks always succeed so noACL checks ever occur The DCAC measurement comesfrom removing a processrsquos DAC permissions by settingits pmask to 0 and giving it an attribute The semaphoreis accessible to processes with this attribute Thus weensured that a DCAC ACL check is performed on ev-ery semaphore operation We measure the average timeper semaphore operation over a long sequence that al-ternated between up and down (measuring the averageoverhead of both) and set the initial semaphore value sothat no semaphore opertion blocks Table 3 shows 27slowdown for a semaphore operation requiring a DCACpermission check

72 Macrobenchmarks

Kernel compile We measure the time to compile theLinux kernel (version 354 without modules) Table 4shows the overhead is negligible for both an ext4 filesys-tem and NFS DCAC only performs additional permis-sion checks on file open creation and deletion Theamount of time spent on these operations is small enoughcompared to the computation involved in a kernel com-pile to cause low overhead

DokuWiki We benchmark DokuWiki by playing backa set of modifications made to the DokuWiki website(which is itself run using DokuWiki) This is a set of6430 revisions of 765 pages We made a set of requeststo a wiki with a 90 read workload Each write operationreplaces a page of the wiki with the next version in theset of revisions that we have We measured the total wallclock time for 16 clients to perform 100 requests apieceagainst the wiki The baseline is the wiki running onthe same machine with the same kernel but no attributesapplied to any files and using standard authenticationResults are in Table 5 DCAC authentication and plainauthentication results were within margin of error of eachother This is expected as DCAC merely adds a fewsystem calls to operations that otherwise have a lot ofcomputation and file IO through running PHP scripts

Setup Baseline DCACTime (s) 455plusmn 07 453plusmn 07

Table 5 Wall clock times for 16 clients to complete 100 requests apieceto DokuWiki Standard deviations are determined from 10 trials

Systems Relation to DCAC

Sandboxes Focus on isolation DCAC also accommo-dates fine-grained sharing

Flexible policyspecification

Focus on completeness rather than usabil-ity DCAC strives for balance

Application- anduser- definedaccess control

DCAC provides fine-grained control sup-ports network filesystems

New securitymodels

DCAC concepts easier to understandcloser to traditional users and groups

Table 6 Comparing DCAC with related systems

8 Related workDCAC is most directly inspired by two systems Cap-sicum [27] and UserFS [14] Capsicum shows that pro-grammers want and will use system abstractions thatmake writing secure code easier Capsicum implementsa fairly standard capability model for security its in-novation is in casting file descriptors an abstraction fa-miliar to Unix programmers as a capability DCAC ap-plies this insight by representing attributes as file descrip-tors Capsicumrsquos capability mode is similar to DCACrsquospmask and DCACrsquos UID-bit in that they are both usedto deprivilege a process and restrain its ambient author-ity granted by legacy access control systems howeverDCACrsquos pmask and UID-bit are more fine-grained ndashthey can selectively restrict a processrsquo ability to performdifferent operations on different files

UserFS [14] leverages existing OS protection mecha-nisms to increase application security by explicitly main-taining a hierarchy of UIDs to represent principals Un-fortunately system-wide UIDs are awkward for dynamicprincipals For example independent server applicationswould contend for UIDs even though their principalsare in logically separated domains Moreover in a dis-tributed setting groups of machines would need to syn-chronize on what UIDs are currently in use DCAC isdesigned to work well where UserFS strugglesmdashhighlydynamic distributed deployments within a single admin-istrative domain

There are too many access control systems and pro-posals to analyze them all so we describe the novel com-bination of features in DCAC by contrasting with entireclasses of access control systems with modern exem-plars Table 6 summarizes our analysis

Sandboxing Many projects try to isolate (ldquosandboxrdquo)potentially malicious code from the rest of the systemAndroid repurposes UIDs to isolate mutually distrusting

applications from one another The Mac OS X Seatbeltsandbox system can constrain processes according touser-defined policies which is used by Chromium [8]

User-level sandboxes are often specific to an applica-tion and are hard to get right because applications reg-ularly change the files and directories they access As aresult they suffer problems with usability and securityvulnerabilities [2 3]

DCAC provides a single mechanism for all applica-tions usable by ordinary (non-administrator) users thatcan meet the varying data access requirements of appli-cations DCAC also meets access control requirementsthat go beyond sandboxing like user-controlled fine-grained sharing A key contribution of DCAC is that itcombines the models used by users (file access controland sharing) and administrators (creating sandboxes)

Capsicum has a daemon Casper which provides ser-vices to sandboxed processes in DarpaBrowser [25]confined code can access resources in the system viaPowerboxes which is controlled by user interface inter-actions These techniques are also applicable to DCACproviding confined processes an alternative path to reachprivileged resources without escalation

Flexible policy specification SELinux [16] and App-Armor [7] aim to provide comprehensive policies for theresources that applications can access This comprehen-siveness can lead to usability problems SELinux is noto-riously difficult to use [22] Both of them are only man-ageable by administrators and have difficulty accommo-dating situations where policies for one application varyper user DCAC is configurable on a per-user basis

eXtensible Access Control Markup Language (XA-CML) [5] is an XML-based format for defining accesscontrol While flexible it relies on XML manipulations(eg XPath queries) that are unsuited for use in frequentlatency-sensitive operations within an OS

POSIX ACLs [4] allow for users to define expressiveaccess control lists for permissions However these haveimportant limitations like the inability to support user-defined groups without explicitly putting all group mem-bers in the ACL of every file that has group permission(which in turn makes group membership updates diffi-cult) DCAC can accommodate user-defined groups

The Andrew File System [12] (AFS) supports flexibleper-directory ACLs and allows users to create groupsunder their own administration In comparison DCAC isnot restricted to a specific file system or IPC mechanismand supports more general usage due to its attribute-based model

Application- and user-defined access control Sev-eral prior systems allow program-controlled subdivi-sion of users into further users for finer-grained protec-tion [10 14 23] These systems still label processes byone user and as a result are less flexible than DCAC Ad-

ditionally these systems do not store information aboutthe user hierarchy in a way that easily allows shared usein a network filesystem UserFS [14] requires synchro-nization of unrelated applications on a global databaseof all users By contrast DCAC attributes are strings thatself-describe where they belong in the attribute hierar-chy

DCAC is inspired by attribute-based access controlproposed as part of InkTag [11] DCAC generalizes theapproach to a trusted OS and makes it coexist with exist-ing access control

New security models Decentralized InformationFlow Control (DIFC) [9 15 17 21 29] systems mod-ify access privileges based on the information that ap-plications have accessed DIFC-enforcing systems mayprovide stronger security guarantees than DCAC

Systems that use radically different security modelsrequire that developers adapt the logic of their code towork in these models While DCAC may require codechanges to applications we expect they will be less sig-nificant because DCACrsquos core concept the attribute isimplemented as a file descriptor and is easily mappedonto users and groups concepts that are familiar to de-velopers and likely reflected in their code Enforcing newsecurity models can require extensive global OS modifi-cation whereas DCACrsquos changes fit mostly within theexisting LSM framework

9 ConclusionOS-level support for application-defined principals makesDCAC usable and flexible enough to solve modern ac-cess control problems DCAC decentralizes privilege andpolicy specification improves application security andsupports distributed operation

References[1] GNU Zlib List of security vulnerabilities http

wwwcvedetailscomvulnerability-listvendor_id-72product_id-1820GNU-Zlibhtml

[2] National Vulnerability Database CVE-2012-4681httpwebnvdnistgovviewvulndetailvulnId=CVE-2012-4681

[4] POSIX 10031e Draft (Security APIs) httpuserssusecom˜agruenaclposixPosix_10031e-990310pdf

[5] eXtensible Access Control Markup Language (XACML) Ver-sion 30 httpdocsoasis-openorgxacml30xacml-30-core-spec-cs02-enhtml August 2012OASIS Committee Specification 02

[6] BARTH A JACKSON C REIS C AND GOOGLE CHROMETEAM The security architecture of the chromium browser Techrep Google Inc 2008

[7] BAUER M Paranoid penguin an introduction to novell AppAr-mor Linux Journal (2006)

[8] The Chromium Project Design Documents OS X Sand-boxing Design httpdevchromiumorg

developersdesign-documentssandboxosx-sandboxing-design

[9] EFSTATHOPOULOS P KROHN M VANDEBOGART SFREY C ZIEGLER D KOHLER E MAZIERES DKAASHOEK F AND MORRIS R Labels and event processesin the Asbestos operating system In SOSP (2005)

[10] FRIBERG C AND HELD A Support for discretionary rolebased access control in ACL-oriented operating systems In Pro-ceedings of the second ACM workshop on Role-based access con-trol (1997)

[11] HOFMANN O S DUNN A M KIM S LEE M Z ANDWITCHEL E InkTag Secure applications on an untrusted oper-ating system In ASPLOS (2013)

[12] HOWARD J H ET AL An overview of the Andrew File Sys-tem Carnegie Mellon University Information Technology Center1988

[13] KERRISK M Namespaces in operation part 1 namespacesoverview httpslwnnetArticles531114 Jan2013

[14] KIM T AND ZELDOVICH N Making Linux protection mech-anisms egalitarian with UserFS In USENIX Security (2010)

[15] KROHN M YIP A BRODSKY M CLIFFER NKAASHOEK M F KOHLER E AND MORRIS R In-formation flow control for standard OS abstractions In SOSP(2007)

[16] LOSCOCCO P AND SMALLEY S D Meeting critical securityobjectives with security-enhanced linux In Proceedings of theOttawa Linux Symposium (2001) pp 115ndash134

[17] MYERS A C AND LISKOV B Protecting privacy using thedecentralized label model ACM Transactions on Software Engi-neering and Methodology (TOSEM) 9 4 (2000) 410ndash442

[18] XATTR protocol patch for NFSv3 httpnameiorgnfsv3xattr

[19] PORTER D E HOFMANN O S ROSSBACH C J BENNA AND WITCHEL E Operating system transactions In SOSP(2009)

[20] PROVOS N FRIEDL M AND HONEYMAN P Preventingprivilege escalation In USENIX Security (2003)

[21] ROY I PORTER D E BOND M D MCKINLEY K SAND WITCHEL E Laminar Practical fine-grained decentralizedinformation flow control In PLDI (2009)

[22] SCHREUDERS Z C MCGILL T AND PAYNE C Empow-ering End Users to Confine Their Own Applications The Resultsof a Usability Study Comparing SELinux AppArmor and FBAC-LSM TISSEC (September 2011)

[23] SNOWBERGER P AND THAIN D Sub-identities Towardsoperating system support for distributed system security Techrep University of Notre Dame 2005

[24] SUN MICROSYSTEMS INC RFC 1813 - NFS Network FileSystem Version 3 Protocol Specification IETF Network WorkingGroup 1995

[25] WAGNER D AND TRIBBLE D A Security Analysis ofthe Combex DarpaBrowser Architecture Online at httpwww combex compapersdarpa-review (2002)

[26] WATSON R N A decade of os access-control extensibilityCommunications of the ACM (2013)

[27] WATSON R N M ANDERSON J LAURIE B AND KENN-AWAY K Capsicum Practical Capabilities for UNIX In USENIXSecurity (2010)

[28] WRIGHT C COWAN C MORRIS J SMALLEY S ANDKROAH-HARTMAN G Linux security modules General secu-rity support for the Linux kernel In USENIX Security (2002)

[29] ZELDOVICH N BOYD-WICKIZER S KOHLER E ANDMAZIERES D Making information flow explicit in HiStar InOSDI (2006)

Introduction

Modern access control idioms

Design

Adding and dropping attributes

DCAC supports modern access control idioms

Harmonious coexistence of DCAC and DAC

Prototype implementation

Programming interface

Processes and Objects

Attribute management

DCAC application implementation

Application-defined permissions in DokuWiki

Sandboxing Evince

NFS

Managing sub-users in SSHD

Evaluation

Microbenchmarks

Macrobenchmarks

Related work

Conclusion