Re: Mobile Code Security???

["Frank O'Dwyer" <fod () brd ie>]

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