Security in Computing (3rd Edition)

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.