Outline Saltzer & Schroeders principles CSci 5271 - PDF document

Outline Saltzer & Schroeder’s principles CSci 5271 Announcements intermission Introduction to Computer Security Day 7: Defensive programming and design, More secure design principles part 1 Software engineering for security Stephen McCamant University of Minnesota, Computer Science & Engineering Secure use of the OS Economy of mechanism Fail-safe defaults When in doubt, don’t give permission Security mechanisms should be as Whitelist, don’t blacklist simple as possible Obvious reason: if you must fail, fail safe Good for all software, but security software needs special scrutiny More subtle reason: incentives Complete mediation Open design Every mode of access must be Security must not depend on the checked design being secret Not just regular accesses: startup, If anything is secret, a minimal key maintenance, etc. Design is hard to keep secret anyway Checks cannot be bypassed Key must be easily changeable if revealed E.g., web app must validate on server, not Design cannot be easily changed just client

Open design: strong version Separation of privilege Real world: two-person principle “The design should not be secret” Direct implementation: separation of If the design is fixed, keeping it secret duty can’t help attackers Multiple mechanisms can help if they But an unscrutinized design is less are both required likely to be secure Password and ✇❤❡❡❧ group in Unix Least privilege Least privilege: privilege separation Programs must also be divisible to Programs and users should have the avoid excess privilege most limited set of powers needed to Classic example: multi-process do their job Presupposes that privileges are suitably OpenSSH server divisible N.B.: Separation of privilege ✻ ❂ privilege Contrast: Unix r♦♦t separation Least common mechanism Psychological acceptability Minimize the code that all users must A system must be easy to use, if users depend on for security are to apply it correctly Related term: minimize the Trusted Make the system’s model similar to the Computing Base (TCB) user’s mental model to minimize E.g.: prefer library to system call; mistakes microkernel OS

Sometimes: work factor Sometimes: compromise recording Cost of circumvention should match Recording a security failure can be attacker and resource protected almost as good as preventing it E.g., length of password But, few things in software can’t be But, many attacks are easy when you erased by r♦♦t know the bug Outline Readings reminder Saltzer & Schroeder’s principles It didn’t seem like many people read Announcements intermission the CFI paper. . . Link was broken until yesterday, my More secure design principles fault Software engineering for security Reminder about library proxy bookmarklet Secure use of the OS Alternative Saltzer & Schroeder Deadlines reminder Not a replacement for reading the real Exercise set 1: Thursday night thing, but: HW1 early submission: Friday night ❤tt♣✿✴✴❡♠❡r❣❡♥t❝❤❛♦s✳❝♦♠✴ Project progress reports: week from t❤❡✲s❡❝✉r✐t②✲♣r✐♥❝✐♣❧❡s✲♦❢✲s❛❧t③❡r✲❛♥❞✲s❝❤r♦❡❞❡r today Security Principles of Saltzer and HW1 final submission: week from Friday Schroeder, illustrated with scenes from Star Wars (Adam Shostack)

Outline Pop quiz Saltzer & Schroeder’s principles Announcements intermission What’s the type of the return value of ❣❡t❝❤❛r ? More secure design principles Why? Software engineering for security Secure use of the OS Separate the control plane Defense in depth Multiple levels of protection can be Keep metadata and code separate better than one from untrusted data Especially if none is perfect Bad: format string vulnerability But, many weak security mechanisms Bad: old telephone systems don’t add up Canonicalize names Fail-safe / fail-stop If something goes wrong, behave in a Use unique representations of objects way that’s safe E.g. in paths, remove ✳ , ✳✳ , extra Often better to stop execution that slashes, symlinks continue in corrupted state E.g., use IP address instead of DNS name E.g., better segfault that code injection

Outline Modularity Saltzer & Schroeder’s principles Divide software into pieces with Announcements intermission well-defined functionality Isolate security-critical code More secure design principles Minimize TCB, facilitate privilege Software engineering for security separation Improve auditability Secure use of the OS Minimize interfaces Appropriate paranoia Hallmark of good modularity: clean Many security problems come down to interface missing checks Particularly difficult: But, it isn’t possible to check everything Safely implementing an interface for continuously malicious users Safely using an interface with a malicious How do you know when to check what? implementation Invariant Pre- and postconditions A fact about the state of a program Invariants before and after execution of that should always be maintained a function Assumed in one place to guarantee in Precondition: should be true before call another Postcondition: should be true after Compare: proof by induction return

Dividing responsibility When to check At least once before any unsafe operation Program must ensure nothing unsafe If the check is fast happens If you know what to do when the check Pre- and postconditions help divide that fails responsibility without gaps If you don’t trust your caller to obey a precondition your callee to satisfy a postcondition yourself to maintain an invariant Sometimes you can’t check Error handling Every error must be handled Check that ♣ points to a null-terminated I.e, program must take an appropriate string response action Check that ❢♣ is a valid function pointer Errors can indicate bugs, precondition Check that ① was not chosen by an violations, or situations in the attacker environment Error codes Exceptions Separate from data, triggers jump to handler Commonly, return value indicates error Good: avoid need for manual copying, if any not dropped Bad: may overlap with regular result May support: automatic cleanup Bad: goes away if ignored ( ❢✐♥❛❧❧② ) Bad: non-local control flow can be surprising

Testing and security Fuzz testing “Testing shows the presence, not the Random testing can also sometimes absence of bugs” – Dijkstra reveal bugs Easy versions of some bugs can be Original ‘fuzz’ (Miller): ♣r♦❣r❛♠ found by targeted tests: ❁✴❞❡✈✴✉r❛♥❞♦♠ Buffer overflows: long strings Modern: small random changes to a Integer overflows: large numbers benign input Format string vulnerabilities: ✪① Outline Avoid special privileges Saltzer & Schroeder’s principles Require users to have appropriate permissions Announcements intermission Rather than putting trust in programs More secure design principles Anti-pattern 1: setuid/setgid program Anti-pattern 2: privileged daemon Software engineering for security But, sometimes unavoidable (e.g., email) Secure use of the OS One slide on setuid/setgid Don’t use shells or Tcl Unix users and process have a user id . . . in security-sensitive applications number (UID) as well as one or more String interpretation and re-parsing are group IDs very hard to do safely Normally, process has the IDs of the Eternal Unix code bug: path names with use who starts it spaces A setuid program instead takes the UID of the program binary

Prefer file descriptors Prefer absolute paths Maintain references to files by keeping Use full paths (starting with ✴ ) for them open and using file descriptors, programs and files rather than by name ✩P❆❚❍ under local user control References same contents despite file Initial working directory under local user system changes control Use ♦♣❡♥❛t , etc., variants to use FD But FD-like, so can be used in place of ♦♣❡♥❛t if missing instead of directory paths Prefer fully trusted paths Don’t separate check from use Avoid pattern of e.g., ❛❝❝❡ss then ♦♣❡♥ Each directory component in a path must be write protected Instead, just handle failure of open Read-only file in read-only directory You have to do this anyway Multiple references allow races can be changed if a parent directory is modified And ❛❝❝❡ss also has a history of bugs Be careful with temporary files Give up privileges Using appropriate combinations of Create files exclusively with tight s❡t✯✐❞ functions permissions and never reopen them Alas, details differ between Unix variants See detailed recommendations in Wheeler Best: give up permanently Not quite good enough: reopen and Second best: give up temporarily check matching device and inode Detailed recommendations: Setuid Fails with sufficiently patient attack Demystified (USENIX’02)

Whitelist environment variables Next time Can change the behavior of called Recommendations from the author of program in unexpected ways q♠❛✐❧ Decide which ones are necessary A variety of isolation mechanisms As few as possible Save these, remove any others