Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] language-based permissions?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Nicolas Cannasse <warplayer@f...>
Subject: Re: [Caml-list] language-based permissions?
>     I noticed that as of OCaml 3.05, there was a new option,
> "-nostdlib".  It seems superficially like with this, and the
> "-nopervasives" option, you could do language-based security (as in the
> MMM web browser of yore, Java, and Perl's Safe module, among many others.)
>     In the attached three files, it seems like "foo.ml" should only be
> allowed to see, and use, the primitives in "fileworld.ml" (which aren't
> much; this is a toy example.)  If "foo.ml" tries to use anything else
> (as in the commented-out "print_string" line), it gets "Unbound value"
> errors in compiling, and can't.
>     My question: could "foo.ml" call other primitives somehow, even
> though they're not linked in?  Using the preprocessor, or "external"
> functions", maybe?  (Assuming that you don't use the  "-unsafe" option,
> of course...)

About security :
Primitive calling is not the only way to compromise security in a virtual
machine, there is also buffer overflows, among others. Currently the Ocaml
bytecode VM is not performing any check, and then is relying on a
well-formed bytecode (means : correct structure, and passed through the
type-checker). Even if you forbid the use of all "dangerous" primitives they
might still be a lot of security holes involving malicious-formed bytecode.
One hope : since the ocaml GC-allocated memory is not on the C heap, it's
then a lot more difficult to exploit.

The bad news is that if you want a perfect secure VM, you should check most
of the primitives arguments types at runtime, thus giving back the speedup
you got from type checking at compile time.

Nicolas Cannasse

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners