Protected Resource Access for Mobile Agent ... - Semantic Scholar

Protected Resource Access for Mobile Agent-based Distributed Computing Anand Tripathi and Neeran Karnik Department of Computer Science, University of Minnesota Minneapolis, MN 55455 [email protected]

Abstract This paper describes the mobile agent paradigm for distributed computing, and outlines the security-related issues encountered in supporting it. One of the major requirements is the provision of access control mechanisms for server resources. Several possible designs are discussed, and one such proxy-based design, which we have developed in conjunction with the Ajanta mobile agent system, is described in detail. Extensions of this mechanism which allow accounting of usage and selective revocation of access privileges are discussed. The Java security model is also described, since the security of the proxy mechanism depends on it.

1. Introduction In recent years, the exponential growth of the Internet and the increasing availability of various types of information via the Worldwide Web, has led to a demand for network-centric applications which need to access heterogeneous resources via the network. New techniques, languages and paradigms have evolved to address these needs. Perhaps the most promising among these is the use of mobile agents. In a broad sense, a mobile agent is a program which represents a user in a computer network and is capable of migrating autonomously from node to node, to perform computations on behalf of the user. The tasks performed by a mobile agent are determined by the application, and can range from on-line shopping to realtime device control to distributed scientific computation. Applications can launch mobile agents into a network to visit different sites, either on a predetermined path or one that the agents themselves determine based on dynamically gathered information. The agents may then return to their “home site” and report their results to the user. Traditionally, distributed applications have relied on the client–server paradigm in which client and server

processes communicate either through message-passing or remote procedure calls (RPC). The RPC model is usually synchronous, i.e., the client suspends itself after sending a request to the server, waiting for the results of the call. In an alternative architecture called Remote Evaluation (REV), proposed by Stamos and Gifford[25], the client sends its own procedure code to a remote server and requests the server to execute it and return the results. Thus in RPC, data is transmitted between the client and server in both directions whereas in REV, code is sent from the client to the server, and data is returned to the client. The mobile agent paradigm is an extension of this concept, in that both code and data are transmitted from node to node on a network. A more generic concept is that of a mobile object, i.e., an object which can be transported from one network node to another. An early example of a system that provided such object mobility within a homogeneous local area network was Emerald[13]. Earlier, systems like R2D2[29] and Chorus[2] introduced the concept of active messages that could migrate from node to node, carrying with them program code to be executed at these nodes. The mobile agent paradigm has evolved from these antecedents. Agents can be implemented as active objects, which encapsulate code and execution context along with their data, and are transportable on a network. Harrison et al[8] have evaluated the agent paradigm in detail and identified two clear advantages of mobile agent-based computing. First, by moving processing functions close to where the information is stored, it reduces communication between the client and the server. Secondly, the mobile agent paradigm increases the degree of asynchrony between the client and the server – a client may become inactive for an arbitrary time after initiating an agent-based computation. Also, mobile agents introduce a higher level of abstraction in comparison with RPC and message passing. For many applications, this may be a more natural programming style. Applications can be composed using agents as active components, traversing the network and performing computations relevant to their locations.

However, the mobile agent paradigm also adds significant problems, primarily in the area of security. The use of mobile agents requires each cooperating host in the distributed system to provide a facility for executing them. Unless some countermeasures are taken, these hosts are exposed to the risk of system penetration by malicious agents. Such agents can potentially leak or destroy sensitive data and disrupt the normal functioning of the host. Malicious (or just buggy) agents can cause inordinate consumption of a host’s resources, thereby denying their use to other legitimate users. Security mechanisms are thus necessary to safeguard hosts’ resources. Similarly, agents themselves may need to be protected from the hosts they visit. An agent is likely to carry, as part of its state, sensitive information about the user it represents – e.g. credit card numbers, or personal preferences to customize an intelligent search. Such data must not be revealed to unauthorized hosts or agents, nor must they be allowed to modify it arbitrarily. Security and robustness concerns about mobile agents are usually identified as the biggest hurdle preventing the widespread deployment and use of agent-based applications. We are developing Ajanta, a Java-based mobile agent system that addresses these concerns among its basic design goals. The primary focus of this paper is on one particular aspect of this system – protecting a host’s resources from visiting agents and granting controlled access to the resources, to such agents. We use the term resources here to mean application-level services, or information available at the host. The remainder of this paper is organized as follows. The next section presents the general security problems encountered in mobile agent systems. Section 3 describes related work in the context of security in other mobile agent systems and applet execution in web browsers. We also briefly review Java’s security model, as it forms the foundation of our design. Section 4 briefly introduces the agent programming environment. Section 5 describes the agent server design and presents the main contribution of this paper, i.e. a proxy-based scheme for granting the visiting agents protected access to host resources. The final section presents some conclusions.

2. Problem Statement Basic notions: An agent is viewed as an active, mobile object which is launched into the network by a client process working on behalf of some authorized user. Typically, the purpose of an agent is to visit some specified services to perform certain tasks. In order to participate in the mobile

agent system, a service provider runs one or more agent server processes on some of its computers on the network. These processes are responsible for hosting and executing any agents that arrive over the network. Agent servers communicate with each other using a server-to-server protocol. The primary function of this protocol is to securely transfer an agent from one server to another. A principal is an entity which has a unique identity in the system. Actions are always performed on behalf of some authorized principal. Agents, naturally enough, are the primary example of principals, but there are several other types, such as service providers, hosts and agent servers. We associate an owner with each agent – this is the human user whom the agent represents. The author of an agent’s code is often important from a security perspective, and therefore may have to be represented as a principal. The agent itself may be created by another entity – such as an application program, or another agent. Thus the creator of an agent is distinct from its owner. Also, a set of principals may be aggregated together in a group to represent a common role. Membership in such a group would represent some common authorization and privileges. Security issues: The introduction of mobile code in a network raises several security issues. In a closed network – contained entirely within one organization – it may be possible to trust all machines and the software installed on them. Users may be willing to allow arbitrary agent programs to execute on their machines, and their agents to execute on arbitrary machines. However in an open environment, it is entirely possible that an agent and a server belong to different administrative domains. In such cases, they will have much lower levels of mutual trust, thus making preemptive security measures necessary. As a mobile agent traverses the network, its code and data are vulnerable to various types of security threats. Agents can be subjected to both active and passive types of attacks on communication links. A passive attacker can attempt to eavesdrop on network communication to obtain any sensitive information carried by an agent. To counter this, a confidentiality (i.e. privacy) mechanism is therefore necessary. In the case of open networks like the internet, we must assume a very general threat model in which the adversary can arbitrarily intercept and modify network-level messages, or even delete them altogether and insert forged ones. These are termed as active attacks. Another type of attack in this category involves impersonation. The adversary impersonates one of the legitimate principals in the system and can attempt to intercept messages intended for that principal. The damage caused by active attacks can be minimized if the communication link provides assurances of data in-

tegrity (i.e. the data is either delivered unmodified, or an exception is raised signaling that the data has been tampered with) and authentication (i.e. the source and destination of the message are unambiguously identified). Passive attacks are difficult to detect, but can be protected against cryptographically. In contrast, active attacks are relatively easy to detect cryptographically, but given our general threat model, they are difficult to prevent altogether. The security-related requirements encountered in mobile agent systems are summarized below:

 Privacy and integrity of communication – mechanisms must be provided to protect sensitive data from disclosure and malicious modification, especially during transit on the network.  Mutual authentication of the agent and server – both the agent and the server hosting it must have foolproof evidence of each others’ identities.  Authorization and access control mechanisms – the host must be able to specify and enforce restrictions on a visiting agent’s access to the local resources, based on the authenticated identity of the agent.  Agent security – the code and state of an agent must be protected against modification by malicious hosts or other agents.  Secure electronic commerce – mechanisms must be provided for metering of resource use and charging for such usage. This paper focuses primarily on the design of an access control scheme, which is used by agent servers in Ajanta to protect their resources.

3. Related Work and Background

3.1. Mobile Agent Systems and Security Several research groups are currently investigating and building mobile agent systems. These systems can be classified into two broad categories based on the characteristics of the base language used to implement the agent paradigm. A number of projects use object-oriented languages. Agents are defined as first-class objects, and the system provides support for their migration in the network. Such systems offer the natural advantages of object-orientation, such as encapsulation, code reuse via inheritance, etc., in building agent-based applications. In recent months, this approach appears to be gaining acceptance, thanks to the widespread popularity of the Java programming language. The second class of agent-based systems uses script languages like Tcl, Python or Perl, for

defining mobile agents. The advantage of such systems is their simplicity and the existence of mature interpreter environments which permit efficient access to local resources. In the category of object-oriented systems, the most noteworthy effort is the Telescript[28] language by General Magic. This object-oriented type-safe language was expressly designed to support agent-based computing, and it was among the pioneers in this field. It has several interesting features especially in the security context. Different types of permits are used for access control and for imposing quotas on resource use. Security mix-in classes can be used to protect objects from unauthorized modification, copying or migration. However, Telescript has now been shelved, with General Magic having embarked on a Java-based mobile agent system called Odyssey[5]. Odyssey has comparatively limited functionality, but can be viewed as a derivative of the Telescript design framework. Recently, Java has emerged as a widely used basis for building mobile agent systems because of its support for object-orientation, its security model for mobile code, and a rich set of libraries which support object serialization, remote method invocation (RMI), and reflection[11]. A comparative evaluation of three Java-based mobile agent systems is presented in [15]. The Aglets Workbench[10] developed by IBM is an example of a Java-based mobile agent system. It uses an event-based programming model; handlers are defined for different types of events such as migration, dispatch, arrival at a server, etc. For migration, an agent’s state is captured at the application level – therefore it does not involve any modifications to the Java virtual machine and makes it easily portable. Currently, this system has only primitive security functionality. However a security architecture for this system has been recently proposed[14]. Voyager[20], Sumatra[22], and Mole[27] are some other Java-based agent programming systems. These systems do not address security issues directly among their basic design objectives. Tacoma[12] and Agent Tcl[7] were among the first of the Tcl-based systems. The Tacoma design does not address security issues. Agent Tcl[7] supports access control lists based on host names and uses PGP for encryption and authentication. The Knowbots project[9] uses Python, an object-oriented script language, for programming agents, although its architecture is language-independent. It does not currently support secure agent transfer, or protection of agents from their hosts. Ara[21] is another mobile agent system which supports multiple agent languages like Tcl and C++. Agents move between “places”, which represent servers. Places use access control lists (called

“allowances”) to impose security restrictions on visiting agents. Most of the systems mentioned above cannot provide strong security guarantees, and in many cases security features are either absent or added on at a late stage, resulting in ad-hoc or incomplete integration with their architectures.

3.2. The Java Security Model Java is currently widely used for programming applets, which are mini-applications downloaded from web servers to client machines for execution. Its security model therefore was designed specifically for applets. Applets are similar to agents; however, they are not autonomous or mobile, and therefore far less general than agents. The security problems raised by downloaded applets[18] are also applicable to mobile agents; however, there are other problems that only arise in the context of mobile agents. These are elaborated on in Section 5.1. The Java environment has a security-aware design[18]. Its security model has three main components: 1. A byte-code verifier ensures that programs do not violate type-safety, encapsulation properties, etc. or cause run-time errors that can result in security vulnerabilities (e.g. stack overflows). 2. Class loader objects are used to dynamically load classes into the Java runtime. Within the Java virtual machine, a class is fully identified by the combination of its name and the class loader instance that installed it. When a dynamically loaded class refers to another class which is not currently installed, the virtual machine calls upon its class loader instance to load the new class as well. Thus, all the classes used in a particular application share the same class loader, and can be said to constitute a name-space. This prevents accidental or deliberate name-clashes across applications that can cause security breaches. This feature is used in the applet context by simply creating a new class loader instance for each downloaded applet. The applet is thus isolated in its own name-space, and is unable to interfere with the classes in other applets’ name-spaces. 3. A security manager can encode a security policy and perform some basic access control functions. All the security-sensitive classes in the Java library call the security manager to decide whether to allow potentially dangerous operations. An application can implement its own security policy by installing a

customized security manager. Once this is done, the security manager cannot be replaced or overridden for the duration of the application’s execution. Applets are not permitted to install their own security managers.

In the Java security model, all classes loaded from the local file system directories listed on the classpath of an application are considered to be local, and are allowed unrestricted access to system resources. Therefore, only trusted classes should be put on the classpath, and these classes must be designed carefully – all accesses to sensitive resources should be screened by the security manager. Thus the security manager acts as a reference monitor[1]. Class loaders and the security manager are the two basic mechanisms which we use for creating protection domains for mobile agents at a host, and to provide agents with protected access to host resources. In Section 5 we outline our approach based on these two mechanisms.

4. Agent Programming Environment AGENT Current

Itinerary

AGENT SERVER Resource

Proxy1

Proxy2

Code

State

(Methods)

(Internal Data)

M1

M2

M3

AccessProtocol

host

Credentials

Agent Environment Resource

Domain

Registry

Database

Agent Transfer

HOST OPERATING SYSTEM

Figure 1. Ajanta Server Structure

To participate in the mobile agent system described here, a host node has to run one or more agent server processes (see Fig. 1), which facilitate the execution of visiting agents. An agent server runs as an ordinary user-level process on its host machine, and is subject to the host operating system’s usual security mechanisms. It accepts and executes agent objects, submitted to it either by a user-level application or by another agent server via

the network. Each agent server has an agent environment component, which acts as the interface between visiting agents and the server. The server’s domain database keeps track of agents currently executing on it, and responds to status queries from their owners. The agent transfer component implements a protocol that allows agents to migrate from server to server. A server may also provide application-specific resources. A resource is an object that acts as an interface to some service or information available at the host. The server maintains a resource registry which is used in setting up safe bindings between resources and agents. All agents, agent servers, and resources are assigned global, location-independent names. An application developer defines new agent and agent server classes by extending the system-defined Agent and AgentServer classes, respectively. An agent is created as an instance of such a class, and initialized with application-defined state using its constructor. An agent object is conceptually a collection of components. The basic component is its code – the classes which implement its functionality. Its state includes its credentials (described in Sec. 5.2) and a reference to the agent environment (called host in the figure). When an agent arrives at a server, its host reference is appropriately initialized before it starts executing. The agent environment provides services to agents in the form of primitive operations. At the most basic level, mobility is supported by the go function, which transports the calling object to a destination specified as a parameter. Higher-level abstractions such as co-location with named objects, or specification of itineraries are implemented on top of the go primitive. Other primitives provided by the agent server include facilities for installing and accessing resources, communicating with other agents, monitoring the status of child agents, issuing control commands to them, etc.

5. Agent Server Security This section focuses on the problem of protecting an agent server’s resources. By allowing the execution of agents originating from unknown and untrusted sources, the host node’s resources are exposed to the risk of various types of attacks. These can include pilfering of sensitive information, damage to host resources, denial of service to other clients or agents, and annoyance attacks. Therefore, various resources of the host system need to be protected from malicious agents. At the same time, legitimate agents must be given access to the resources they need. In this context, the primary system-level problems that need to be addressed are: binding of agents to the local environment, creation of protection domains for them, authorization, and

enforcement of access control.

5.1. Requirements The security requirements in a mobile agent system differ in several ways from those available for Java applet security:

 The granularity of access control is very coarse in the applet model. Applets signed by a trusted entity are allowed arbitrary access to system resources. All other applets are considered untrusted and are denied access to all resources such as the file system, network ports (with the exception of network connections back to their site of origin), etc. We need greater flexibility of access control with mobile agents, and therefore a finer granularity is necessary.  Mobile agents can provide or access application-level value-added resources, such as database services. Access control needs to be provided for such resources too, in addition to the system-level ones. The security policies of such resources can be dynamically modified by their owners.  Agent owners may impose restrictions on the rights that are delegated to the agent. These restrictions must be enforced in addition to the access controls applied by the resources themselves.  Applets do not usually communicate with each other, whereas agents are often required to do so. Moreover, communication among co-located agents needs to be established securely, eliminating the possibility of one agent tampering with another agent’s code or data.

5.2. Credentials and Authorization An agent acts as a delegate of its creator application, and executes on behalf of its owner. Each agent carries a set of credentials, which associate the agent’s identity with those of its owner and creator, in a tamperproof manner. Apart from an identity (name), the credentials include the owner’s public key certificate. The creator may delegate to the agent only a limited set of privileges while working on its behalf. Such access restrictions are also encoded in the credentials. When a server receives an agent, it uses these credentials to validate the authenticity of the agent, and based on the agent’s identity and delegated rights, it can grant access privileges for its local resources. For security purposes, the credentials could have an expiration time[26, 24] so that stolen credentials cannot be misused indefinitely. In general, the approach adopted in our design follows the server-oriented view of

enforcement of security policies, advocated in [4]. This viewpoint is preferred over a ubiquitous or central authority for security policy enforcement, which may not be feasible in an open, federated environment of servers and clients. There are two basic problems that we have to address. The first is to design protocols for constructing credentials for an agent to act as its owner’s verifiable and tamperproof proxy. We do not discuss this problem in this paper, but for the purpose of this presentation, treat any credential-related functions and protocols at an abstract level. A server may also need to forward an agent to another server (like a subcontract) granting it some additional privileges or restricting some of its existing ones. In the past, several protocols have been proposed based on secret or public-key cryptosystems for delegating rights to proxies[24, 4, 19]. Integration of any such protocols in our designs is constrained by the fact that an on-line authentication service may not always be available. The second problem is to provide mechanisms to agent servers for specifying restricted access rights for agents – this is usually termed as authorization. The rights assigned usually depend on the agent’s identity (implying that a secure authentication facility is necessary), and are determined by consulting a security policy. In addition, we need mechanisms for enforcing the specified rights – this is the problem of access control. An underlying system-level problem is that of providing a safe binding between the visiting agent code and the server resources, so that the agent can access the resources it needs (only in ways it is authorized to), but cannot breach system security by accessing resources it is not authorized to use.

5.3. Protection Domains The approach presented here rests on two of the three mechanisms provided by the Java’s security model — name-space separation based on class loaders, and the security manager – together with Java’s class-hierarchy based type model and support for type checking. Domain creation: A separate agent protection domain must be created for each agent. This is done by creating a new class loader instance to load the incoming agent into its own name-space. Any classes that the agent subsequently refers to are loaded by the same class loader, which ensures that any privileged classes (such as those having direct access to system-level resources) are loaded from the local classpath and not from a remote site. This prevents agents from installing “impostor” classes of the same name, which can bypass the security checks in their code. The namespace mechanism also serves to isolate agents from one

another, and thus protects agents from tampering by other agents. Domain identification: The security manager for the agent server needs to distinguish the protection domain of the agent from that of the server. This is accomplished by creating a new thread group to execute each agent. All threads created by the agent belong to the same thread group, which thus identifies the agent’s protection domain. Similarly, all server threads execute under the same thread group, which identifies the server protection domain. Thread group manipulation operations must therefore be treated as privileged operations; such operations are appropriately mediated by the security manager. For example, a thread executing in an agent’s domain is not allowed to create a new thread in a different thread group whereas a server thread is allowed to do so. The domain database: The agent server maintains a domain database. For each agent, it stores several items of information including its thread-group, owner, creator, and home-site address. It also includes access authorization for various server resources, usage limits and current usage. If the agent is currently granted access to any server resources, then information about the binding objects, detailed in Section 5.5, is also maintained here. This database can be updated only by a thread executing in the server’s protection domain.

5.4. Protected Binding to Server Resources The agent server provides language-level binding between the agent’s domain and the server’s resources. There are several ways to execute an agent in a controlled environment. One approach would be to check all resource accesses using the security manager. This would require each resource developer to extend or modify the security manager. This has a few disadvantages. Because all security policies would have to be enforced through it, the security manager may tend to become an excessively large module and that could raise the potential for introducing errors during extensions. Therefore, our approach is to limit the use of the security manager to providing generic protection of system resources and not have it directly deal with the protection of application-level objects. Another approach for establishing controlled access is to use proxy[23] objects. When an agent first makes a request to access a resource, the server consults the security policy and constructs a resource proxy, which is an object with a safe interface to the resource. If the agent is not trusted, certain operations on the resource may be disabled. A separate proxy is created for each agent. The agent only

has a reference to the proxy, and its restricted interface ensures that the agent can only access the resource in a safe manner. In a third approach, each resource is protected by encapsulating it in a wrapper object. The agent only has references to these wrappers and cannot bypass them to access resources directly. The wrapper accepts requests for the resource and determines whether or not to allow the access based on the client’s identity. For this it needs to maintain an access control list. From a server’s viewpoint, a possible difficulty with this approach is that in an open environment the identities of all potential clients may not be known beforehand. However, putting a wrapper around an agent can be reasonable for protecting the agent itself, since the set of principals required to invoke an agent’s methods is likely to be small and may even be known at the time of agent’s creation. Another approach, exemplified by Safe Tcl[16], is to use two execution environments – a safe one which hosts the agent, and a more powerful trusted one which provides access to resources. Whenever the agent calls a potentially dangerous operation, the safe environment acts as a monitor and screens the request based on its security policy. If it is allowed to proceed, it calls the trusted environment which provides the actual access to the resource. This is conceptually similar to wrappers, but instead of protecting each resource with a separate wrapper, it seeks to place a wrapper around the agent itself. The wrapper approach is attractive because it is relatively simple to implement and transparent to the agent programmer. Only one wrapper exists for each resource object. In contrast, when proxies are used, a proxy instance must be created for each agent that accesses the resource. The wrapper approach is however inflexible in that all clients must be subjected to the same access control mechanism, which is invoked on every access to the resource. Proxy objects on the other hand can be tailored to specific agents and dynamically generated as required. Once a safe proxy is made available to an agent, access control checks would require a minimal amount of computation. The Safe Tcl approach to protection domains works well provided that all dangerous operations are identified and protected in the safe environment. But it can incur substantial overhead because it may require a transition across system-level protection domains on every resource access.

5.5. Design of a Proxy-Based Approach We now present a proxy-based approach for creating protected bindings for application-defined resources. We

illustrate the procedure using an example in which we develop a bounded buffer resource using the generic resource skeleton (Figure 2) provided by the system. We first discuss the generic Resource interface and show how it is used to develop a Buffer interface, its implementation, and its proxy class. Next, we will discuss the resource request protocol that agents can use to access the Buffer. Resource

AccessProtocol

ResourceImpl

BufferImpl

KEY:

class interface

Buffer

BufferProxy

implementation inheritance interface inheritance

Figure 2. Resource Classes and Interfaces

public interface Resource { // generic methods, common to all resources // e.g. queries for name/id, ownership, etc. } public class ResourceImpl implements Resource { // implementations of the above methods }

Figure 3. A generic resource

Resource and Proxy Classes: The system defines a Resource interface, and provides a ResourceImpl class which implements it (outlined in Figure 3). The methods of this class provide generic functionality for all resources, such as resource naming, ownership, charging protocols, etc. The resource access protocol, which binds agents to local resources, is defined in terms generic Resource objects so as to keep it independent of application-defined types. All application-defined resource classes must implement the Resource interface; this is typically done by simply inheriting from the ResourceImpl class. For example, an application can provide a Buffer resource

interface implemented by a BufferImpl class as shown in Figure 4. public interface Buffer extends Resource { // An application-defined bounded buffer public synchronized BufItem get(); public synchronized void put (BufItem);

the AccessProtocol interface (shown in Fig. 7), i.e. a getProxy method. This method is responsible for creating the proxy and selectively disabling some of its methods, based on the calling agent’s credentials. For a given resource class, the corresponding proxy class can be automatically generated by a simple lexical processing tool. For example, the proxy for the Buffer class is shown in Figure 5.

// etc.

AGENT SERVER

} Resource

public class BufferImpl extends ResourceImpl implements Buffer, AccessProtocol { // implementation of the Buffer and // AccessProtocol methods }

6 Proxy2

AGENT 1

AGENT 2

Proxy1

5

AccessProtocol

Figure 4. A bounded buffer resource 1

4

2 Agent Environment

public class BufferProxy implements Buffer { private Buffer ref; // ref is a reference to the underlying // resource, which is initialized by the // constructor (below) BufferProxy(Buffer b) { ref = b; } public synchronized BufItem get() { if (isEnabled("get")) return ref.get(); else // throw a security exception } // etc. private boolean isEnabled(String method) { // if the named method is disabled, // it throws a security exception. }

Resource Registry

3

Domain Database

1: resource registers itself 2: agent requests a resource 3: server looks up resource in registry

Agent Transfer

4: getProxy method is invoked 5: proxy object is returned to agent 6: agent accesses resource via proxy

Figure 6. Dynamic Resource Binding

public // // //

interface AccessProtocol { Defines the generic resource access interface. The getProxy method returns a proxy object (typecasted to Resource).

public Resource getProxy(); }

}

Figure 7. The Access Protocol interface Figure 5. Proxy class for the bounded buffer

Agents are not provided with direct references to resources. Instead, when an agent requests a resource, an instance of a proxy class is returned. For each applicationdefined resource class, a corresponding proxy class must be defined. A proxy contains a reference to the actual resource, which should not be visible outside the proxy. The Java encapsulation mechanism is used to enforce this requirement. The proxy class implements the same interface as the resource it represents. However, each interface method simply passes the invocation through to the resource object after ensuring that it is enabled. Authorization is done by the resource class, which must implement

Resource Request Protocol: Figure 6 depicts the components of an agent server’s resource binding protocol. This figure shows two protection domains for two agents. A resource is made available to agents by invoking the agent’s environment’s registerResource primitive, which stores the resource name and a reference to the resource object in the resource registry (step 1 in the figure). Each entry also contains ownership information, which is used to prevent any unauthorized modifications to the registry entries. An agent can make itself available to other agents in similar fashion, by registering itself as a resource.

In order to obtain access to a resource, an agent must invoke the getResource primitive (step 2) and provide the global name of the desired resource. In response, the agent environment searches the resource registry to locate the corresponding resource object (step 3), and makes an “upcall” to its getProxy method (step 4). One should note that it is the requesting agent’s thread which is executing these methods. The getProxy method obtains the requesting agent’s credentials if necessary, by querying the server’s domain database. If permitted by the embedded security policy, the resource object creates an appropriately restricted proxy, and passes it back to the agent via the agent environment (step 5). The agent can now invoke any of the enabled methods of the resource interface, via this proxy object (step 6). The above protocol raises an interesting possibility – it facilitates the dynamic extension of server capabilities. A service provider can dispatch an agent at any time, to install new resources dynamically. The agent can carry resource objects, each of which encapsulates a customized access control protocol, proxy creation mechanism, etc. On arrival at a server, the agent can make such resources available by registering them with the server. Having done so, the agent thread may terminate, leaving the passive resource objects behind. Other agents running on the same agent server can then access such resources via the usual proxyrequest mechanism. Accounting and Revocation: The proxy-based approach presented here offers some other advantages too. The following features can be added by a resource provider by suitably implementing the getProxy method, and extending the proxy class. One can embed usage-metering and accounting mechanisms in a proxy[19]. This can be done either by counting the invocations of each method, possibly assigning different costs to different methods, or by metering the elapsed time for method execution and then basing the charges on it. Even though the reference to a proxy is like a capability, we can limit its propagation from one agent to another by checking whether the invoker of the proxy belongs to the protection domain to which it was originally granted. Thus, a proxy acts as an identity-based capability[6]. This requires extending the proxy by including in its state, the identifier of the protection domain to which it was assigned. It is also possible to add an expiration time to each proxy object. After its expiration, a proxy would simply raise an exception for any invocation of its methods. Also, a resource manager can invalidate any of its currently

active proxies at any time it wishes, or it can selectively revoke or add permissions for specific methods of a given proxy, by invoking a privileged method of the proxy object. The proxy would include access control information about the protection domains that are permitted to execute this privileged method. When the method is invoked, it uses this information to validate its caller’s privileges.

6. Conclusions The major obstacles to deploying the mobile agent paradigm in open distributed systems are security concerns, especially in regard to protecting host resources from malicious agents. In this paper we presented a resource protection scheme that we have developed for a Java-based mobile agent system. The approach taken in this design is to allow visiting agents to use a server’s resources only through proxy objects which are created dynamically by the server, for each agent. Such proxy objects restrict an agent’s use of resources according to some application-defined security policies. This proxy mechanism is based on Java’s security mechanisms such as the security manager, class loader based name-space separation, and strong type checking. It also uses the object-oriented encapsulation mechanism for information protection and supporting dynamic binding between an agent and a resource. This same scheme is also used for controlled binding between agents co-located at a server, allowing them to securely communicate with each other. The proxy-based approach also offers other benefits, such as metering of resource usage and selective revocation or addition of privileges. Privileges can also be revoked based on time-out. A proxy serves as a capability, and its propagation can be restricted by encapsulating within it the identity of the agent to whom it was granted. We would like to note that several other projects have also used a type-safe language to create and enforce protection domains. The SPIN operating system[3] allows applications to safely load extensions written in Modula-3 into the kernel. An approach based on Java is used in choices[17]. It uses name-space separation based on class loaders and it inhibits modifications to Java packages using access control lists.

References [1] S. R. Ames, M. Gasser, and R. Schell. Security Kernel Design and Implementation: An Introduction. IEEE Computer, pages 14–22, July 1983. [2] J. Banino. Parallelism and Fault Tolerance in Chorus. Journal of Systems and Software, pages 205–211, 1986. [3] B. Bershad, S. Savage, P. Pardyaki, E. Sirer, M. Fiuczynski, D. Becker, C. Chambers, and S. Eggers. Extensibility,

[4]

[5] [6]

[7]

[8]

[9]

[10] [11] [12]

[13]

[14]

[15]

[16]

[17]

[18] [19]

[20]

Safety and Performance in the SPIN Operating System. In Proceedings of the 15th ACM Symposium on Operating Systems Principles, pages 267–284, December 1995. J. Bull, L. Gong, and K. Sollins. Towards Security in an Open Systems Federation. In Proceedings of the Second European Symposium on Research in Computer Security - ESORICS’92, pages 3–20. Springer-Verlag, November 1992. GeneralMagic. General Magic’s Odyssey web page. http://www.genmagic.com/agents/odyssey.html, 1997. L. Gong. A Secure Identity-Based Capability System. In IEEE Symposium on Security and Privacy, pages 56–63, May 1989. R. S. Gray. Agent Tcl: A flexible and secure mobile-agent system. In Proceedings of the Fourth Annual Tcl/Tk Workshop (TCL 96), July 1996. C. G. Harrison, D. M. Chess, and A. Kershenbaum. Mobile Agents: Are they a good idea? Technical report, IBM Research Division, T.J.Watson Research Center, March 1995. Available at URL http://www.research.ibm.com/massdist/mobag.ps. J. Hylton, K. Manheimer, F. L. Drake, Jr., B. Warsaw, R. Masse, and G. van Rossum. Knowbot programming: System support for mobile agents. In Proceedings of the Fifth International Workshop on Object Orientation in Operating Systems (IWOOOS ’96), October 1996. IBM. IBM Aglets Workbench Documentation web page. http://www.trl.ibm.co.jp/aglets/documentation.html. JavaSoft. JDK 1.1 Documentation. Available at URL http://www.javasoft.com/products/jdk/1.1/docs/. D. Johansen, R. van Renesse, and F. B. Schneider. An Introduction to the TACOMA Distributed System. Technical Report 95-23, Department of Computer Science, University of Tromsø, June 1995. E. Jul, H. Levy, N. Hutchinson, and A. Black. Fine-Grained Mobility in the Emerald System. ACM Transactions on Computer Systems, 6(1):109–133, February 1988. G. Karjoth, D. Lange, and M. Oshima. A Security Model for Aglets. IEEE Internet Computing, pages 68–77, JulyAugust 1997. J. Kiniry and D. Zimmerman. A Hands-on Look at Java Mobile Agents. IEEE Internet Computing, pages 21–30, JulyAugust 1997. Available at http://computer.org/internet/. J. Y. Levy and J. K. Ousterhout. A Safe Tcl Toolkit for Electronic Meeting Places. In Proceedings of the First USENIX Workshop on Electronic Commerce, pages 133–135, July 1995. W. S. Liao, S. M. Tan, and R. H. Campbell. Fine-grained, Dynamic User Customization of Operating Systems. In Proceedings of the Fifth International Workshop on ObjectOrientation in Operating Systems, pages 62–66, 1996. G. McGraw and E. Felten. Java Security. John Wiley & Sons, Inc., 1996. B. Neuman. Proxy-based authorization and accounting for distributed systems. In Proceedings of the Thirteenth International Conference on Distributed Computing Systems, pages 283–291, May 1993. ObjectSpace. ObjectSpace Voyager Core Package Technical Overview. Technical report, ObjectSpace, Inc., July 1997. Available at URL http://www.objectspace.com/.

[21] H. Peine and T. Stolpmann. The Architecture of the Ara Platform for Mobile Agents. In Proceedings of the First International Workshop on Mobile Agents (MA’97), Berlin, Germany, April 1997. Springer Verlag, LNCS #1219. [22] M. Ranganathan, A. Acharya, S. Sharma, and J. Saltz. Network-aware Mobile Programs. In Proceedings of USENIX ’97, Winter 1997. [23] M. Shapiro. Structure and Encapsulation in Distributed Systems: The Proxy Principle. In Proceedings of the 6th International Conference on Distributed Computing Systems, pages 198–204. IEEE, 1986. [24] K. R. Sollins. Cascaded Authentication. In IEEE Symposium on Security and Privacy, pages 156–163, 1988. [25] J. W. Stamos and D. K. Gifford. Remote Evaluation. ACM Transactions on Programming Languages and Systems, 12(4):537–565, October 1990. [26] J. Steiner, B. Neuman, and J. Schiller. Kerberos: an authentication service for open network systems. In Usenix Conference Proceedings, pages 191–202, Dallas, Texas, February 1988. [27] M. Straer, J. Baumann, and F. Hohl. Mole - A Java Based Mobile Agent System. In Proceedings of the 2nd ECOOP Workshop on Mobile Object Systems, 1996. [28] J. Tardo and L. Valente. Mobile Agent Security and Telescript. In Proceedings of COMPCON Spring ’96, pages 58– 63. IEEE, 1996. [29] J. Vittal. Active Message Processing: Messages as Messengers. In R. Uhlig, editor, Computer Message System, pages 175–195. North-Holland, 1981.