[cap-talk] Need help with the confused deputy problem and Object-capability model

Toby Murray toby.murray at comlab.ox.ac.uk
Wed May 21 17:48:26 CDT 2008


On Wed, 2008-05-21 at 15:35 -0700, Mark Miller wrote:
> On Wed, May 21, 2008 at 2:16 PM, Toby Murray
> <toby.murray at comlab.ox.ac.uk> wrote:
> > The object-capability model solves this problem because here, the user
> > can name the file if and only if they can access it. Hence, if they
> > cannot access a file, they cannot name it and hence, the vulnerability
> > doesn't arise.
> 
> 
> This is a good start, but I don't think it goes to the heart of the
> matter. For example, if the user happens to have read-only access to
> the compiler's billing record file, then the user can name the file.

No, I disagree. We're in the object-capability model here, not a
capability-based OS. Hence, if the user has read-only access to the
file, in the OCap model this amounts to having a capability to a
ReadOnly Facet for that same file. The user cannot name the Compiler's
billing file but only a facet to it that allows only reading. It is this
object that the Compiler attempts to write to, not the billing file.
Hence, I argue that in the Ocap model, this remains the essence.

>Thee reason the attack still fails is that the rights the compiler will
> bring to bear on writing the compilation output is only those rights
> bundled with the designator provided by the user, even though the
> compiler itself separately possesses adequate rights to the designated
> object.

The OCap model has no notion of rights. I agree that in a practical OS
implementation, that the above is how the scenario plays out. But the
original question pertained to the the OCap model in particular.

Ricky Liu wrote:
> Hi, I am reading the paper of Mark S. Miller about the object
> capability model. However, I am still not very clear about how the
> confused deputy is solved using this model. So could anyone please
> give me some clue or advice to help me out?

Am I splitting hairs here? Probably ;)

Cheers

Toby


More information about the cap-talk mailing list