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 authentication 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 Another example Suppose that we deploy a firewall at the network perimeter to enforce the security goal that only authorized connections should be permitted into our internal network Then in this case the firewall is the TCB for this security goal A third example When we build access control into a system there is always some mechanism that is re CS 161 Spring 2010 Notes 1 29 1 sponsible for enforcing the access control policy As you may remember from the lecture notes on firewalls this mechanism is known as a reference monitor The reference monitor is the TCB for security goal of ensuring that the access control policy is followed Basically the notion of a reference monitor is just the idea of a TCB specialized to the case of access control In fact the three guiding principles for a reference monitor also apply to TCB We repeat them here A TCB should be Unbypassable There must be no way to breach system security by bypassing the TCB Tamper resistant The TCB should be protected from tampering by anyone else For instance other parts of the system outside the TCB should not be able to modify the TCB s code or state The integrity of the TCB must be maintained Verifiable It should be possible to verify the correctness of the TCB This usually means that the TCB should be as simple as possible as generally it is beyond the state of the art to verify the correctness of subsystems with any appreciable degree of complexity Keeping the TCB simple and small is good practice The less code you have to write the less chances you have to make a mistake or introduce some kind of implementation flaw Industry standard error rates are 1 5 defects per thousand lines of code Thus a TCB containing 1000 lines of code might have 1 5 defects while a TCB containing 100 000 lines of code might have 100 500 defects I know which I d pick Windows XP consists of about 40 million lines of code all of which is in the TCB Yikes The lesson is to shed code design your system so that as much of the code can be moved outside the TCB 2 TCBs What are they good for Who cares about all this esoteric stuff about TCBs Actually the notion of a TCB is a very powerful and pragmatic one The concept of a TCB allows a primitive yet effective form of modularity It lets us separate the system into two parts the part that is security critical the TCB and everything else This separation is a big win for security Security is hard It is really hard to build systems that are secure and correct The more pieces the system contains the harder it is to assure its security If we are able to identify a clear TCB then we will know that only the parts in the TCB must be correct for the system to be security Thus when thinking about security we can focus our effort where it really matters And if the TCB is only a small fraction of the system we have much better odds at ending up with a secure system the less of the system we have to rely upon the less likely that it will disappoint Let s do a concrete example You ve been hired by the National Archives to help with their email retention system They re chartered with saving a copy of every email ever sent by government officials They want to ensure that once a record is saved it cannot be subsequently deleted or destroyed For instance if someone is investigated they are worried about the threat that someone might try to destroy embarassing or incriminating documents previously stored in the archives The security goal is to prevent this kind of afterthe fact document destruction 1 So you need to build a document storage system which is append only once a document is added to the collection it cannot be removed How are you going to do it One possible approach You could augment the email program sitting on every
View Full Document
Unlocking...