[5961] in www-talk@info.cern.ch
Re: How about a Safe Virtual Machine?
daemon@ATHENA.MIT.EDU (Brian Behlendorf)
Fri Sep 30 23:06:40 1994
Date: Sat, 1 Oct 1994 04:03:44 +0100
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: brian@wired.com
From: Brian Behlendorf <brian@wired.com>
To: Multiple recipients of list <www-talk@www0.cern.ch>
On Sat, 1 Oct 1994, Daniel W. Connolly wrote:
> Hmm... the more I think about it, the less interesting it becomes to
> think about executing completely untrusted, anonymous programs. The
> interesting part is to allow programs access to exactly the set of
> resources that they are authorized to use, and to support accounting
> for the use of these resources.
*Exactly* my reasoning behind suggesting a "safe shell". Constraining
ourselves to any one language is antisocial, nonprogressive, and
anti-WWW-philosophy (as I see it). I'd like to put up Perl scripts, C
code, and even binary code for different platforms - even if there were
a safe Perl I wouldn't write everything in that.
> A truly anonymous program might begin executing with with finite
> resources: a certain amount of memory and some CPU time. To gain
> access to the filesystem, network ports, databases, more compute time,
> or more memory, I see three options:
>
> (1) In an interactive session, (like a program that runs inside Mosaic
> to control a smart form) the virtual machine could present a dialog to
> the interactive user:
>
> The 'fractal image display' task has consumed the default
> maximum memory resources, and requested 5MB more.
> <Grant Request> <Abort Task>
The 'smart form' task wishes to open a socket connection to port 25
(sendmail) on whitehouse.gov.
<Grant Request> <Abort Task>
The 'geometric viewer' application wants to read the file "/etc/passwd".
<Grant Request> <Abort Task>
It seems that at least in terms of protecting operating systems, which can be
defined by a limited number of subsystems each of which can be explicitely
monitored, this system would work. The client could even specify certain
allowed things, like "can always write to /tmp".
The thesis that "specifically allowing certain actions is safer than
specifically prohibiting others" can be integrated into this, one would
think.
The main argument I heard to this was that shells would be hard to implement
on some systems, such as the Macintosh. I don't know what to answer to that,
other than I'd have to gain a deeper knowlege of the Macintosh architecture
before being convinced. Second opinions anyone?
Brian
