Outline OS trust and assurance CSci 5271 Introduction to Computer - PDF document

Outline OS trust and assurance CSci 5271 Introduction to Computer Security Announcements intermission Day 11: OS security: higher assurance Stephen McCamant Unix access control University of Minnesota, Computer Science & Engineering Trusted and trustworthy Trusted (I/O) path How do you know you’re talking to the Part of your system is trusted if its right software? failure can break your security And no one is sniffing the data? Thus, OS is almost always trusted Example: Trojan login screen Real question: is it trustworthy? Or worse: unlock screensaver with root Distinction not universally observed: password trusted boot, Trusted Solaris, etc. Origin of “Press Ctrl-Alt-Del to log in” Minimizing trust How to gain assurance Kernel ✦ microkernel ✦ nanokernel Use for a long time Reference monitor concept Testing TCB size: measured relative to a policy Code / design review goal Third-party certification Reference monitor ✒ TCB Formal methods / proof But hard to build monitor for all goals

Evaluation / certification Orange book OS evaluation Trusted Computer System Evaluation Testing and review performed by an Criteria independent party D. Minimal protection Goal: separate incentives, separate C. Discretionary protection accountability C2 adds, e.g., secure audit over C1 Compare with financial auditing B. Mandatory protection Watch out for: form over substance, B1 ❁ B2 ❁ B3: stricter classic MLS misplaced incentives A. Verified protection Common Criteria Common Criteria, Anderson’s view Many profiles don’t specify the right International standard and agreement things for IT security certification OSes evaluated only in unrealistic Certification against a protection profile , environments and evaluation assurance level EAL 1-7 E.g., unpatched Windows XP with no network attacks Evaluation performed by “Corruption, Manipulation, and Inertia” non-government labs Pernicious innovation: evaluation paid for Up to EAL 4 automatically by vendor Labs beholden to national security cross-recognized apparatus Formal methods and proof Proof and complexity Can math come to the rescue? Formal proof is only feasible for Checking design vs. implementation programs that are small and elegant Automation possible only with other If you honestly care about assurance, tradeoffs you want your TCB small and elegant E.g., bounded size model anyway Starting to become possible: Should provability further guide design? machine-checked proof

Some hopeful proof results Outline seL4 microkernel (SOSP’09 and OS trust and assurance ongoing) 7.5 kL C, 200 kL proof, 160 bugs fixed, 25 person years Announcements intermission CompCert C-subset compiler (PLDI’06 and ongoing) Unix access control RockSalt SFI verifier (PLDI’12) Note to early readers Outline OS trust and assurance This is the section of the slides most likely to change in the final version Announcements intermission If class has already happened, make sure you have the latest slides for Unix access control announcements UIDs and GIDs File mode bits To kernel, users and groups are just Core permissions are 9 bits, three numeric identifiers groups of three Names are a user-space nicety Read, write, execute for user, group, E.g., ✴❡t❝✴♣❛ss✇❞ mapping other Historically 16-bit, now 32 ❧s format: r✇① r✲① r✲✲ User 0 is the special superuser r♦♦t Octal format: 0754 Exempt from all access control checks

Interpretation of mode bits Directory mode bits File also has one user and group ID Same bits, slightly different interpretation Choose one set of bits Read: list contents (e.g., ❧s ) If users match, use user bits If subject is in the group, use group bits Write: add or delete files Otherwise, use other bits Execute: traverse Note no fallback, so can stop yourself X but not R means: have to know the or have negative groups But usually, ❖ ✒ ● ✒ ❯ names Process UIDs and s❡t✉✐❞✭✷✮ Setuid programs, different UIDs If 04000 “setuid” bit set, newly exec’d UID is inherited by child processes, and process will take UID of its file owner an unprivileged process can’t change it Other side conditions, like process not traced But there are syscalls root can use to Specifically the effective UID is changed, change the UID, starting with s❡t✉✐❞ while the real UID is unchanged E.g., login program, SSH server Shows who called you, allows switching back More different UIDs Setgid, games Two mechanisms for temporary switching: Setgid bit 02000 mostly analogous to Swap real UID and effective UID (BSD) setuid Remember saved UID , allow switching to it (System V) But note no supergroup, so UID 0 is still Modern systems support both special mechanisms at the same time Classic application: setgid ❣❛♠❡s for Linux only: file-system UID managing high-score files Once used for NFS servers, now mostly obsolete

Special case: ✴t♠♣ Special case: group inheritance When using group to manage We’d like to allow anyone to make files permissions, want a whole tree to have in ✴t♠♣ a single group So, everyone should have write When 02000 bit set, newly created permission entries with have the parent’s group But don’t want Alice deleting Bob’s files (Historic BSD behavior) Solution: “sticky bit” 01000 Also, directories will themselves inherit 02000 “POSIX” ACLs ACL legacy interactions Hard problem: don’t break security of Based on a withdrawn standardization legacy code More flexible permissions, still fairly Suggests: “fail closed” Unix-like Contrary pressure: don’t want to break Multiple user and group entries functionality Decision still based on one entry Suggests: “fail open” Default ACLs: generalize group POSIX ACL design: old group inheritance permission bits are a mask on all novel Command line: ❣❡t❢❛❝❧ , s❡t❢❛❝❧ permissions “POSIX” “capabilities” Privilege escalation dangers Many pieces of the root privilege are Divide root privilege into smaller ( ✘ 35) enough to regain the whole thing pieces Access to files as UID 0 Note: not real capabilities ❈❆P ❉❆❈ ❖❱❊❘❘■❉❊ First runtime only, then added to FS ❈❆P ❋❖❲◆❊❘ ❈❆P ❙❨❙ ▼❖❉❯▲❊ similar to setuid ❈❆P ▼❑◆❖❉ Motivating example: ♣✐♥❣ ❈❆P P❚❘❆❈❊ ❈❆P ❙❨❙ ❆❉▼■◆ ( ♠♦✉♥t ) Also allows permanent disabling

Legacy interaction dangers Former bug: take away capability to drop privileges Use of temporary files by no-longer setuid programs For more details: “Exploiting capabilities”, Emeric Nasi