On Wed, 1 Oct 2003, Peter Gutmann wrote:
>This doens't really work. Consider the simple case where you run Outlook with >'nobody' privs rather than the current user privs. You need to be able to >send and receive mail, so a worm that mails itself to others won't be slowed >down much. In addition everyone's sending you HTML-formatted mail, so you >need access to (in effect) MSIE via the various HTML controls. Further, you >need Word and Excel and Powerpoint for all the attachments that people send >you. They need access to various subsystems like ODBC and who knows what else >as an extension of the above. As you follow these dependencies further and >further out, you eventually end up running what's more or less an MLS system >where you do normal work at one privilege level, read mail at another, and >browse the web at a third. This was tried in the 1970s and 1980s and it >didn't work very well even if you were prepared to accept a (sizeable) loss of >functionality in exchange for having an MLS OS, and would be totally >unacceptable for someone today who expects to be able to click on anything in >sight and have it automatically processed by whatever app is assigned to it. I think part of the point is that that expectation is a substantial problem. Data that moves between machines is inherently suspect; and if it can originate at unknown machines (as in SMTP or NNTP), it should be regarded as guilty until proven innocent. There ought to be no way to send live code through the mail. Users simply cannot be expected to have the ability to make an informed decision (as opposed to a habit) about whether to run it, because its format does not give them enough information to make an informed decision. The distinction between live code and text is crucial. While both are just sequences of bytes, text has no semantics as far as the machine is concerned. Once you start sending something that has machine semantics - something that contains instructions for the machine to run and running those instructions may cause the machine to do something besides just displaying it - then you are dealing with live code. And live code is handy, but dangerous. There is pressure to stick live code into any protocol that moves text; SMTP sprouted 'clickable' attachments. Java, javascript, and now flash seem to have gotten stuck into HTTP. But I think that live code really and truly needs a different set of protocols; and for security's sake, there really need to be text-only protocols. It should be part of their charter and part of their purpose that they do *NOT* under any circumstances deliver live code. "Can be relied on to _only_ deliver text" is a valuable and important piece of functionality, and a capability that has been cut out of too many protocols with no replacement in sight. Separating it by protocol would give people practical things that they could do. You could, for example, allow people to use a live-code mail protocol inside a company firewall or allow a live-code browsing protocol inside the firewall, while allowing only a text mail protocol or a text browsing protocol to make connections from outside the company. We approximate this by trying to make smarter clients that have different trust models for different domains, but that's always a crapshoot; you then have to depend on a client, and if the client can be misconfigured and/or executes live code it can't really be relied on. It would be better to have separate protocols; Ideally, even separate applications. >One thing that I noticed in the responses to "CyberInsecurity: The Cost of >Monopoly" was that of the people who criticised it as recommending the wrong >solution, no two could agree on any alternative remedy. This indicates just >how hard a problem this really is... Indeed. I think that there ought to be simpler, text-only protocols for the use of people who don't need to send and recieve live code, so that they could be effectively protected from live code at the outset unless they really need it. Others, of course, disagree. Bear --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]