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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 12:58:25 PDT