Re: browser execution
Karl Lehenbauer <karl@sugar.neosoft.com>
Subject: Re: browser execution
To: sugar!bsdi.com!sanders@dxmint.cern.ch
Date: Tue, 29 Jun 1993 17:32:20 -0500 (CDT)
From: Karl Lehenbauer <karl@sugar.neosoft.com>
Cc: www-talk@nxoc01.cern.ch
In-reply-to: <9306291821.AA05096@austin.BSDI.COM> from "Tony Sanders" at Jun 29, 93 01:21:01 pm
X-Mailer: ELM [version 2.4 PL5]
Content-Type: text
Content-Length: 1469
Message-id: <9306291732.AA10920@NeoSoft.Com>
> Marc wisely said:
> > Having browsers execute code is *very* scary. Servers generally run
> > (or should run -- no reason not to) as userid 'nobody', and as such
> > can cause practically no damage to anything. In any case, server
> > writers have much more knowledge about what's going to happen and what
> > could happen while writing a server than client users do while just
> > randomly clicking hyperlinks. I don't see as there's any reason to
> > think that client-side execution is safer.
>
> In either case you should probably **seriously** think about running
> in a chroot()'ed environment (which requires root perms to setup
> of course).
>
> Also, what about DOS environments (et.al.) where you have neither file
> permissions nor chroot(). I think you are just SOL.
We are involved in some work on safe Tcl which will become part of
active email under MIME. The idea is that a subordinate Tcl interpreter
can be created that is restricted only to operations that are safe --
file access, forking, etc, are unavailable. The "regular" Tcl interpreter
can also export commands to the safe interpreter which are executed
in the regular interpreter's environment -- totally analogous to an
operating system's system calls.
I am about to post a secure Tcl experimenter's kit to comp.lang.tcl.
It would be a good candidate, IMHO, for delivering active HTML messages
(i.e. programs) that can be executed safely, even though the sender
isn't trusted.