Re: How about a Safe Virtual Machine?

Steven D. Majewski (sdm7g@virginia.edu)
Tue, 4 Oct 1994 02:06:59 -0400 (EDT)

One problem I see with the safe virtual machine approach can be
seen if you look at an existing example:
Some of the Macintosh virus protection programs do something
quite similar: they sit there and intercept system calls and
warn you that a program is trying to modify a file in the system
folder. You can then refuse, allow or "learn" ( an allow that will
be marked to allow again in the future. )
The problem is that, since the Mac was not designed with security
in mind, it's usually not obvious to a typical user whether these
are legitimate accesses or not. About half of the users I see,
panic when they see these messages and the other half just allow
*everything* or turn off the facility.

The security mechanisms have to be sufficiently higher order
to be useful.

My reservations concerning safe-tcl are that:
(1) It provides some of these higher-order safety features.
(2) It's missing others that may be required. -- Well - that's
not a problem. It's a programming language, so you can implement
the unexpected requirements that Nathaniel is worried you won't
capture in a more declarative non-procedural language.
(3) That extensional capability is the loophole: how can you
ensure that the higher-order access functions are used, and not
some lower level disguised approach. ( Not disguised to the
safe-tcl mechanism, but disguised to the user - i.e. will they
understand the warning. )
(4) safe-tcl can be incrementally extended to provide new higher-
level facilities, while restricting low level access, but this
leads to a versioning problem.

These problems may not be fatal. But think the security requirements
for enabled-mail, server-agents, and client-executed browser code
are all rather different, so a fatal flaw in one realm may be only
a minor annoyance in another. In some cases you can get away with
the conservative approach of rejecting anything that even looks
suspicious. In others, you will punt the decision to the user
with an Allow/Deny query.

In some of the distributed programming safety features I want
to get into Python, for example, I have a looser requirement.
That the program not do things it "claims" not to do: If it
imports no I/O capable module, then it doesn't do any I/O. If
it requires to communicate over a socket to another program,
then I can hand it an already opened socket, or an object
that represents a potential socket or inactive "future".

I'm trying for something that is halfway between the safe-tcl
model, and the more capability based model of Obliq. It's not
just a question of language syntax (I think), but of a very
different security model. I don't think Obliq could be made to
provide safe-tcl like enabled mail, but I think it may be a
better model for the types of client server interaction we're
considering on the Web.

-- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU> --
-- UVA Department of Molecular Physiology and Biological Physics --
-- Box 449 Health Science Center Charlottesville,VA 22908 --
[ "Cheese is more macho?" ]