1 / 12

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

Setuid Demystified (and how it may relate to stored procedure authorizations) Mahesh. Access Control in Unix. Partly based on UIDs In old unix systems, process had two UIDs: ruid, euid. Why? Principle of least privilege Newer unix systems (solaris, bsd, linux), three uids: ruid, euid, suid

morgan
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. Access Control in Unix (contd.) • 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 • (Ordinary) access control: based on euid • (Meta) access control policy: on what basis can a process change r/e/suid? • setuid system calls

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

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

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

  7. DFA (contd.) • Ensure that set of transitions is complete – source code inspection • 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.

  8. Algorithm correctness • Equivalence classes of states • Equivalence classes of <state, transition> pairs for a particular OS

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

  10. Example use • Portability between OSes: • Construct “parallel composition” of two FAs • In new FA, state is pair (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

  11. Their proposed API • cf. figure 13

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

More Related