[cap-talk] Confused Deputies in Capability Systems

[Bill Frantz]

toby.murray at comlab.ox.ac.uk (Toby Murray) on Wednesday, February 11, 2009 wrote:

>char msg[] = ... 
>char rmsg[] = ...
>unsigned int len;
>while (true) {
>    uint index, replyCap;
>    recvFromAnyone(msg,sizeof(msg),&len,&replyCap);
>    index = atoi(msg);
>    sendAndReceive(index,msg
>+sizeof(uint),len-sizeof(uint),rmsg,sizeof(rmsg),&len);
>    sendMessage(replyCap,rmsg,len)
>}

I must say when I saw this example I thought, why is the program storing a
capability that users shouldn't access in the same data structure as the
ones they may access?

But, if we assume a complete break, like from a classic buffer overrun,
then it doesn't matter where the capability is stored, bad-boy code will
get it and use it. The solution is not to store powerful capabilities where
buggy programs have access to them.

Weakeners (like front ends that make R/W capabilities R/O) and multiplexers
(like a network driver) are going to be part of the reliance set of the
facilities that depend on them for security. We can hope they will be small
and well isolated, so they can be practically checked for correctness.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        |"After all, if the conventional wisdom was working, the
408-356-8506       | rate of systems being compromised would be going down,
www.periwinkle.com | wouldn't it?" -- Marcus Ranum