[cap-talk] Capability-secure subsets of existing languages

[David Hopwood]

Ben Laurie wrote:
> Stiegler, Marc D wrote:
> 
>> David, you are the one who was able to rip through an app that *was*
>> written in a capability secure language, with no ambient authorities
>> laying around, and still find great security breaches. Think how
>> boringly easy it would be to find breaches in a program written with a
>> language where all those super-power authorities are just laying around,
>> begging to be abused, with only the willpower of the programmer at 2AM
>> in the morning before the deadline standing between that power and a
>> breach :-)
>>
>> While I'm responding, since you used Java as your example, just thought
>> I'd mention that a capability-secure version of 100%pure Java, Joe-E, is
>> possible, if you use an appropriate verifier. That version of Java could
>> make sense -- but it is once again a true capability-secure language.
> 
> Interesting. Could this approach be applied to C++? Perl? Python?

C++: no, not without changing the language so much that it would be
unrecognisable or unattractive to most C++ programmers. If I wanted
to make a C-family language cap-secure, I'd start with Cyclone
(http://c2.com/cgi/wiki?CycloneLanguage).

Perl: I don't know.

Python: probably yes. The reflection facilities are insecure; they would
have to be removed or redesigned. The standard libraries would have to be
subsetted.

I've been thinking about changes needed to Erlang, Oz, Python, Haskell,
OCaml, Smalltalk/Squeak, and Cyclone to make them capability-secure, but
they're mostly in my head at the moment rather than written up.
(Scheme has already been done: http://pluto.mumble.net/~jar/pubs/secureos/)

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>