How to Write Secure Programs
Well-known educator Matt Bishop discusses informal techniques for writing programs that enforce security policies.
Save 35% off the list price* of the related book or multi-format eBook (EPUB + MOBI + PDF) with discount code ARTICLE.
* See informit.com/terms
This chapter is from the book
This chapter is from the book
This chapter is from the book
CLOWN: What is he that builds stronger than either the mason, the shipwright, or the carpenter?
OTHER CLOWN: The gallows-maker; for that frame outlives a thousand tenants.— Hamlet, V, i, 42–45.
The software on systems implements many mechanisms that support security. Some of these mechanisms reside in the operating system, whereas others reside in application and system programs. This chapter discusses the design and implementation of a program to grant users increased privileges. It also presents common programming errors that create security problems, and offers suggestions for avoiding those problems. Finally, testing and distribution are discussed.
This chapter shows the development of the program from requirements to implementation, testing, and distribution.
31.1 Problem
The purpose of this chapter is to provide a glimpse of techniques that provide better than ordinary assurance that a program’s design and implementation satisfy its requirements. This chapter is not a manual on applying high-assurance techniques. In terms of the techniques discussed in Part VI, “Assurance,” this chapter describes low-assurance techniques.
However, given the current state of programming and software development, these low-assurance techniques enable programmers to produce significantly better, more robust, and more usable code than they could produce without these techniques. So, using a methodology similar to the one outlined in this chapter will reduce vulnerabilities and improve both the quality and the security of code.
A specific problem will illustrate the methods in this chapter. On the Drib’s development network infrastructure systems, numerous system administrators must assume certain roles, such as bin (the installers of software), mail (the manager of electronic mail), and root (the system administrator). Each of these roles is implemented as a separate account, called a role_account. Unfortunately, this raises the problem of password management. To avoid this problem, as well as to control when access is allowed, the Drib will implement a program that verifies a user’s identity, determines if the requested change of account is allowed, and, if so, places the user in the desired role.