From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.6.10/8.6.6) id RAA00597 for caml-redistribution; Tue, 28 Nov 1995 17:12:24 +0100 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.6.10/8.6.6) with ESMTP id RAA00534 for ; Tue, 28 Nov 1995 17:09:41 +0100 Received: from margaux.inria.fr (margaux.inria.fr [128.93.8.2]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id RAA26415 for ; Tue, 28 Nov 1995 17:09:37 +0100 (MET) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by margaux.inria.fr (8.6.10/8.6.6) with ESMTP id RAA06417 for ; Tue, 28 Nov 1995 17:09:36 +0100 Received: from liasg6.epfl.ch (root@liasg6.epfl.ch [128.178.155.48]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id RAA26411 for ; Tue, 28 Nov 1995 17:09:29 +0100 (MET) Received: from lia.di.epfl.ch by liasg6.epfl.ch with esmtp (Smail3.1.29.1 #28) id m0tKSaf-0002khC; Tue, 28 Nov 95 17:09 MET Message-Id: From: "Stefan Monnier" To: Christophe Raffalli Cc: caml-list@margaux.inria.fr Subject: Re: MMM, a Web browser with applets in Caml Special Light In-reply-to: Francois.Rouaix's message of Tue, 14 Nov 1995 15:49:40 +0100. <199511141449.PAA02853@fronsac.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Nov 1995 17:09:01 +0100 Sender: weis Francois Rouaix 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