Response from Rohan Padhye
===========================

1) Why is the compiler the "confused deputy"?

The compiler is designed to read/write files from exactly those locations that it has the OS-granted "home license", and the file(s) specified by the user as arguments during invocation. However, these instructions/permissions could conflict with each other and in this case there is no mechanism to resolve such a conflict; hence the compiler is a "confused deputy".

2) How could capabilities have prevented the confusion?

With capabilities, the compiler would deal with unforgable tokens of authority instead of plain-text filenames. Hence, the OS would have to hand over some write capabilities (an object with access rights and implicit references to actual filesystem locations) to the compiler as would the user who is invoking the compiler. The user would not be able to get the write capability to the billing file and hence would not have been able to provide it as an argument which was meant for a debugging output location. Since the security check has moved from a generic "Can the compiler access this resource?" to "Can the system grant this resource?" and "Can the user write to this resource?", the different intents of the OS-granted home license and user-granted debug file location are separated cleanly.

3) Describe how Capsicum can be used for Chromium, based on our discussion of Chromium's security architecture last time. 

Chromium's architecture is designed for privilege separation, where the renderer component executes with a lower privilege than the browser kernel. However, there is no standard mechanism for enforcing such sandboxing of the renderer and this leads to complex OS-specific implementations with varying levels of security. Even on UNIX systems, the base approaches were not perfect. For example, (1) a sandbox based on chroot restricts file access to a particular subtree of the file-system, but does not provide fine constraints on other resources such as shared memory or network access, (2) SELinux-type MAC requires system admin privilege to modify/configure privileges, thus preventing dynamic configuration and (3) the custom seccomp mode requires a complex implementation of thousands of lines of assembly which is difficult to maintain and verify.

Capsicum can be helpful in this case since it allows the browser kernel to instantiate rendering engines with a white-list of file descriptors (files, sockets, etc) that it is allowed to access and prevent arbitrary access of resources and privilege escalation using the cap_enter primitive of Capsicum. The rendering engine will be linked to libcapsicum and since system calls have to go through this library before reaching the OS, accidental leakage of resource access can be minimized.


Response from Tobias Boelter
=============================

1) Why is the compiler the "confused deputy"?
The core problem here is ambient authority, i.e. the compiler runs with authority coming from multiple sources: The “home files license”, that he needs to write the statistics and billing information, and the user’s authority that he needs to access user supplied files. In a privileged operation the compiler doesn’t a priori know which authority to use, which makes him a “confused deputy”.

2) How could capabilities have prevented the confusion?
If capabilities were used, the developer had to specify a specific capability for each write operation. He would then use a “home file capability” to write to the statistics and billing file and a user supplied capability to write to the output file. Because the user could only generate capabilities to access files which he has the right for, he can not generate a capability for the billing file.

3) Describe how Capsicum can be used for Chromium, based on our discussion of Chromium’s security architecture last time.
Capsicum could be used to implement the sandboxing of the rendering engines in Chromium. Because the components in Chromium are already well separated, this is a straightforward process.