Friday Star Wars: Principle of Fail-safe Defaults
In this week’s Friday Star Wars Security Blogging, I’m continuing with the design principles from Saltzer and Scheoder’s classic paper. (More on that in this post.) This week, we look at the principle of fail-safe defaults:
Fail-safe defaults: Base access decisions on permission rather than exclusion. This principle, suggested by E. Glaser in 1965 means that the default situation is lack of access, and the protection scheme identifies conditions under which access is permitted. The alternative, in which mechanisms attempt to identify conditions under which access should be refused, presents the wrong psychological base for secure system design. A conservative design must be based on arguments why objects should be accessible, rather than why they should not. In a large system some objects will be inadequately considered, so a default of lack of permission is safer. A design or implementation mistake in a mechanism that gives explicit permission tends to fail by refusing permission, a safe situation, since it will be quickly detected. On the other hand, a design or implementation mistake in a mechanism that explicitly excludes access tends to fail by allowing access, a failure which may go unnoticed in normal use. This principle applies both to the outward appearance of the protection mechanism and to its underlying implementation.
I should note in passing that a meticulous and careful blogger would have looked through the list and decided on eight illustrative episodes before announcing the project. Because, on reflection, Star Wars contains few scenes which do a good job of illustrating this principle. And so, after watching A New Hope again, I settled on:
OFFICER: Where are you taking this…thing?
LUKE: Prisoner transfer from Block one-one-three-eight.
OFFICER: I wasn’t notified. I’ll have to clear it.
HAN: Look out! He’s loose!
LUKE: He’s going to pull us all apart.
Now this officer knows nothing about a prisoner transfer from cell block 1138. (Incidentally, I’d like to know where the secret and not-yet-operational Death Star is getting enough prisoners that they need to be transferred around?) Rather than simply accepting the prisoner, he attempts to validate the action.
You might think that it’s a cell block–how bad can it be to have the wrong wookie in jail? It’s not like (after Episode 3) there’s much of the WCLU left around to complain, and the Empire is ok with abducting and killing the Royal Princess Leia, so a prisoner in the wrong cell is probably not a big deal, right? Wrong.
As our diligent officer knows, “A conservative design must be based on arguments why objects should be accessible, rather than why they should not.” The good design of the cell block leads to a “fail[ure] by refusing permission, a safe situation, since it will be quickly detected.” Now, Luke and Han also know this, and the officer happens to die for his care. Nevertheless, the design principle serves its purpose: The unauthorized intrusion is detected, and even though Luke and Han are able to enter the cell bay, they can’t get out, because other responses have kicked in.
Had the cell block operations manual been written differently, the ruse might have worked. Prisoner in manacles? Check! (Double-check: they don’t quite fit.) Accompanied by Storm Troopers? Check! (Double-check: one’s a bit short.) The process of validating that something is ok is more likely to fail safely, and that’s a good thing. Thus the principle of fail-safe defaults.
If you enjoyed this post, a good way to read more of the series might be the Star Wars category archive.