Berkeley COMPSCI 261N - Design Principles for Security-conscious Systems

Unformatted text preview:

Design Principles for Security-conscious Systems1Overview• Design principles from Saltzer & Schroeder’s 1975 paper• A few case studies• What did Saltzer-Schroeder overlook? (Personal opinions)2Saltzer and Schroeder’s PrinciplesEconomy of mechanism: Keep the design as simple and small as possible.Fail-safe defaults: Base access decisions on permission rather than exclusion.Complete mediation: Every access to every object must be checked for authority.Open design: The design should not be secret.Separation of privilege: It’s safer if it takes two parties to agree to launch a missilethan if one can do it alone.Least privilege: Operate with the minimal set of powers needed to get the jobdone.Least common mechanism: Minimize subsystems shared between or relied uponby mutually distrusting users.Psychological acceptability: Design security systems for ease of use.3Economy of Mechanism• Keep your implementation as simple as possible– Note that simple is different from small: just because you can write a CGIprogram in 300 bytes of line-noise Perl, doesn’t mean you should– All the usual structured-programming tips help here: clean interfacesbetween modules, avoid global state, etc.• Interactions are a nightmare– You often need to check how each pair of subsystems interacts, andpossibly even each subset of subsystems– For example, interactions between the password checker and thepage-fault mechanism– Complexity grows as Ω(n2), possibly even Ω(2n)4Bellovin’s Fundamental Theorem of FirewallsAxiom 1 (Murphy) All programs are buggy.Theorem 1 (Law of Large Programs) Large programs are even buggier thantheir size would indicate.Corollary 1.1 A security-relevant program has security bugs.Theorem 2 If you do not run a program, it does not matter whether or not it isbuggy.Corollary 2.1 If you do not run a program, it does not matter if it has securityholes.Theorem 3 Exposed machines should run as few programs as possible; the onesthat are run should be as small as possible.5The sendmail wizard hole• Memory segments: text (code), data (initialized variables), bss (variablesnot explicitly initialized), heap (malloced)• Config file parsed, then a “frozen” version written out by dumping the bss andheap segments to a file• Wizard mode implementation:int wizflag; // password enabled?char*wizpw = NULL; // ptr to passwdWhen wizflag set, enables extra access for remote debugging; wizpwholds the password (NULL = no password needed). Code that sets wizflagto true also sets wizpw to some appropriate password.• Results:– In production mode, wizard mode enabled, no password needed.– But in development, password protection was tested, and worked fine...Credits: Bellovin.6The ftpd/tar hole• To save network bandwidth, ftpd allows client to run tar on the ftp server.• This was fine, until people started using GNU tar.• Security hole:quote site exec tar -c -v--rsh-command=commandtorunasftp -f somebox:foo foo• Beware the wrath of feeping creaturism...7Fail-safe Defaults• Start by denying all access, then allow only that which has been explicitlypermitted– By doing this, oversights will usually show up as “false negatives” (i.e.someone who should have access is denied it); these will be reportedquickly– The opposite policy leads to “false positives” (bad guys gain access whenthey shouldn’t); the bad guys don’t tend to report these types of problems• Black-listing vs white-listing8Complete Mediation• Check every access to every object• In rare cases, you can get away with less (caching)– but only if you’re sure that nothing relevant in the environment haschanged– and there’s a lot that’s relevant...– Example: open("/dev/console",O_RDWR), revoke()9Separation of Privilege• Require more than one check before granting access to an object– A single check may fail, or be subverted. The more checks, the harder thisshould be– Something you know, something you have, something you are– e.g. Web site checks both your password and a cookie– e.g. Airport security checks both the shape of your hand and a PIN• Require that more than one principal “sign off” on an attempted access beforegranting it– This is easy to do with cryptography: secret sharing can mathematicallyprovide that a capability is released only when k out of n, for example,agree.10Least Privilege• Figure out exactly what capabilities a program requires in order to run, andgrant exactly those• This is not easy. One approach is to start with granting none, and see whereerrors occur– But achieving 100% coverage of application features can be hard.• This is the principle used to design policy for sandboxes (e.g. Janus)• The Unix concept of root only gets you partway to this goal– Some programs need to run as root just to get one small privilege, suchas binding to a low-numbered port– This leaves them susceptible to buffer-overflow exploits that havecomplete run of the machine11Sandboxes and code confinement• Least privilege is the motivation behind the use of sandboxes to confinepartially-untrusted code.• Example: sendmail– Once sendmail is broken into, intruder gains root access, and the game isover.– Better would be for sendmail to run in a limited execution domain withaccess only to the mail subsystem.12Sandboxes and code confinement, cont.• Example: Web browser plugins– Browser plugins run in the browser’s address space, with no protection.– At one point, a bug in the popular Shockwave plugin could be used bymalicious webmasters to read your email, by abusing mailbox:-styleURLs.13Least Common Mechanism• Be careful with shared code– The assumptions originally made may no longer be valid• Example: Some C library routines (and the C runtime) have excess featuresthat lead to security holes• Be careful with shared data– They create the opportunity for one user/process to influence another– Be especially cautious with globally accessible mutable state14Saltzer and Schroeder’s PrinciplesEconomy of mechanism: Keep the design as simple and small as possible.Fail-safe defaults: Base access decisions on permission rather than exclusion.Complete mediation: Every access to every object must be checked for authority.Open design: The design should not be secret.Separation of privilege: It’s safer if it takes two parties to agree to launch a missilethan if one can do it alone.Least privilege: Operate with the minimal set of


View Full Document

Berkeley COMPSCI 261N - Design Principles for Security-conscious Systems

Download Design Principles for Security-conscious Systems
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Design Principles for Security-conscious Systems and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Design Principles for Security-conscious Systems 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?