Confused deputies are an important kind of software vulnerability that cannot be prevented in most current computer systems.

Part 1: the plot

... in which the good guy and the bad guy make their entrance.

Well designed software often contains parts that provide a service for other parts, like doing something complex and specialized. I will call these parts "subjects" in general, but you can think of them as components, procedures, objects, functions, processes or subroutines if you like. In a secured system, subjects cannot do just anything: they need the right permission. Therefore service subjects will often need to use their client's permissions, like one to read an input file and another one to write results to an output file. If that is the case, then the service subject is called a "deputy", because it does things on behalf of its clients, with permissions delegated by its clients.

A deputy is confused when he accidently uses his own permissions where he should have used the permissions of his client. For instance, one of his clients could tell the deputy to read input from a file the deputy is allowed to read, but the client is not. How should the deputy protect himself againts tricks like that?

Part 2: the culprit

... in which everything is blamed on the "system".

Deputies can be confused when security is managed by a part of the system, external to the software, as I will explain now.

The special part is called a "reference monitor", and its task is to decide which subjects are permitted to use what other subjects. The reference monitor cannot know what the subjects are up to, and therefore it has to distrust the subjects completely, and go only by its list of who has what permission. For instance its list may indicate that a process that is run by user Fred has read-permission to Fred's email. Such a list is usually called an access control list (ACL).

Splitting up responsibilities between the software and the system like this is called "separation of concerns", and it is a good design principle, because it allows programmers to concentrate on making the program do the right things, and it allows system administrators to concentrate on preventing the program from doing the wrong things.

However, in this case, the separation of concerns has gone too far, because from the confused deputy example, it seems that the deputy's permission to use something should depend on what he is planning to do with it. The deputy should have permission to read his own file at any time, for his own purposes but not for his client's purposes, unless that client also happens to have permission to read that file.

If you are still reading, expect now to be rewarded with the simple and genial solution to this seemingly complex problem of intentions.

Part 3: the cure

... in which the end of the fairy tale is revealed and it turns out we have to do everything ourselves.

The client always has to tell the deputy where his files are, so he has to give a "designation" of his files. Usually that is the name of the file and its place on the hard disk. Instead of a plain designation, let us use "magic" designations that cannot be forged and that contain the client's permission. Anyone who gets hold of the designation is automatically allowed to use it.

Such a magical designation is called a capability. The deputy can simply use the capabilities provided by a client for that client's purposes, and use its own capabilities only for his own purposes. Nobody has to do any accounting and check the access control list. The client cannot give a capability designating the deputy's file unless he got it in a rightful way (not by forgeing). The deputy can be sure the proper permission is applied when he uses the capability provided by his client.

This solution is known for years, and was published by Norman Hardy on his website:

The capability approach is simple and does not require a stateful reference monitor (one with a list). But it shifts the burden of security to the programmer. Tools are being built, and methods are being invented to make this new task feasible. Confused deputies are a real problem and can only be prevented this way, so if you are a programmer like me, expect this task to be coming your way some day.


Clicking on an external link will bring you to a page where you have to click again on the link to get there.

Confused Deputies

Capability Based Security

Capability Secure Programming Languages:

Capability Secure Operating Systems:

Log in or register to write something here or to contact authors.