Star Wars and Least Common Mechanism
Today, in Friday Star Wars Security blogging, we continue with Saltzer and Schroeder, and look at their principle of Least Common Mechanism:
Least common mechanism: Minimize the amount of mechanism common to more than one user and depended on by all users [28]. Every shared mechanism (especially one involving shared variables) represents a potential information path between users and must be designed with great care to be sure it does not unintentionally compromise security. Further, any mechanism serving all users must be certified to the satisfaction of every user, a job presumably harder than satisfying only one or a few users. For example, given the choice of implementing a new function as a supervisor procedure shared by all users or as a library procedure that can be handled as though it were the user’s own, choose the latter course. Then, if one or a few users are not satisfied with the level of certification of the function, they can provide a substitute or not use it at all. Either way, they can avoid being harmed by a mistake in it.
The reasons behind the principle are a little less obvious this week. The goal of Least Common Mechanism (LCM) is to manage both bugs and cost. Most useful computer systems come with large libraries of sharable code to help programmers and users with commonly requested functions. (What those libraries entail has grown dramatically over the years.) These libraries are collections of code, and code that has to be written and debugged by someone.
Writing secure code is hard and expensive. Writing code that can effectively defend itself is a challenge, and if the system is full of large libraries that run with privileges, then some of those libraries will have bugs that expose those privileges.
So the goal of LCM is to constrain risks and costs by concentrating the security critical bits in as effective a fashion as possible. Which, if you recall that the best defense is a good offense, leads us to this week’s illustration:
This is, of course, the ion cannon on Hoth destroying an Imperial Star Destroyer, and allowing a transport ship to get away. There is only one ion cannon (they’re apparently expensive). It’s a common mechanism designed to be acceptable to all the reliant ships.
That’s about the best we can do. Star Wars doesn’t contain a great example of minimizing common mechanism in the way that Saltzer and Schroeder mean it. Also hard to find good examples of is separation of privilege. Unless someone offers up a good example, I’ll skip it, and head right to open design and psychological acceptability, both of which I’m quite excited about. They’ll make find ends to the series.
If you like the concept, why not check out the Star Wars category archive?
In Episode 1 all the droids were shut down by the failure of 1 system. That seems like a failure to implement the LCM principle…
I find that LCM is the Least Intuitive Principle. I think the reason for this is that when most people these days think of a shared mechanism, they think of shared libraries, and I believe the principle doesn’t apply to them.
Yes, writing a large number of support libraries has the potential of introducing bugs, but having everyone roll their own seems even more error prone. For example, the JPEG vulnerability had a lot of impact, but we were able to eliminate them in a fairly short amount of time. If a well-tested and widely used component has bugs, can you imagine how many more vulnerabilities there would be in the hundreds of home-brewed JPEG implementations?
The principle text talks about something else, though. First, it mentionsshared data & resources as channels for information flow — something notably absent from shared libraries. The second example in fact advocates writing shared libraries instead of a privileged service used by everyone. I still have trouble wrapping my head around that one, since if there’s something in your system that could be implemented as a user library, even if you do provide a privileged implementation of it, there’s nothing forcing your users from switching.
So really, I think the principle (or at least its second part) is saying that you want to design your system so that few mechanisms require privilege, but that’s not the image evoked by the phrase “LCM.”
Maybe “keep the TCB small” is what they are driving at. When there’s a choice of whether something goes in the TCB prefer the option where it doesn’t.
Nikita,
I’m with you that this is a hard one, and think your analysis is good. Would you dump it if you could re-do the list? There’s already least priv.
Anon,
TCB post-dates Saltzer and Schroeder, so that’s cheatin’.