Security in Agent Systems1.3 Programs from Strangers"Please run me. I'll be good. Really!" You probably wouldn't run a program sent to you by a stranger on the Net. But would you hesitate to open a document sent by a stranger as e-mail? Depending on what you use to read that document, you may be running a program simply by opening it; your document-reading program may be obeying hidden orders embedded by the document author. Hundreds, and probably thousands, of users of Microsoft Word have recently discovered this first-hand. The Concept virus [4] is a piece of code written in WordBasic, the macro language used by the word processor Microsoft Word. If I open (i.e. use Word to read) a document infected with this virus, part of the virus immediately runs, and copies the virus into my installed copy of Word, in such a way that future documents that I save may become infected with the virus. Concept itself has no intentionally destructive "payload", but it does sometimes cause problems because of some of the side-effects it has when it embeds itself in documents. The virus spreads well enough that it has infected at least hundreds of different computers, and it seems to have become sufficiently widespread that it is unlikely to become extinct in the near future. So whether we like it or not, agent systems are here, are in wide use, and are already troubled by viruses. We may be using them unintentionally now; as we begin to use them on purpose, we have a chance to decide how they should be controlled. In a typical corporate environment today (February, 1996), users are forbidden by policy from using any software that did not come into the company through the usual channels (the Purchasing Department or equivalent). Many individual users, especially virus-conscious ones, follow similar policies, and use only software from shrink-wrapped boxes and the most reliable shareware and BBS sources. In some ambitious visions of the future, agents are programs that flit from machine to machine, accessing services, performing searches, carrying messages, and generally constituting the entire computing infrastructure. This vision is not entirely compatible with the ability to control which programs my system executes. If all mail is in the form of nimble message-carrying programs, I have to be willing to execute programs sent by anyone I want to accept mail from. If the standard way of interacting with information providers is via small downloaded programs, I have to be willing to execute programs sent by anyone whose data I want to browse. This programs-from-anywhere model of computing is not required by the agent systems that enable it. All of them provide, or plan to provide, optional facilities to restrict the set of users that programs will be accepted from, and in some cases to restrict execution to programs that are digitally certified as benign by some trusted agency. Users or system administrators are free to use these facilities. On the other hand, if the general consensus is that these facilities are not needed, it is likely that popular and widely-used resources will appear that require them to be shut off. And in that case, users will shut them off: security features that get in the way of getting work done always get shut off. The designers of agent systems, of course, have thought of these things. As well as restricting the sources from which one will accept programs, well-designed agent systems also provide facilities to control what an incoming program is allowed to do once it has arrived. This is generally done either by having the programs run in a virtual or interpreted environment, or (on multi-user systems) having the programs run with only certain privileges, or both. Safe-tcl [5], Java [6] and Telescript [7] programs are all interpreted, to give the system detailed control over the actions that received programs can take (more detailed than that provided by the access controls, if any, in the native operating system). Exactly how to use this control is not always clear. Java applets, for instance, can be forbidden to access any part of the filesystem except those parts set aside for use by applets. In the present environment, this is good protection. But if Java applets begin to form an important part of the computing infrastructure, the applet-usable part of the filesystem will become more important, and need to be protected itself. In some cases, the privileges that an incoming program has should depend on where the program came from, as well as some function of where it has been. There are complexities involved in authentication and authorization when a program has been through multiple hops since leaving its source; these technologies are still evolving rapidly. Controlled execution of received agents is naturally not as secure as not running them at all. But if the security of the systems, both real and perceived, is sufficient, and if they let us do useful new things, we will eventually accept them, and profit by them.[ Top of Page | Previous Page | Next Page | Table of Contents ] |