[cap-talk] Confused Deputies in Capability Systems

[Sandro Magi]

David-Sarah Hopwood wrote:
> How does a path string get vetted?
> 
> If:
>  - vetted-paths are unforgeable, can be delegated between subjects,
>    and are only given to subjects that are authorized to access the
>    file at that path [*];
>  - such vetted values are the *only* way to access any kind of
>    access-controlled object;
>  - there are no other implicit channels by which authority can be
>    obtained or transmitted;

I was thinking of a sort of trusted object which performs the check at
the appropriate time. In C#:

public sealed class VettedPath
{
  string path;

  // no way to construct an instance
  VettedPath () {}

  // implicit coercion of a string to a VettedPath
  // that performs the access check at time of creation
  public static implicit operator VettedPath(string path)
  {
    // access check, throws UnauthorizedException
    File.AccessCheck(path);
    return new VettedPath(path);
  }
}

So the compiler would accept only the trusted object:

public Compiler
{
  public byte[] Compile(VettedPath filePath) { ... }
}

And the client would invoke:

public MaliciousClient
{
  Compiler compiler;

  public void Main()
  {
    string billingPath = "/var/compiler/bill.log";
    // file path implicitly converted to VettedPath
    // throws UnauthorizedException
    compiler.Compile(billingPath);
  }
}

Looks a bit like capabilities since they are delegable authorizations,
but they seem to have a different flavour, since it's not a direct
object reference, but a sort of reified "authorization context".

VettedPath is a little special-purpose however, but perhaps it can be
generalized in some way (carry a principle id to authorize certain
actions?).

Sandro

> then we have a capability system (if ACL access controls are still
> supported, it is a hybrid capability system), and the vetted values
> are capabilities. If not, then we still have vulnerabilities
> (confused deputy or excess authority).
> 
> 
> [*] Identifying files in a way that does not depend on paths, i.e.
>     so that a file's identity is stable over moves, may be preferable.
>