Setuid Demystified (and how it may relate to stored procedure authorizations) Mahesh.

Slides:



Advertisements
Similar presentations
Protection Goals of Protection Domain of Protection Access Matrix
Advertisements

Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 14: Protection.
Chapter 3 Process Description and Control
Computer Science CSC 405 LabBy Yuzheng Zhou1 CSC 405 Introduction to Computer Security Lab session.
CMSC 414 Computer (and Network) Security Lecture 13 Jonathan Katz.
Computer Science 1 CSC 405 Introduction to Computer Security Topic 4. Security in Conventional Operating Systems -- Part II.
Protection. Goals of Protection Operating system consists of a collection of objects, hardware or software Each object has a unique name and can be accessed.
CS5261 Information Security CS 526 Topic 8: Operating Systems Security Basics & Unix Access Control Topic 8: Operating System Security Basics.
CS252: Systems Programming Ninghui Li Based on Slides by Prof. Gustavo Rodriguez-Rivera Topic 17: Signals, Process Credentials.
CSE 451: Operating Systems Winter 2009 Module 4 Processes Mark Zbikowski Gary Kimura.
Early OS security Overview by: Greg Morrisett Cornell University, Edited (by permission) for CSUS CSc250 by Bill Mitchell.
CSE451 Processes Spring 2001 Gary Kimura Lecture #4 April 2, 2001.
Processes April 5, 2000 Instructor: Gary Kimura Slides courtesy of Hank Levy.
1 setuid Demystified -- Examining the API of Security Operation in OS using Formal Models Hao Chen, David Wagner UC Berkeley Drew Dean SRI International.
C. Edward Chow Presented by Mousa Alhazzazi C. Edward Chow Presented by Mousa Alhazzazi Design Principles for Secure.
Lecture 7 Access Control
Lecture slides prepared for “Computer Security: Principles and Practice”, 2/e, by William Stallings and Lawrie Brown, Chapter 4 “Overview”.
Lecture Topics: 11/3 Address spaces Memory protection Creating a process –NT style –Unix style.
CSE 451: Operating Systems Autumn 2013 Module 6 Review of Processes, Kernel Threads, User-Level Threads Ed Lazowska 570 Allen.
The Impact of Programming Language Theory on Computer Security Drew Dean Computer Science Laboratory SRI International.
1 Setuid Demystified Hao Chen David Wagner UC Berkeley Drew Dean SRI International.
Implementing Processes and Process Management Brian Bershad.
Let’s look at an example I want to write an application that reports the course scores to you. Requirements: –Every student can only get his/her score.
Announcements Assignment 3 due. Invite friends, co-workers to your presentations. Course evaluations on Friday.
Lecture 3 Process Concepts. What is a Process? A process is the dynamic execution context of an executing program. Several processes may run concurrently,
CS426Fall 2010/Lecture 91 Computer Security CS 426 Lecture 9 Unix Access Control.
14.1 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts with Java – 8 th Edition Chapter 14: Protection.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Protection (Chapter 14)
CE Operating Systems Lecture 21 Operating Systems Protection with examples from Linux & Windows.
Threads G.Anuradha (Reference : William Stallings)
Silberschatz, Galvin and Gagne  Operating System Concepts Process Concept An operating system executes a variety of programs:  Batch system.
Lecture 18 Page 1 CS 111 Online OS Use of Access Control Operating systems often use both ACLs and capabilities – Sometimes for the same resource E.g.,
Access Control  privilege How does your code manage who has access to what?  authorization  permission Two OS models: Unix Windows.
1 Setuid Demystified Hao Chen David Wagner UC Berkeley Drew Dean SRI International Proceedings of the 11th USENIX Security Symposium San Francisco, California,
Access Control Lesson Introduction ●Understand the importance of access control ●Explore ways in which access control can be implemented ●Understand how.
Information Security CS 526
Chapter 14: Protection Silberschatz, Galvin and Gagne ©2005 Operating System Concepts – 7 th Edition, Apr 11, 2005 Goals of Protection Operating.
Race conditions and synchronization issues Exploiting UNIX.
MOPS: an Infrastructure for Examining Security Properties of Software Authors Hao Chen and David Wagner Appears in ACM Conference on Computer and Communications.
Lecture 5 Page 1 CS 111 Online Process Creation Processes get created (and destroyed) all the time in a typical computer Some by explicit user command.
Company LOGO Security in Linux PhiHDN - VuongNQ. Contents Introduction 1 Fundamental Concepts 2 Security System Calls in Linux 3 Implementation of Security.
Let’s look at an example
CS703 - Advanced Operating Systems
Chapter 14: System Protection
Chapter 6 Integrity Policies
Chapter 14: Protection.
Chapter 14: Protection.
Chapter 14: Protection.
CE Operating Systems Lecture 21
Chapter 14: Protection.
More examples How many processes does this piece of code create?
Chapter 14: Protection.
CSE 451: Operating Systems Winter 2011 Processes
CSE 451: Operating Systems Winter 2010 Module 4 Processes
Chapter 14: Protection.
Processes Hank Levy 1.
Chapter 14: Protection.
Processes and Process Management
Chapter 14: Protection.
Chapter 14: Protection.
CSE 451: Operating Systems Winter 2003 Lecture 4 Processes
CSE 451: Operating Systems Autumn 2004 Module 4 Processes
Chapter 14: Protection.
Chapter 14: Protection.
Chapter 14: Protection.
Chapter 14: Protection.
Processes Hank Levy 1.
Chapter 14: Protection.
Set-UID Privileged Programs
Race Condition Vulnerability
Presentation transcript:

Setuid Demystified (and how it may relate to stored procedure authorizations) Mahesh

Access Control in Unix Partly based on UIDs Partly based on UIDs In old unix systems, process had two UIDs: ruid, euid. In old unix systems, process had two UIDs: ruid, euid. Why? Principle of least privilege Why? Principle of least privilege Newer unix systems (solaris, bsd, linux), three uids: ruid, euid, suid Newer unix systems (solaris, bsd, linux), three uids: ruid, euid, suid Why? To be able to restore to higher privilege Why? To be able to restore to higher privilege

Access Control in Unix (contd.) fork() – inherit parent’s uids fork() – inherit parent’s uids exec() – keep uids, unless setuid bit is set, in which case e & suid are set to file owner’s id exec() – keep uids, unless setuid bit is set, in which case e & suid are set to file owner’s id (Ordinary) access control: based on euid (Ordinary) access control: based on euid (Meta) access control policy: on what basis can a process change r/e/suid? (Meta) access control policy: on what basis can a process change r/e/suid? setuid system calls setuid system calls

Setuid calls setresuid(r,e,s) setresuid(r,e,s) seteuid(e) seteuid(e) setreuid(r,e) setreuid(r,e) setuid(u) setuid(u) Linux specific: setfsuid() setfsuid() set/unset setuid “capability” set/unset setuid “capability”

Issue What exactly is the effect of each call? When does each succeed? What exactly is the effect of each call? When does each succeed? Source code inspection Source code inspection Build some “formal” model – DFA (still need some source code inspection) Build some “formal” model – DFA (still need some source code inspection) Source code observations – cf. 5.2 Source code observations – cf. 5.2

DFA construction Identify set of all possible states Identify set of all possible states identifies a state (except in linux) identifies a state (except in linux) Maybe return code (error/success) is part of state Maybe return code (error/success) is part of state Equivalence classes of states Equivalence classes of states Identify all possible transitions Identify all possible transitions E.g., given universe of ids, {0,1}, all possible calls are: setuid(0), setuid(1), seteuid(0,1), etc. E.g., given universe of ids, {0,1}, all possible calls are: setuid(0), setuid(1), seteuid(0,1), etc. cf. figure 3 cf. figure 3

DFA (contd.) Ensure that set of transitions is complete – source code inspection Ensure that set of transitions is complete – source code inspection Examples (U = {0,1} versus U = {1,2} etc.) Examples (U = {0,1} versus U = {1,2} etc.) (1) cf. figs 4 (a), (b), (c) (2) cf. fig (5, a) versus fig (6) Several bugs identified; setuid() call is ambiguous. Several bugs identified; setuid() call is ambiguous.

Algorithm correctness Equivalence classes of states Equivalence classes of states Equivalence classes of pairs for a particular OS Equivalence classes of pairs for a particular OS

Correctness (contd.) If If getstate() – returns rep. from equiv. class getstate() – returns rep. from equiv. class setstate(s) – OS enters some s’ equiv to s setstate(s) – OS enters some s’ equiv to s getallstates() – returns pair of sets (S,C) s.t.: getallstates() – returns pair of sets (S,C) s.t.: Every state equiv. class is repr. in S Every state equiv. class is repr. in S Every pair-equiv-class contains an s.t. c  C Every pair-equiv-class contains an s.t. c  C Then Then buildmodel() corrects models OS behaviour buildmodel() corrects models OS behaviour Assertion: |U| = 6 is sufficient. Assertion: |U| = 6 is sufficient.

Example use Portability between OSes: Portability between OSes: Construct “parallel composition” of two FAs Construct “parallel composition” of two FAs In new FA, state is pair (s,s’) In new FA, state is pair (s,s’) A state is accepting iff s  s’ A state is accepting iff s  s’ If there is an execution trace from a non- accepting state to an accepting state, then potential portability issue If there is an execution trace from a non- accepting state to an accepting state, then potential portability issue

Their proposed API cf. figure 13 cf. figure 13

(Dis)similarity to stored procedure stuff We are not dealing with procedures explicitly changing privilege level We are not dealing with procedures explicitly changing privilege level Ambiguity in how it works “statically” Ambiguity in how it works “statically” Errors in Oracle docs Errors in Oracle docs Even if we clearly understand how it works, it doesn’t make sense from some intuitive security standpoint Even if we clearly understand how it works, it doesn’t make sense from some intuitive security standpoint