[cap-talk] basic question: concerning confused deputy

[Matej Kosik]

Toby Murray wrote:
> On Mon, 2007-02-26 at 13:53 +0100, Matej Kosik wrote:
>> Friends,
>>
>> Can anyone please shed more light on "confused deputy"? This basic definition
>>
>> http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html
>>
>> confused me. It is either very simple or very intricate. Can you give me some more examples, for example in context of ordinary UNIX-like system?
>>
> My favourite confused deputy example comes from Fred Spiessens' thesis:
> http://www.info.ucl.ac.be/~fsp/fsp_thesis.pdf
> 
> See section 8.1.5 “Little Snitch” : A User Experience with Reference
> Monitors
> 
> Fred describes ssh as the ultimate confused deputy here, when granted
> blanket authority to access the network by a reference monitor such as
> Little Snitch on Mac OSX.

Interesting (simple) examples. Thank you.

Is the "confused deputy" subset of problems related to "excess of authority"?

Excess of authority can be explained very well. In the Fred's ssh example we can easily identify such excess (though ACL gives us no mechanisms to solve it; at least not by the price of making the kernel (the guard guarding usage of ambient authority) more complicated. It does not have sense to do that because in order to be able to enforce those interesting security policies that can be achieved with capabilities the kernel would have to be infinitely complicated.). I think.

> 
> I've always liked this example ever since I first read it a couple
> months back.
> 
>> Might `system task' in Minix3 be a good example of confused deputy?
> 
>>From your description and my own understanding of confused deputy, I'd
> agree that the system task in Minix 3 is a confused deputy.
> 
> Any process/agent/object/whatever P that receives commands from some
> other process/agent/object/whatever Q that contain non-authority
> -carrying designations, which P responds to by wielding its own
> authority have the potential to be confused deputies, as far as I see
> it.
> 
>> Details: All device drivers in Minix3 were "lifted to user space". These device drivers cannot do "dangerous" operations themselves (such as copying whatever whereever in memory or using IN and OUT instructions for talking to the hardware devices directly). However, the `system task' which runs in the privileged mode happily does that for them.
>>
>> Here
>> http://www.minix3.org/doc/AppendixB.html
>> the file `kernel/table.c' on lines 06000--06121 actually defines the security policy via access-control lists. It defines
>> - which kinds of processes can use which communication primitives
>>   (the device drivers, line 06057, are allowed to use all primitives)
>> - which processes can talk to which other processes
>>   (the device drivers, line 06071, are allowed to talk to the `system task')
>>   (this is necessary because so called `endpoints' in Minix are ambient, i.e. forgeable)
>> - which processes can use which kernel calls (various services provided by the `system task')
>>   (the device drivers, line 06084, can, among other things use
>>    - SYS_VIRCOPY (they can ask system task memory between arbitrary address spaces)
>>    - SYS_DEVIO (they can ask the system task to perform any kind of I/O operation
>>   )
>>
>> Thus, effectively, although device drivers (clients) cannot do dangerous operations themselves, the security model and security policy gives them authority to do that because `system task' is confused deputy?
>>
>> Such separation indeed reduces the impact of unintentional errors (that is indeed an improvement), but it still does not prevent malicious behavior. 
>> _______________________________________________
>> cap-talk mailing list
>> cap-talk at mail.eros-os.org
>> http://www.eros-os.org/mailman/listinfo/cap-talk
> 
> 
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
> 


-- 
Matej Kosik

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20070226/c7274b92/attachment.bin