This preview has intentionally blurred sections. Sign up to view the full version.View Full Document
Unformatted text preview: CS 161 Computer Security Spring 2010 Paxson/Wagner Notes 1/29 Patterns for Building Secure Software This lecture will show you a number of patterns for building secure systems, and in particular, what you can do at design time to improve security. How can you choose an architecture that will help reduce the likelihood of flaws in your system, or increase the likelihood that you will be able to survive such flaws? You will also see a powerful concept, the notion of a trusted computing base (TCB). 1 The Trusted Computing Base (TCB) Earlier in this class we introduced the notion of trusted and trustworthy components. A trusted component is a part of the system that we rely upon to operate correctly, if the whole system is to be secure; to turn it around, a trusted component is one that is able to violate our security goals if it misbehaves. A trustworthy component is a part of the system that we would be justified in trusting, i.e., where we’d be justified in expecting it to operate correctly. For instance, on Unix systems the super-user (root) is trusted; hopefully she is also trustworthy, or else we are in trouble. In any system, the trusted computing base (TCB) is that portion of the system that must operate correctly, for the security goals of the system to be assured. We have to rely on every component in the TCB to work correctly. However, anything that is outside the TCB isn’t relied upon in any way: even if it misbehaves or operates maliciously, it cannot defeat the system’s security goals. Indeed, we can take the latter statement as our definition of the TCB: the TCB must be large enough so that nothing outside the TCB can violate security. Example: Suppose the security goal is that only authorized users are allowed to log into my system using SSH. What is the TCB? Well, the TCB includes the SSH daemon, since it is the one that makes the au- thentication and authorization decisions—if it has a bug (say, a buffer overrun), or if it was programmed to behave maliciously (say, the SSH implementor has included a backdoor in it), then it will be able to violate my security goal (e.g., by allowing access to unauthorized users). That’s not all. The TCB also includes the operating system, since the operating system has the power to tamper with the operation of the SSH daemon (e.g., by modifying its address space). Likewise, the CPU is in the TCB, since we are relying upon the CPU to execute the SSH daemon’s machine instructions correctly. Suppose a web browser application is installed on the same machine; is the web browser in the TCB? Hopefully not! If we’ve built the system in a way that is at all reasonable, the SSH daemon is supposed to be protected (by the operating system’s memory protection) from interference by unprivileged applications, like a web browser....
View Full Document
This note was uploaded on 04/14/2010 for the course CS 161 taught by Professor Staff during the Spring '08 term at Berkeley.
- Spring '08
- Computer Security