Application-Defined Decentralized Access Control Yuanzhong Xu, Alan Dunn, Owen Hofmann*, Michael Lee, Syed Akbar Mehdi, Emmett Witchel ! UT-Austin, Google* Access control mechanism
• Simplicity • Flexibility
• Easy to understand • Expressive
• Less prone to bugs • Support many use cases
2 UNIX/Linux - simplicity
• Linux/UNIX
• User: UID
• Group: GID
• Admin: root user
• Simplicity
• Easy to understand
• Less prone to bugs
3 UNIX/Linux - more flexibility
• Linux/UNIX
• User: UID • Need more flexibility
• • Group: GID setuid binary • effective UID • Admin: root user • FS UID • Simplicity • sticky bit • Easy to understand • … • Less prone to bugs
4 setuid binaries make things tricky
suEXEC of Apache server: using setuid binaries to run • Need more flexibility CGI/SSI with different UIDs • setuid binary
“If you aren't familiar with • effective UID managing setuid root programs and the security • FS UID issues they present, we highly recommend that you • sticky bit not consider using • … suEXEC.”
— http://httpd.apache.org/docs/2.2/suexec.html 5 Access control in server applications
• A server application typically uses its own, hand- crafted program logic to enforce access control Access control is hard to get right… ! !Source of bugs: among OWASP top 10 application security risks https://www.owasp.org/index.php/Top_10_2010-Main
Server application Access control
Why OS access control OS CANNOT help? Inflexible OS-level access control
• Numerical identifiers for Consequences principals in a flat namespace • different servers/apps CANNOT • 32-bit integer UID, GID manage principals separately (Linux) • requires mapping between server users and OS UIDs
• centralized management of principals • regular user CANNOT define an ad hoc group (like a circle in • root/administrator privilege Google+) required to manage users/ • creating a server user requires groups modifying system-wide sensitive files • /etc/passwd, /etc/group
7 OS mechanism: inflexible, but robust
Used beyond basic access control of OS users
• Privilege separation in SSHD - different components have different UIDs
• Android - each application has a unique UID
• Mac OS X Seatbelt application sandbox
8 User/Application-defined access control
• Privilege separation
• Application sandbox
• Access control in server applications
• Flexible group sharing
A unified OS-level mechanism to support all those scenarios?
- a balance between Simplicity and Flexibility
9 DCAC
• DeCentralized Access Control
• Conceptually similar to traditional UNIX discretionary access control (DAC)
• But generalized, more flexible
• A unified model: familiar, intuitive - can naturally represent users/groups
• Coexists with DAC
10 DCAC mechanisms summary
Augment! Restrict! privilege/access privilege/access
Add child attribute DCAC basic attribute-based Drop attribute model Attribute gateway
Grant access when Mechanisms for EITHER DCAC OR pmask, UID-bit coexisting with DAC DAC passes
11 DCAC Attributes - principal identifiers
• Attributes — hierarchically named strings - components separated by “.”
.u .g .u.alice .u.bob .g.student
.u.alice.photo
• .u.alice is the parent attribute of .u.alice.photo A parent attribute represents a superset of privileges of its child attributes
12 DCAC Attributes - principal identifiers
• Attribute is a generic abstraction — can represent different types of principals • OS users/groups • Server users/groups • Applications • Application components • Naming conventions for OS users and groups: • user .u.
13 DCAC processes vs Linux processes
DCAC Process Linux Process
UID: 1000 Attribute set Inherite .u.alice Inheritedd acrossacross fork() GIDs: 4, .u.alice.photos andfork() exec() and .g.students 20, …
14 DCAC objects vs Linux objects
DCAC File/IPC object Linux File/IPC object
ACL: 4 access modes permission bits -rwxr-xr-x read = .g.students V .u.alice.photos Each access mode is a formula of attributes in UID: 1000 write = .u.alice.photos disjunctive normal (owner: alice) form (DNF), w/o execute = Ø negations GID: 100 (group: student) modify = .u.alice
15 DCAC ACL access modes
traditional DAC DCAC (discretionary access control) permission to read/ read, write, execute rwx permission bits write/execute access modes -rwxr-xr-x
Admin privilege — modify access mode UID (owner) change access
A matching process can A process with the same change ACL of the file UID can chmod
16 Any process can change its attribute set
• Deprivilege a process without root: .u.alice
• A process can add a child attribute add child of any existing attribute in its attribute set .u.alice .u.alice.photo • A process can always drop any drop parent attribute .u.alice.photo • Decentralized in privilege,compared to Linux: setuid() syscall restricted to root
17 Example: sandbox a PDF viewer
read = .u.alice.pdf Alice’s shell process
.u.alice pdf viewer .u.alice fork .u.alice.pdf
fork add drop exec
18 Example: support server-defined users
Alice Bob
worker process for Bob 2 requests from process .apps.server request .apps.server.u.bob for Bob
dispatcher process fork .apps.server worker process for Alice .apps.server process .apps.server.u.alice request for Alice
19 Augmenting a process’ privilege
Linux: DCAC: setuid binaries: Attribute gateways: ! ! • e.g. sudo • e.g., represent an ad ! hoc group: sudo allows a ! user’s process to the gateway allows a become root, if the group member’s user is in group process to add the “admin” group attribute
20 Ad hoc group
Group: “reading-group” defined by Alice Ad hoc group: members • created/managed by regular users • Who are members of admins the group? • Who are admins of the group?
21 Ad hoc group as gateway
Gateway — ACL for Group: attribute “reading-group” defined by Alice .u.alice.reading-group members ACL read = .u.chris V .u.david
admins modify = .u.alice V .u.bob
gateway: a special file 22 Ad hoc group as gateway
child attribute Gateway — ACL for of .u.alice: Group: attribute under control “reading-group” defined by Alice .u.alice.reading-group of Alice members ACL read = .u.chris V .u.david
admins modify = .u.alice V .u.bob
gateway: a special file 23 Ad hoc group as gateway
Gateway — ACL for Group: attribute “reading-group” defined by Alice .u.alice.reading-group Regular members as the read members ACL access mode read = .u.chris V .u.david
admins modify = .u.alice V .u.bob
gateway: a special file 24 Ad hoc group as gateway
Gateway — ACL for Group: attribute “reading-group” defined by Alice .u.alice.reading-group members ACL read = .u.chris V .u.david
admins modify = .u.alice V .u.bob
Admins as the modify access mode: ! Admin Privilege gateway: a can modify this gateway, or special file create new gateways for .u.alice.reading-group25 Ad hoc groups in a server application
gateway worker process for Bob .apps.server.u .bob.friends
.apps.server.u.bob read= dispatcher process fork .apps.server
worker process for Alice
.apps.server.u.alice
.apps.server.u.bob. friends
26 Decentralized attribute gateways
• DCAC doesn’t enforce the location of gateways
• Specific OS distributions/applications should develop conventions
27 Decentralized attribute gateways
• Different applications manage their own gateways separately
Application 1 Application 2 Application 3
gateways gateways gateways
28 Coexisting with DAC in Linux DAC: traditional discretionary access control
DCAC Process Linux Process in DAC
Attribute set UID: 1000 (alice)
.u.alice GIDs: 4, 20, … .u.alice.photos .g.students
29 Coexisting with DAC in Linux DAC: traditional discretionary access control DCAC Process How to restrict Grant access when DAC? Attribute set either DCAC or DAC passes isolate processes with .u.alice ! the same UID — A valid Linux disk .u.alice.photos image is a valid .g.students DCAC disk image (enables incremental UID: 1000 (alice) deployment) GIDs: 4, 20, …
More permissive than DAC only
30 How to restrict DAC? DAC: traditional discretionary access control DCAC Process pmask Attribute set permission bits ANDed with pmask .u.alice e.g. pmask=0555: DAC can’t grant .u.alice.photos write permission .g.students
UID: 1000 (alice) UID-bit If UID-bit=0: GIDs: 4, 20, … - give up the UID-based ambient authority pmask = 0555 e.g. DAC can’t allow chmod UID-bit = 0 A process can ONLY clear bits in pmask and UID-bit — to deprivilege itself
31 Bootstrap DCAC
• Attributes can only be added based on the current attribute set
• Who sets up the initial attribute?
• Allow a root process to add any attribute
• Modify login/sshd/lightDM to set up attribute set of a user’s process with: - .u.
32 Represent ACLs on objects
• ACLs for persistent files are stored in extended attributes (xattr)
• ACLs are also cached in memory
• support in-memory files, IPC objects
• improve performance
• can be invalidated by NFS according to time stamps, or hashes
33 Applications
A single model that supports these scenarios: • A wrapper program that sets up a sandbox, for unmodified applications.
• DokuWiki [246 lines code change] - use DCAC to enforce access control - support ad hoc groups
• NFS [326 lines code change] - DCAC can operate on multiple machines - No centralized attribute server
• SSHD [81 lines code change] - Allow a regular OS user to define his/her sub-users, who can log in with a subset of the OS user’s privilege.
34 Performance
• File system micro-benchmarks (Reimplemented Andrew Benchmarks, small file): DCAC only adds overhead on open, create, delete, etc.
• ext4: 32B ACL: under4% slowdown - in-inode xattr 256B ACL: under 9% slowdown - extra disk block for xattr
• NFSv3: under 5% slowdown ACL size has small impact on performance Extra round-trips (for fetching ACLs) — but not often, cached for most of the time
35 Performance
• Macro-benchmarks
• Kernel compile: under 2% slowdown - both ext4 and NFSv3
• DokuWiki: 0% slowdown - playing back 6,430 revisions of 765 pages to the DokuWiki website
36 Conclusion
• DCAC generalizes OS access control to support user/ application-defined scenarios
• DCAC avoids the requirement of root privilege in many use cases
• DCAC does not require centralized attribute management
• DCAC coexists with DAC (discretionary access control)
Code available on GitHub: https://github.com/ut-osa/dcac
37