Sand-boxing

Sand-boxing

[Jon Harrop]

We're gearing up for the release of our hardware-accelerated vector graphics 
engine, Smoke. As our foray into web programming, I'd like to create a new 
kind of browser that allows content to be scripted in OCaml.

What is the best way to execute downloaded OCaml code safely?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?e

Re: [Caml-list] Sand-boxing

[skaller]

On Tue, 2007-05-29 at 03:01 +0100, Jon Harrop wrote:
> We're gearing up for the release of our hardware-accelerated vector graphics 
> engine, Smoke. As our foray into web programming, I'd like to create a new 
> kind of browser that allows content to be scripted in OCaml.
> 
> What is the best way to execute downloaded OCaml code safely?

The same way Flash works (or, in my case, doesn't work).
On Firefox this uses a plugin which can be installed by 
the client on demand (only the Flash vendors are
rather stupid and don't provide a 64 bit version
so you can't run Flash on AMD64 or ia64 Linux)

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Sand-boxing

[pierre chambart]

Jon Harrop wrote :
> We're gearing up for the release of our hardware-accelerated vector graphics 
> engine, Smoke. As our foray into web programming, I'd like to create a new 
> kind of browser that allows content to be scripted in OCaml.
>
> What is the best way to execute downloaded OCaml code safely
You can use the dynlink library.
When you load module with that, you can specify the modules that can't
be accessed from the loaded code.

http://caml.inria.fr/pub/docs/manual-ocaml/libref/Dynlink.html#6_Accesscontrol

Re: [Caml-list] Sand-boxing

[Alain Frisch]

pierre chambart wrote:
> You can use the dynlink library.
> When you load module with that, you can specify the modules that can't
> be accessed from the loaded code.

This can catch some errors, but it is not a real security
mechanism! The "security model" relies on the assumption that the loaded
modules have been produced by ocamlc from well-typed programs that don't
use unsafe features. The bytecode interpreter does not try to protect
itself against ill-behaved code at all.

  Alain

Re: [Caml-list] Sand-boxing

[Jon Harrop]

On Tuesday 29 May 2007 06:12:15 Alain Frisch wrote:
> pierre chambart wrote:
> > You can use the dynlink library.
> > When you load module with that, you can specify the modules that can't
> > be accessed from the loaded code.
>
> This can catch some errors, but it is not a real security
> mechanism! The "security model" relies on the assumption that the loaded
> modules have been produced by ocamlc from well-typed programs that don't
> use unsafe features. The bytecode interpreter does not try to protect
> itself against ill-behaved code at all.

But if the browser downloads the OCaml source code from the server, compiles 
it using ocamlc with restrictions on the client and then dynlinks it, 
everything should work safely? This was actually Francois Rouaix's idea. I 
think it will be much more user-friendly to put OCaml source code on your web 
server. The only problem I can think of now is malicious sites exploiting 
exponential type growth to hang the client's ocamlc. :-)

I assume I can ban the code from accessing LablGL directly (it is unsafe) but 
I can allow it to access our library that uses LablGL (which is safe)?

I think this is a killer idea! Instead of writing a web page in HTML, you 
write it in OCaml and call our library to generate a scene graph for your 
entire site.

Incidentally, I'm uploading our vector graphics library:

  http://www.ffconsultancy.com/products/smoke_vector_graphics/

The Linux demos should all work now and I'm working on the free edition 
downloads. I'm particularly keen to know if the x86 Linux demos work because 
they were built in a 32-bit chroot on my AMD64...

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?e