At 10:48 29/04/98 -0400, Marcus J. Ranum wrote:
>So, back to 30,000 feet: I like the Java sandbox model. I kind
>of wish I could run general Windows applications in a sandbox.
A shortcoming I see with the sandbox approach is that it
it only treats the code. Assigning privileges to code
doesn't work if the same code has to handle trusted
and untrusted data. For example, I have some Java code
that sucks in XML files that represent local documents on
my PC. I trust this code somewhat since (a) I wrote it
myself, and (b) I even went to a little bother to try
and improve its security. However, since one thing this
code does is to actually _open_ these documents on request,
it's only OK if you trust the XML files (the data)
too. Download the XML from the net, and all bets are off.
Now, this code is written to Java1.2. I could apply
a sophisticated sandbox to it if I chose - but it
wouldn't help much, because the data is the source of
the problem, not the code. Running separate instances
of the code in different sandboxes would be a start,
but it isn't a long term solution--and it doesn't work
for very dynamic systems where both code and data
are "mobile" (i.e. where object _instances_ effectively
roam the network - and this is really the situation
with Java, ActiveX, CORBA, XML, et al.). You also get
untrusted instances calling more trusted instances,
and vice versa, and code sandboxes don't address that
at all.
Another way of putting this is that most data turns out
to be code in disguise. This is obvious when the data
is a script, say, or a configuration file. It's less
obvious when the data is some serialized Java object
or an XML stream, but these too are effectively executed
by the corresponding programs. In fact it's hard to think
of any non-trivial program which doesn't in some sense
execute the data it works with, and which wouldn't morph
into a completely different animal if fed some bogus
information.
I think the answer is still a sandbox of some sort.
But fundamentally we need to sandbox object *instances*
and not object implementations--this means that privileges
must be assignable to code+data, and not code alone. I want
to trust the widget I get from the net differently than
the widget I made myself. I'm not content to know that the
widget _code_ is the same and trusted in each case. I need
to factor in the data that was used to make the widget,
as well as the data it will use and affect over its lifetime.
Long-term I think what is needed is a hybrid of what Java1.2
does for code (which is very nice, by the way) and something
like Perl's data-tainting mechanism, but with the granularity,
simplicity, and automatic containment of JDK1.2's code
stuff.
>To get our work done, we have to run code from other people.
... and we have to work with data from other people...
>Therefore we are vulnerable. The question is "which other
>people?" The Web, and active content, makes it really easy
>to blur the line. At this point, I think of the problem
>as akin to shark attack. There is a nonzero probability it
>will happen. It's a low probability, on an individual
>basis. If it does happen, it'll Suck Real Bad. But I'll
>either recover or die. :) Which brings me to the best defense
>I can think of: be prepared to resume your business.
>I'm wondering if fast recovery will ever replace security
>or direct defense as an approach to business resumption.
This is the way I approach the web, to be honest. While I
run all sorts that I download, I also make a point of
completely reinstalling my PC OS, applications and data
every now and then, just to give myself some assurance
that I know how to recover things should the worst come
to pass. Basically you try to be ready for the day you
open up the case to find that both the hard disk
and the NVRAM are missing. (Besides, it's amazing
how you don't miss all of the cruft you forgot to back
up. I recommend it - it's very therapeutic:-)
(Of course, the backups may be polluted and virus-ridden
too, which is where I came in...)
[...]
Cheers,
Frank O'Dwyer
Received on May 05 1998
Intro
