[cap-talk] Capability-secure subsets of existing languages
david.nospam.hopwood at blueyonder.co.uk
Tue Nov 2 13:14:41 EST 2004
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
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
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>
More information about the cap-talk