Re: [Caml-list] Sand-boxing

[Jon Harrop <jon@ffconsultancy.com>]

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