General PrinciplesPatterns for Building Secure SoftwareThe Trusted Computing Base (TCB)TCBs: What are they good for?TOCTTOU VulnerabilitiesModularityOptional: Defensive ConsistencyPaxsonSpring 2011CS 161Computer Security1/27Principles and Design Patterns for Secure SystemsIn this set of notes we look at ways of building secure systems. The same ideas also allowus to examine existing systems to understand their security properties.1 General PrinciplesWe’ll being with some general principles for secure system design.1• Security is economics. No system is completely, 100% secure against all attacks.Rather, systems may only need to resist a ce rtain level of attack. There is no pointbuying a $10,000 firewall to protect $1,000 worth of trade secrets.Also, it is often helpful to quantify the level of effort that an attacker would need toexpend to break the system. Adi Shamir once wrote, “There are no secure systems,only degrees of insecurity.” A lot of the science of computer security comes in measuringthe degree of insecurity.Analogy: Safes come with a rating of their level of security. For instance, a consumer-grade safe might indicate that it will resist attack for up to 5 minutes by anyonewithout tools. A high-end safe might be rated TL-30: it is secure against a burglarwith safecracking tools and limited to 30 minutes access to the safe. (With such a safe,we know that we need to hire security guards who are able to respond to any intrusionwithin 30 minutes.)A corollary of this principle is you should focus your energy on securing the weakestlinks. Security is like a chain: it is only as secure as the weakest link. Attackers followthe path of least resistance, and they will attack the system at its weakest point. Thereis no sense putting an exp ensive high-end deadbolt on a screen door; attackers aren’tgoing to bother trying to pick the lo ck when they can just rip out the screen and stepthrough.• Least privilege. Give a program the set of access privileges that it legitimately needsto do its job—but nothing more. Try to minimize how much privilege you give eachprogram and system component.Least privilege is an enormously powerful approach. It doesn’t reduce the probability offailure, but it can reduce the expected cost of failures. The less privilege that a programhas, the less harm it can do if it goes awry or becomes subverted. You can think of this1Many of these principles are due to Saltzer and Schroeder, who wrote a classic paper in the 1970s withadvice on this topic.1/27 CS 161, Spring 2011 — Material courtesy Prof. David Wagner 1 of 13as the computer-age version of the shipbuilder’s notion of “watertight compartments”:even if one compartment is breached, we want to minimize the damage to the integrityof the rest of the system.For instance, the principle of least privilege can help reduce the damage caused bybuffer overruns. If a program is compromised by a buffer overrun attack, then it willprobably be completely taken over by an intruder, and the intruder will gain all theprivileges the program had. Thus, the fewer privileges that a program has, the lessharm is done if it should someday be penetrated by a buffer overrun attack.Example: How does Unix do, in terms of least privilege? Answer: Pretty lousy. Everyprogram gets all the privileges of the user that invokes it. For instance, if I run a editorto edit a single file, the editor receives all the privileges of my user account, includingthe powers to read, modify, or delete all my files. That’s much more than is needed;strictly speaking, the editor probably only needs access to the file being edited to getthe job done.Example: How is Windows, in terms of least privilege? Answer: Just as lousy. Ar-guably worse, because many users run under an Administrator account, and manyWindows programs require that you be Administrator to run them. In this case, everyprogram receives total power over the whole computer. Folks on the Microsoft se curityteam have recognized the risks inherent in this, and are taking many steps to warnpeople away from running with Administrator privileges, so things are getting betterin this respect.• Use fail-safe defaults. Use default-deny polices. Start by denying all access, then allowonly that which has been explicitly permitted. Ensure that if the security mechanismsfail or crash, they will default to secure b ehavior, not to insecure behavior.Example: A packet filter is a router. If it fails, no packets will be routed. Thus, apacket filter fails safe. This is good for security. It would be much more dangerous ifit had fail-open behavior, since then all an attacker would ne ed to do is wait for thepacket filter to crash (or induce a crash) and then the fort is wide open.Example: Long ago, SunOS machines used to ship with + in their /etc/hosts.equiv,which allowed anyone with root access on any machine on the Internet to log into yourmachine as root. Irix machines used to ship with xhost + in their X Windows con-figuration files by default. These instances violate of the principle of fail-safe defaults,since the machines came with an out-of-the-box configuration that was insecure bydefault.• Separation of responsibility. Split up privilege, so no one person or program has com-plete power. Require more than one party to approve before access is granted.Examples: In a nuclear missile silo, two launch officers must agree before the missile1/27 CS 161, Spring 2011 — Material courtesy Prof. David Wagner 2 of 13can be launched.Example: In a movie theater, you pay the teller and get a ticket stub; then when youenter the movie theater, a separate employee tears your ticket in half and collects onehalf of it, putting it into a lockbox. Why bother giving you a ticket that 10 feet lateris going to be collected from you? One answer is that this helps prevent insider fraud.Tellers are low-paid employees, and they might be tempted to under-charge a friend,or to over-charge a stranger and pocket the difference. The presence of two employeeshelps keep them both honest, since at the end of the day, the manager can reconcilethe number of ticket stubs collected against the amount of cash collected and detectsome common shenanigans.Example: In many companies, purchases over a certain amount must be approvedboth by the requesting employee and by a separate purchasing office. This controlhelps prevent fraud, since it is less likely that both will collude and since it is unlikelythat the
View Full Document
Unlocking...