[cap-talk] More Heresey: ACLs not inherently bad

[David-Sarah Hopwood]

Raoul Duke wrote:
> Alan Karp writes:
>> If the compiler uses setuid to run as the user, it can't update billing file.
>> If it runs as itself, it will clobber the billing file with the output.
> 
> right -- so that seems to me to make the benefits gained from
> auto-inferring-capabilities not all that more exciting than just
> making programs setuid as the user invoking them.

I'm confused by your position. The capability system with the
powerbox-based command-line shell (what you are calling the
"auto-inferring" system) prevents the confused deputy attack; the
setuid mechanism does not, for the reason that Alan Karp points out.
I'll repeat the argument I made in a previous post for why the
cap system prevents this attack:

Raoul Duke wrote:
>> >> The same inferences can be drawn from command line input.
> >
> > "Some user came to know the name (SYSX)BILL and supplied it to the
> > compiler as the name of the file to receive the debugging
> > information." [1]
> >
> > how does the ability to inference-and-add abilities save us?

That user only came to know the *name* (SYSX)BILL. They did not
themself have access to (SYSX)BILL; instead they relied on the
compiler's access to it.

So, if a shell acting on behalf of user U maps command line
arguments to capabilities based on U's authority, that would
not prevent capabilities from solving the confused deputy problem
in this case.

Note that in a typical capability OS, the system call that executes
a program does not take a string as the program's command line; it
requires a collection of typed parameters each of which can be a
capability. The filename->capability mapping would be functionality
only of the command-line shell, not of this system call. Even if a
'posix_spawn' or similar API is retained for compatibility, it
wouldn't perform this mapping.

-- 
David-Sarah Hopwood