[cap-talk] Confused Deputies in Capability Systems - not

[Marcus Brinkmann]

Sam Mason wrote:
> On Tue, Feb 24, 2009 at 12:12:35AM -0800, Jed Donnelley wrote:
>> At 04:15 AM 2/23/2009, Sam Mason wrote:
>>> In the compiler example this bug can be fixed a couple of ways:
>>>
>>>  1) the compiler shares responsibility with the operating system for
>>>  checking security properties, namely that it ensures the output file
>>>  isn't the same as the bill or any other state the compiler (but not the
>>>  client) has access to
>> I don't think so.  It may well be that the requester and the compiler
>> (server) share access to a file that might be a legitimate sink for
>> the requested output.  The key aspect is that the communicated parameter
>> indicates an object that the sender had access to when sending.  This
>> is exactly what a capability communication system guarantees, but which
>> no mechanism that uses names for designation can supply.
> 
> I was mainly including this example because Marcus was asking why this
> wasn't just a "programming error"[1] that could be fixed in the compiler
> and why capabilities were considered to be such an improvement.  Before
> Jed's message I was beginning to convince myself that Marcus was correct
> and it was "easy" to fix the bug above by just having it check that the
> output file isn't the bill.  I've since realized that it's far more
> complicated than this and it should be checking that the source file was
> readable by the submitting user and the output is going somewhere that's
> writable to the submitting user.  There are other exploitable bugs
> remaining I've not enumerated and probably others I've not considered;
> but if capabilities were used the problems above would disappear (and
> a few others) simplifying things and strengthening the security of the
> system.

I have not suggested that the compiler checks if the supplied file name is the
billing file.  That is a simplistic check that doesn't work very well.  Here
is what I would do if I were to write such a compiler:

Instead, in a Unix implementation the compile should use suid/sgid mechanism
and access() to check user-supplied filenames.  That is a robust mechanism to
solve this problem that is provided by the operating system exactly for this
use case.

The access() check is a positive confirmation that the user has the desired
(read and/or write) access to the file in question at the time of the check.
This is not exactly the same as Jed asked for, he wanted a check that applies
at the time the designation moved from one domain to another.  But the
difference is negligible for all applications I know of.

I find it increasingly disturbing that the criticism of IBAC systems is so
rarely based on best practices in the real world.  Sure enough the capability
community can make its points while giving existing systems the credit they
deserve.  Using relevant real world examples has the other benefit that it
reveals hidden assumptions, goals and limitations.  More about this in my
reply to Jed's pickup mail.  Most importantly, it makes the criticism
approachable by people who are not attracted to capability systems based on
their formal properties alone.

Thanks,
Marcus