Francois Rouaix <Francois.Rouaix@inria.fr> wrote:
> Yes, naturally. Security is *the* important issue with applets !
> Basically (to make a long story short), security relies on the type and 
> module system.
[...]
> Finally, please note that I'm not making any claim about security yet.
> Although I've been working on identifying and blocking security holes for
> several weeks, I may have forgotten something.

and in http://pauillac.inria.fr/~rouaix/mmm/applets.html, he wrote:
>    Bytecode integrity
>      All of the above mechanisms rely on bytecode integrity : all checks are
>      done at (dynamic) link-time. The checks therefore assume that the
>      bytecode is the intact output of an unmodified CSL compiler. The solution
>      we choose is to provide support for PGP-authentication. In paranoid mode,
>      each loading of foreign bytecode is subject to confirmation by the
>      user. When the bytecode has been PGP-signed, the user is shown the PGP
>      diagnostic on the file.

Confirmation by the user sounds stupid to me. How is he supposed to know
that the bytecode is correct ? I see a few alternatives:
- somehow check the bytecodes (Java does it, but I have no idea if it's
  doable with CSL's bytecodes)
- transmit source rather than byte codes (since source code can be checked
  easily)
- use authentication: the bytecode has to be signed by some trusted entity.
  It would for instance be possible to provide a mail server that receives
  CSL source, compiles it, and signs it with its private key: checking the
  signature against the widely available publickey would prove that it is
  really the output of an unmodified CSL compiler. This would probably require
  the use of PGP3's API since forking a PGP for each execution sounds
  awfully expensive to me (the advantage of having precompiled bytecode
  would be less obvious)

>    Denial of service
>      MMM does not offer protection against this type of attack. A trivial
>      example is a non-terminating applet : since CSL does not provide threads,
>      the browser will get stuck in the execution of the applet, and the only
>      remedy is to kill the browser.

I can deal with this. Providing threads would be a good idea anyway in CSL, tho.
But it should be possible to restrict the CPU and memory usage (and probably
other aspects like network, file system, processes, etc...) of a thread.


	Stefan