[e-lang] Securing and taming an existing language

[Bruce Mitchener]

Hopefully this is the right list for this question or set of questions ...

I help maintain the Dylan language, http://opendylan.org/. It is similar
to Scheme, but with a CLOS-style object system, and was originally designed
by various Common Lisp folks at Apple, CMU and Harlequin in the early 1990s.

I'm interested in seeing what we could do to become friendly to object
capabilities.

I've following along with E over the last 17 years off and on and some of
the other efforts. I've read the slides for
http://dynamic-languages-symposium.org/dls-07/program/media/MarkMiller_2007_TradeoffsInRetrofittingSecurityAnExperienceReport_Dls.pdf
... I've also skimmed the paper on taming Pict

I'm curious if there's a good place to start reading for how to:

1) subset a language to remove ambient authority
2) tame unprincipled libraries

I realize that these are big, complicated tasks, but I'd like to evaluate
whether or not this is a feasible direction for Dylan to move in.

Along with the usual issues, Dylan has another interesting complication in
that it is using the CLOS model of OO which is very different from that of
Java, Smalltalk and C++. In the CLOS model, multiple dispatch is used and
the methods (generic functions) don't "belong" to objects or classes. (It
isn't really a message-passing OO.)

Has there been any consideration of that sort of object system and model in
the past with respect to object capabilities?

Cheers,

- Bruce

[Raoul Duke]

emily taming ocaml might be a close place to look for inspiration?
(dylan is cooool!!!)

[Mark S. Miller]

Post by Bruce Mitchener
Hopefully this is the right list for this question or set of questions ...
I help maintain the Dylan language, http://opendylan.org/. It is similar
to Scheme, but with a CLOS-style object system, and was originally designed
by various Common Lisp folks at Apple, CMU and Harlequin in the early 1990s.
I'm interested in seeing what we could do to become friendly to object
capabilities.

Awesome! I remember Dylan fondly.

Post by Bruce Mitchener
I've following along with E over the last 17 years off and on and some of
the other efforts. I've read the slides for
http://dynamic-languages-symposium.org/dls-07/program/media/MarkMiller_2007_TradeoffsInRetrofittingSecurityAnExperienceReport_Dls.pdf
... I've also skimmed the paper on taming Pict
1) subset a language to remove ambient authority
2) tame unprincipled libraries
I realize that these are big, complicated tasks, but I'd like to evaluate
whether or not this is a feasible direction for Dylan to move in.

We've now done this successfully a number of times, for very different
languages and libraries <
http://wiki.erights.org/wiki/Object-capability_languages>, so we should
more concrete lessons we could write down as a record independent of any
one of these efforts. I'm embarrassed to say that we have not made any such
record -- it is all folklore and experience, transmitted through
conversation. Where are you located (feel free to respond privately to
***@gmail.com)? It would probably be good to assemble a group together
for such conversations.

Post by Bruce Mitchener
Along with the usual issues, Dylan has another interesting complication in
that it is using the CLOS model of OO which is very different from that of
Java, Smalltalk and C++. In the CLOS model, multiple dispatch is used and
the methods (generic functions) don't "belong" to objects or classes. (It
isn't really a message-passing OO.)
Has there been any consideration of that sort of object system and model
in the past with respect to object capabilities?

For CLOS itself, I'd say it is rather hopeless. But IIRC, Dylan has a
module system that forms an encapsulated scope, similar to Java's package
scope. Does this, or can this, for a basis for secure encapsulation? If so,
there's an implicit rights amplification hazard that can lead to confused
deputies, but not in a way that's necessarily fatal. I would start from
there.

[Marc Stiegler]

For a taste of taming, the taming of the OCaml library for Emily is quite
small and simple, see a very brief description of it at
http://www.hpl.hp.com/techreports/2006/HPL-2006-116.pdf

But the taming effort that is really informative is the one we did for E. I
have been told by a couple of people that they really came to understand
what taming was about by reading the tables supplied with E that specify
which methods and constructors are allowed, and which are disallowed. Markm
can tell you where to look to see that list. YMMV.

--marcs

On Mon, Feb 23, 2015 at 10:41 AM, Bruce Mitchener <

Post by Bruce Mitchener
Hopefully this is the right list for this question or set of questions ...
I help maintain the Dylan language, http://opendylan.org/. It is
similar to Scheme, but with a CLOS-style object system, and was originally
designed by various Common Lisp folks at Apple, CMU and Harlequin in the
early 1990s.
I'm interested in seeing what we could do to become friendly to object
capabilities.

Awesome! I remember Dylan fondly.

Post by Bruce Mitchener
I've following along with E over the last 17 years off and on and some of
the other efforts. I've read the slides for
http://dynamic-languages-symposium.org/dls-07/program/media/MarkMiller_2007_TradeoffsInRetrofittingSecurityAnExperienceReport_Dls.pdf
... I've also skimmed the paper on taming Pict
1) subset a language to remove ambient authority
2) tame unprincipled libraries
I realize that these are big, complicated tasks, but I'd like to evaluate
whether or not this is a feasible direction for Dylan to move in.

We've now done this successfully a number of times, for very different
languages and libraries <
http://wiki.erights.org/wiki/Object-capability_languages>, so we should
more concrete lessons we could write down as a record independent of any
one of these efforts. I'm embarrassed to say that we have not made any such
record -- it is all folklore and experience, transmitted through
conversation. Where are you located (feel free to respond privately to
together for such conversations.

Post by Bruce Mitchener
Along with the usual issues, Dylan has another interesting complication
in that it is using the CLOS model of OO which is very different from that
of Java, Smalltalk and C++. In the CLOS model, multiple dispatch is used
and the methods (generic functions) don't "belong" to objects or classes.
(It isn't really a message-passing OO.)
Has there been any consideration of that sort of object system and model
in the past with respect to object capabilities?

For CLOS itself, I'd say it is rather hopeless. But IIRC, Dylan has a
module system that forms an encapsulated scope, similar to Java's package
scope. Does this, or can this, for a basis for secure encapsulation? If so,
there's an implicit rights amplification hazard that can lead to confused
deputies, but not in a way that's necessarily fatal. I would start from
there.
--
Cheers,
--MarkM
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

[Mike Stay]

There are three documents about taming javascript and the document
object model (DOM) here:
https://code.google.com/p/google-caja/source/browse/#svn/branches/es53/doc/domado
"DOMado" is a pun: the word means "tamed" in Spanish.

Post by Marc Stiegler
For a taste of taming, the taming of the OCaml library for Emily is quite
small and simple, see a very brief description of it at
http://www.hpl.hp.com/techreports/2006/HPL-2006-116.pdf
But the taming effort that is really informative is the one we did for E. I
have been told by a couple of people that they really came to understand
what taming was about by reading the tables supplied with E that specify
which methods and constructors are allowed, and which are disallowed. Markm
can tell you where to look to see that list. YMMV.
--marcs

On Mon, Feb 23, 2015 at 10:41 AM, Bruce Mitchener

Post by Bruce Mitchener
Hopefully this is the right list for this question or set of questions ...
I help maintain the Dylan language, http://opendylan.org/. It is similar
to Scheme, but with a CLOS-style object system, and was originally designed
by various Common Lisp folks at Apple, CMU and Harlequin in the early 1990s.
I'm interested in seeing what we could do to become friendly to object
capabilities.

Awesome! I remember Dylan fondly.

Post by Bruce Mitchener
I've following along with E over the last 17 years off and on and some of
the other efforts. I've read the slides for
http://dynamic-languages-symposium.org/dls-07/program/media/MarkMiller_2007_TradeoffsInRetrofittingSecurityAnExperienceReport_Dls.pdf
... I've also skimmed the paper on taming Pict
1) subset a language to remove ambient authority
2) tame unprincipled libraries
I realize that these are big, complicated tasks, but I'd like to evaluate
whether or not this is a feasible direction for Dylan to move in.

We've now done this successfully a number of times, for very different
languages and libraries
<http://wiki.erights.org/wiki/Object-capability_languages>, so we should
more concrete lessons we could write down as a record independent of any one
of these efforts. I'm embarrassed to say that we have not made any such
record -- it is all folklore and experience, transmitted through
conversation. Where are you located (feel free to respond privately to
for such conversations.

Post by Bruce Mitchener
Along with the usual issues, Dylan has another interesting complication
in that it is using the CLOS model of OO which is very different from that
of Java, Smalltalk and C++. In the CLOS model, multiple dispatch is used and
the methods (generic functions) don't "belong" to objects or classes. (It
isn't really a message-passing OO.)
Has there been any consideration of that sort of object system and model
in the past with respect to object capabilities?

For CLOS itself, I'd say it is rather hopeless. But IIRC, Dylan has a
module system that forms an encapsulated scope, similar to Java's package
scope. Does this, or can this, for a basis for secure encapsulation? If so,
there's an implicit rights amplification hazard that can lead to confused
deputies, but not in a way that's necessarily fatal. I would start from
there.
--
Cheers,
--MarkM
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

[Mark S. Miller]

[+David, +Adrian, +Tyler]


Joe-E taming of Java: https://code.google.com/p/joe-e/wiki/Taming
Javadoc of Joe-E taming of Java: http://www.cs.berkeley.edu/~daw/joe-e/api/

E taming of Java:
http://www.combex.com/papers/darpa-review/security-review.html#taming
http://www.erights.org/elib/legacy/taming.html
Javadoc of E taming of Java: http://www.erights.org/javadoc/index.html

Although Joe-E's taming was inspired by E's taming, it was purposely done
without reference to the particular E taming decisions so that we could
compare them afterwards and learn from their differences. Unfortunately,
AFAIK, no one has yet done this comparison, though it would still be
interesting.

Post by Marc Stiegler
For a taste of taming, the taming of the OCaml library for Emily is quite
small and simple, see a very brief description of it at
http://www.hpl.hp.com/techreports/2006/HPL-2006-116.pdf
But the taming effort that is really informative is the one we did for E.
I have been told by a couple of people that they really came to understand
what taming was about by reading the tables supplied with E that specify
which methods and constructors are allowed, and which are disallowed. Markm
can tell you where to look to see that list. YMMV.
--marcs

On Mon, Feb 23, 2015 at 10:41 AM, Bruce Mitchener <

Post by Bruce Mitchener
Hopefully this is the right list for this question or set of questions ...
I help maintain the Dylan language, http://opendylan.org/. It is
similar to Scheme, but with a CLOS-style object system, and was originally
designed by various Common Lisp folks at Apple, CMU and Harlequin in the
early 1990s.
I'm interested in seeing what we could do to become friendly to object
capabilities.

Awesome! I remember Dylan fondly.

Post by Bruce Mitchener
I've following along with E over the last 17 years off and on and some
of the other efforts. I've read the slides for
http://dynamic-languages-symposium.org/dls-07/program/media/MarkMiller_2007_TradeoffsInRetrofittingSecurityAnExperienceReport_Dls.pdf
... I've also skimmed the paper on taming Pict
1) subset a language to remove ambient authority
2) tame unprincipled libraries
I realize that these are big, complicated tasks, but I'd like to
evaluate whether or not this is a feasible direction for Dylan to move in.

We've now done this successfully a number of times, for very different
languages and libraries <
http://wiki.erights.org/wiki/Object-capability_languages>, so we should
more concrete lessons we could write down as a record independent of any
one of these efforts. I'm embarrassed to say that we have not made any such
record -- it is all folklore and experience, transmitted through
conversation. Where are you located (feel free to respond privately to
together for such conversations.

Post by Bruce Mitchener
Along with the usual issues, Dylan has another interesting complication
in that it is using the CLOS model of OO which is very different from that
of Java, Smalltalk and C++. In the CLOS model, multiple dispatch is used
and the methods (generic functions) don't "belong" to objects or classes.
(It isn't really a message-passing OO.)
Has there been any consideration of that sort of object system and model
in the past with respect to object capabilities?

For CLOS itself, I'd say it is rather hopeless. But IIRC, Dylan has a
module system that forms an encapsulated scope, similar to Java's package
scope. Does this, or can this, for a basis for secure encapsulation? If so,
there's an implicit rights amplification hazard that can lead to confused
deputies, but not in a way that's necessarily fatal. I would start from
there.
--
Cheers,
--MarkM
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

[Bill Frantz]

Post by Mark S. Miller
[+David, +Adrian, +Tyler]
Joe-E taming of Java: https://code.google.com/p/joe-e/wiki/Taming
Javadoc of Joe-E taming of Java: http://www.cs.berkeley.edu/~daw/joe-e/api/
http://www.combex.com/papers/darpa-review/security-review.html#taming
http://www.erights.org/elib/legacy/taming.html
Javadoc of E taming of Java: http://www.erights.org/javadoc/index.html
Although Joe-E's taming was inspired by E's taming, it was purposely done
without reference to the particular E taming decisions so that we could
compare them afterwards and learn from their differences. Unfortunately,
AFAIK, no one has yet done this comparison, though it would still be
interesting.

I have always been concerned that taming involves many human
decisions, each subject to human error. Comparing two
independent taming projects seems like a good way of finding out
how error prone these decisions actually are. If there are very
few discrepancies, then we can have some confidence that humans
can actually tame. If there are a lot, including dangerous items
that passed one taming example, but not the other, then watch out.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz |"After all, if the conventional wisdom was
working, the
408-356-8506 | rate of systems being compromised would be
going down,
www.pwpconsult.com | wouldn't it?" -- Marcus Ranum

[Raoul Duke]

If there is no formalism then I would fully expect there to be things
that slip past the humans, no surprise there? But that seems to me to
be true of "security" in general. Is not "security" somewhat
subjective anyway, as in we know it in hind sight? :-)