[cap-talk] Are Guards Ambient Authorities?

[Kevin Reid]

On Oct 7, 2009, at 17:41, Grant Husbands wrote:

> A while ago, tav tried to encourage/demonstrate capability-secure
> Python. Some early attacks against the provided example were
> parameters that pretended to be strings but were more insidious, and
> similar type trickery. With some interesting code, tav was able to
> defend against these attacks, in a way that seems reminiscent of
> guards.
>
> However, it brought to mind that duck-typing capability languages most
> likely need guards for almost any time a value would otherwise be
> assumed to be of a particular type. These guards seem to be an ambient
> authority, though, which seems to undermine some of the principles of
> capability security.
>
> Guards also apparently undermine the principles of duck-typing.
> Talking about files, say, I can no longer give a file-like object to
> an object that expects a file, if it uses a guard on the incoming
> parameter. As a programmer who wants that influence, Do I need to
> control the other object's compile-time environment in order to
> control the otherwise-ambient authority it carries?

These are not ambient; they are "well-known". In *principle* you can  
evaluate in an environment which doesn't reveal them, or at least give  
something else the standard name.

(It's also debatable whether they're "authorities".)

> I always expected that a capability-based system would allow me to
> give out file-like objects rather than files. Was I wrong? Is there a
> difference between integer-like objects and (read-only, say) file-like
> objects?

Yes, there is a key difference. The E- (or Python-) provided integer  
objects represent all integers. There is no reason to want something  
else, because something else either is not an integer (and so  
shouldn't be accepted) or is different from the standard number object  
protocol (and so shouldn't be accepted)[*].

There *is* on the other hand reason to want "file-like" objects which  
are proxies for things other than OS files.

For this reason, I tend to agree with you in the particular case that  
the File-guard-which-accepts-only-OS-files *should* be not well-known  
(available in the safeScope, er, safeEnv), but rather part of the  
privileged environment so that code which wants to accept only "real  
files" must be parameterized with respect to what a real file is.

In general, *data structure* guards may be well-known; guards for  
external authorities (and possibly even for internal ones, mutable  
objects?) should not.


[*] Well, you could want numbers which *extend* the standard integer  
protocol. But that's a future compatibility hazard, and is difficult  
to maintain anyway due to integer literals; if you want this the  
proper thing to do is make your extended-integer objects __conformTo  
the integer guard to turn into regular integers, and make your  
extended-integer guard which coerces regular integers into yours. Then  
your code can interop with unaware standard code.

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>