{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}

Software security: principles

Security in Computing (3rd Edition)

Info iconThis preview shows pages 1–2. Sign up to view the full content.

View Full Document Right Arrow Icon
CS 161 Computer Security Fall 2005 Joseph/Tygar/Vazirani/Wagner Notes 14 Principles of Secure Software This lecture will show you a number of principles for building secure systems. First, we will show one powerful concept, the notion of a trusted computing base (TCB); then, we will describe thirteen useful principles. The principles are neither necessary nor sufficient to ensure the design of a secure system, but they are often very helpful nonetheless. This lecture focuses primarily on 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? That’s the focus of this lecture. We reserve the question of what to do at implementation time until next lecture. 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. 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.
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Image of page 2
This is the end of the preview. Sign up to access the rest of the document.

{[ snackBarMessage ]}