WO2000060466A1

WO2000060466A1 - Management agent and system including the same

Info

Publication number: WO2000060466A1
Application number: PCT/US2000/008967
Authority: WO
Inventors: Thomas Soares; Sukesh Patel; Ashwani Dhawan
Original assignee: Manage.Com
Priority date: 1999-04-05
Filing date: 2000-04-04
Publication date: 2000-10-12
Also published as: AU4071500A

Abstract

A remote sytem for receiving a request (101A) from one or more source systems to execute code with a code execution block (120) in the remote system using an agent is described. The agent has an interface (101A...n) and a code loader (102). The interface (101A..n) receives the request (101A) from either direct or indirect connections and has a handler (101B) to signal the code execution block (120) to execute the code if the code is resident on the remote system. The code loader (102) loads nonresident code from a trusted code source in response to the interface (101A..n) being unable to locate the code. The code loader (102) has a certification block (102A) and a code authorization block (102B). The certification block (102A) verifies the code loaded from the trusted code source has been certified as safe by a trusted authority (103B), and the code authorization block (102B) verifies the code (103D) is authorized to be executed by the code execution block (120).

Description

MANAGEMENT AGENT AND SYSTEM INCLUDING THE SAME

FIELD OF THE INVENTION

The present invention relates to the field of controlling computer systems from a remote location; more particularly, the present invention relates to a management agent that responds to requests received from remote locations to execute resident or nonresident code.

BACKGROUND OF THE INVENTION

Today, there are many cases in which a program running on one system,

hereinafter referred to as the source system, is used to execute code on another system,

hereinafter referred to as the remote system. For example, network management

applications often need to execute code on remote systems in order to do monitoring,

control, maintenance, or diagnostic functions. Security is of the utmost importance in

executing code on remote systems, since those systems are often servers that are

business critical and /or contain sensitive information and allowing access to remote systems may make them susceptible to unauthorized access.

In the prior art, there are currently at least four approaches in which source

systems can access remote systems. In a first approach, a source system may access a

remote system using remote shells or remote access protocols such as TELNET. With

this approach, a program nirining on a source system opens a connection to the remote

system and has access to a standard command shell on that system, through which it

can initiate actions.

A second approach uses remote control protocols/products, such as PCAnywhere or X-Windows. These approaches are graphical user interface (GUI)-

based methods of access that present a GUI on the source system which is actually

connected to and driven by the remote system.

In a third approach, agents are used to facilitate the control of using remote

systems using standard network management protocols (such as SNMP or Microsoft

WBEM). These agents allow an application running on the source system to perform

various actions on the remote system. For example, SNMP agents allow SET operations

that affect the state of the remote system, and Microsoft's WBEM allows method calls to

be made on WBEM objects that also modify the state of the remote system.

The fourth approach uses proprietary, application-specific agents which are

installed on the remote system, but are designed to be used only by a particular

application. Examples include SMB agent from Microsoft of Redmond, Washington, and agents manufactured by Hewlett Packard of Palo Alto, California, Compaq

Computer of Houston, Texas, Computer Associates of New York, as well as others.

One problem with one or more of these approaches is that they do not allow

control or trust to be imposed over what code is executed on the remote systems. For

example, the first two approaches only allow controlling whether a user can or can't

load (from another system) and execute code on the system. They do not allow an

individual to specify that a user and /or program on the source system may load and

execute certain pieces of code on the remote system but not others. For example, to

load and execute code on a remote system using TELNET, the user must have permission to run FTP (or some other transfer protocol), the ability to save files to a

directory, and execute a program. However, if a user has these privileges, the user

cannot be restricted to only loading and executing certain pieces of code.

Another problem with one or more of these approaches is that they do not allow

arbitrary code to be executed. For example, the approaches that use SNMP and WBEM

agents allow a fixed & predefined set of functions to be performed. Users and/or

programs desiring to execute other code must find an alternate way of doing so. The

approach of using proprietary agents typically also has this problem since they are

designed to work with a particular application and, therefore, support only the

functionality needed by that application.

An additional problem with one or more of these approaches is that they cannot

be accessed by an arbitrary program running on the source system. For example, some

proprietary agents are only designed to work with one particular application, making

them useless to any other program.

Still another problem with one or more of these approaches is that the source system must communicate with the remote system by establishing a direct connection

over some sort of binary protocol, typically using TCP/IP. This limits the utility of the

approaches and makes prior art approaches useless to programs on a source system

that cannot establish a direct connection to the remote system due to such reasons as

security restrictions (i.e., firewalls) or intermittent availability of communications (for

example, if the remote system via a periodically established dial-up connection).

What is needed is an approach to allowing a source system to cause code to execute on a remote system that avoids one or more of the above referenced problems. SUMMARY OF THE INVENTION

A remote system for receiving a request from one or more source systems to execute code with a code execution block in the remote system using an agent is described. In one embodiment, the agent has an interface and a code loader. The interface receives the request from either direct or indirect connections and has a handler to signal the code execution block to execute the code if the code is resident on the remote system. The code loader loads nonresident code from a trusted code source in response to the interface being unable to locate the code. In one embodiment, the code loader has a certification block and a code authorization block. The certification block verifies the code loaded from the trusted code source has been certified as safe by a trusted authority, and the code authorization block verifies the code is authorized to be executed by the code execution block.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be understood more fully from the detailed description given below and from the accompanying drawings of various embodiments of the invention, which, however, should not be taken to limit the invention to the specific embodiments, but are for explanation and understanding only.

Figure 1 is a block diagram of one embodiment of a management agent interacting with an external environment.

Figure 2 is a flow diagram of one embodiment of the process performed by a management agent, such as the management agent shown in Figure 1.

Figure 3 is a flow diagram of one embodiment of the process performed by a code loader. DETAILED DESCRIPTION OF THE PRESENT INVENTION

A management agent facilitating execution of code on a remote system is

described. In the following description, numerous details are set forth. It will be

apparent, however, to one skilled in the art, that the present invention may be practiced

without these specific details. In other instances, well-known structures and devices are

shown in block diagram form, rather than in detail, in order to avoid obscuring the

present invention.

In the following description, for purposes of explanation, numerous specific

details are set forth in order to provide a thorough understanding of the present

invention. It will be apparent, however, to one skilled in the art that the present

invention can be practiced without these specific details. In other instances, well-

known structures and devices are shown in block diagram form in order to avoid

obscuring the present invention.

Some portions of the detailed descriptions which follow are presented in terms

of algorithms and symbolic representations of operations on data bits within a

computer memory. These algorithmic descriptions and representations are the means

used by those skilled in the data processing arts to most effectively convey the

substance of their work to others skilled in the art. An algorithm is here, and generally,

conceived to be a self-consistent sequence of steps leading to a desired result. The steps

are those requiring physical manipulations of physical quantities. Usually, though not

necessarily, these quantities take the form of electrical or magnetic signals capable of

being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these

signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar terms are to be

associated with the appropriate physical quantities and are merely convenient labels

applied to these quantities. Unless specifically stated otherwise as apparent from the

following discussions, it is appreciated that throughout the present invention,

discussions utilizing terms such as "processing" or "computing" or "calculating" or

"determining" or "displaying" or the like, refer to the action and processes of a computer

system, or similar electronic computing device, that manipulates and transforms data

represented as physical (electronic) quantities within the computer system's registers

and memories into other data similarly represented as physical quantities within the

computer system memories or registers or other such information storage, transmission

or display devices.

The present invention also relates to apparatus for performing the operations

herein. This apparatus may be specially constructed for the required purposes, or it

may comprise a general purpose computer selectively activated or reconfigured by a

computer program stored in the computer. Such a computer program may be stored in

a computer readable storage medium, such as, but is not limited to, any type of disk

including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only

memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or

optical cards, or any type of media suitable for storing electronic instructions, and each

coupled to a computer system bus. The algorithms and displays presented herein are not inherently related to any

particular computer or other apparatus. Various general purpose systems may be used

with programs in accordance with the teachings herein, or it may prove convenient to

construct more specialized apparatus to perform the required method steps. The

required structure for a variety of these systems will appear from the description below.

In addition, the present invention is not described with reference to any particular

programming language. It will be appreciated that a variety of programming

languages may be used to implement the teachings of the invention as described herein.

Overview of the Extensible Management Agent

The present invention allows a program running on a source system to execute a

particular piece of code on a remote system. The present invention uses an agent on the

remote system to accomplish the execution. The agent receives a request to execute

code from one or more source systems. The requests may be system specific requests

(requests that are specific to the platform to which they are sent) or machine

independent requests (requests that are not specific to the platform to which they are

sent and need to be interpreted for the platform that receives them). The

communication of requests may be through a direct connection or an indirect

connection, such as when a direct connection is not possible (such as when the systems

are separated by firewalls or when the only connection between the systems is via a

periodically established communications channel (such as a dial-up connection)).

In response to a request to execute code, the agent determines if the code is

present on the remote system. If the code is not resident on the remote system, the agent is able to load the code for execution thereafter. In one embodiment, to ensure

the remote system only executes secure code, the agent ensures that the code is loaded

from a trusted source. This prevents a hacker from replacing code which is to be loaded

and executed by the remote system. In one embodiment, the agent also verifies that the

code is from certifying authority who is trusted to sign only "safe" code. Allowing only

certified code prevents a hacker that manages to access a trusted source from causing

unsafe code to be executed on the remote system.

In one embodiment, the identities of all parties involved in the communications

(e.g., the source system, the remote system, and the trusted code source) are validated.

If their identities are not validated, it may be possible for a hacker to impersonate a

trusted party.

In one embodiment, the agent on the remote computer system is able to prohibit

any piece of code, even if it is "trusted", from execution on the remote system. This

may be necessary because pieces of code that are trusted on one system may not be

trusted on another. Similarly, the agent is able to control the actions (such as, for

example, deleting files, opening network connections, or starting /stopping processes)

that any or all code can perform. This may be necessary because of the difficulty in

knowing what actions a particular piece of code can do, and /or it may be desirable to

always prohibit certain actions on particular systems. In one embodiment, the

operating system security policies are not overridden in order to prevent bypassing the

operating system as a security breach.

Advantages of one or more of the embodiments of the management agent include the elimination of the need for upgrade and reinstallation of agent software, the ability to dispatch needed functionality on-demand, and the ability to configure agent

with only needed functionality.

An Exemplary Management Agent

Figure 1 is a block diagram of one embodiment of a management agent that

receives requests to execute code from one or more source systems and executes the

code on an execution functional unit on the remote system. Referring to Figure 1, the

management agent comprises a communications interface 101, code loader 102, a

database 103, and a security manager 104. In one embodiment, the management agent

comprises one or more software modules installed on a remote system. The software

may be running continuously.

Communication interface 101 allows communications to and from the agent. In

one embodiment, communications interface 101 permits communications over various

protocols. These protocols may not require a direct connection, which is particularly

advantageous in situations where such a connection is not possible. Also,

communication interface 101 does not require a binary protocol.

The communications permitted by communications interface 101 may include

external requests sent to the agent to execute a piece of code. Each request contains

identifying information that enables the agent to identify and locate that piece of code.

In one embodiment, communications interface 101 comprises receivers 101A._.N

coupled to receive requests. Each of receivers 101 A._.N may be part of a transceiver. In

one embodiment, receiver 101A. supports communication with TCP/IP socked

connections using the SSL protocol with digital certificates for identity validation. In one embodiment, receiver 101A₂ supports exchange of electronic mail (e-mail)

communications by communication with an E-mail server using any standard e-mail

protocol. In one embodiment, messages received by receiver 101A. to which the agent

responds are contained in the contents of the e-mails. For example, the agent may

receive a request to execute a piece of code that is contained in an e-mail message. In

one embodiment, the contents of the e-mail messages are encrypted and digitally

signed.

A message handler 101B is coupled to receive messages and other information

from receivers 101A1-N. In response to requests to execute a particular piece of code,

message handler 101B determines whether or not the code is resident on the remote

system. If message handler 101B determines that the code is present on the remote

system, then message handler 101B causes code execution block 120 to execute the code.

In one embodiment, upon receiving a request to execute a particular piece of

code, message handler 101B extracts identification information (e.g., a code identifier)

from the request and examines a table that lists code that is resident on the remote

system to determine whether the code's identification information is listed. The table

may be stored in database 103 or any other storage area. If the code's identification

information is listed, then message handler 101B knows that the code is already resident

on the remote system. In one embodiment, the table also includes a pointer (e.g., an

address) to the location in memory where the code is stored. Using the code's

identification information, message handler 101B identifies the pointer to the code and

forwards the pointer to code execution block 120 to cause execution of the code. In an alternative embodiment, message handler 102 uses the pointer to access the code and

then forwards the code to code execution block 120 for execution thereby.

Code loader 102 is capable of loading code that message handler 101B

determines is not present on the remote system. In one embodiment, code loader 102

loads code using a communications mechanism. The communications mechanism may

comprise a transceiver (not shown) or one of receivers 101A._.N that is capable of

operating as a transceiver. In one embodiment, code loader 102 uses the identification

information that was extracted from the request by message handler 101B.

Note that in one embodiment, the requests directed to the remote system are

universal to a number of different platforms (e.g., Windows NT, UN LX, etc.). That is, a

universal requests are used and interpretable and may be acted on by agents of

different platforms. In such a case, code loader 102 (and/or message handler 101B in an

alternate embodiment) interprets the request and loads the code that satisfies the

request for the particular system on which the code is to be executed. For example, if a

source system wants to obtain a directory listing, it sends a universal request, such as

"Hsting" to an agent. In response to the "Hsting" command, code loader 102 of the

agent recognizes that the remote system upon which it resides is a Windows NT

system, in this example, and loads the code to perform the listing command for the

Windows NT system. To identify the system (platform) specific code like loading it,

code loader 102 may specify its platform type in the request to code sources, along with

the code identifier.

In one embodiment, code loader 102 only loads code from trusted sources.

Therefore, code loader 102 comprises certification block 102A that verifies that the code loaded by code loader 102 has been certified by a trusted code certifying authority and

code authorization block 102B that verifies that the code is authorized code. In one

embodiment, code loader 102 ensures that any code that is executed on the agent

satisfies the flowing criteria: 1) the code was received from a trusted source; 2) the

code was certified as "safe" by a trusted certification authority; and 3) the agent is

specifically configured to allow the piece of code to run. These criteria together

establish that a reasonable degree of trust exists for any piece of code that the agent

executes. This eliminates the problem that prior solutions have with not being able to

ensure that only trusted code is executed on the remote system.

After verifying that the code has been certified by a trusted code certifying

authority and verifying that the code is authorized code, code loader 102 stores the code

on the remote system and updates a code location table 103E with the code's

identification information and the pointer for the code. In an alternative embodiment,

message handler 101B creates an entry in table 103E by storing the code's identification

information therein prior to code loader 102 obtaining the code, and code loader 102 is

responsible for storing the pointer information into table 103E. Either message handler

101B or code loader 102 causes code execution block 120 to execute the newly loaded

code once code loader 102 notifies message handler 101B that the code has been loaded

and stored. Alternatively, code loader 102 signals code execution block 120 to execute

the code.

Note that those portions of communications interface 101 and code loader 102 by

which requests are made for the agent to execute code and by which the agent actually

loads and invokes the code may be generic, in that any piece of code could potentially be executed on the agent if it satisfies all of the trust criteria listed above. This

overcomes the limitation that some prior solutions have of only working with a

particular, proprietary application.

Database 103 stores configuration information. Database 103 may comprise one

or more separate memories. In one embodiment, the configuration information

includes a list of trusted code sources 103A, a list of code certifying authorities 103B, a

list of authorized code 103C, and a list of authorized actions 104D. Code loader 102

accesses database 103 to obtain information regarding trusted code sources, code

certifying authorities, and authorized code to determine if code being loaded onto the

remote system for execution is safe for execution.

The list of trusted code sources 103 A indicates those sources from which the

agent can load code and data to execute. In one embodiment, for each source, database

103 stores the protocol and other information necessary to communicate with the

source. For example, for the TCP/IP protocol, database 103 stores the IP address and

port number of the code source.

The list of code certifying authorities 103B are those entities who are trusted to

certify only pieces of code that are safe to execute. In one embodiment, for each

certifying authority, database 103 includes information necessary to validate a digital

signature from that authority. This information may comprise a certifying authority's

public key to enable decryption of information that the certifying authority has

encrypted with its private key using an asymmetric encryption scheme.

The list of authorized code 103C indicates portions of code explicitly permitted or prohibited from executing on the agent. In one embodiment, the list specifies a default permission that applies to all code that does not have an explicit permission. In

an alternative embodiment, the list indicates only the code that does not have explicit

permission.

The list of authorized actions 103D specify those actions that are permitted and

prohibited on the agent. In one embodiment, the list indicates only those actions which

are permitted, thereby implicitly making all other actions prohibited by default. In an

alternative embodiment, the list indicates each individual action that is prohibited,

thereby implicitly making all other actions permitted by default. Actions that may be

prohibited include actions such as, for example, deleting files or opening network

connections.

In one embodiment, security manager 104 ensures that code executing on the

agent is subject to a control policy based on the agent's configuration. This overcomes

the limitation of prior art approaches not being able to ensure control over what actions

a piece of code performs when that code is executed on the remote system. Security

manager 104 uses the list of authorized actions 103D to control which actions a piece of

code is allowed to perform. While the code is executing, but before each individual

action is performed, security manager 104 determines whether the action in question is

on the list of authorized actions 103D by accessing database 103. If the action in

question does not appear on the list, then, in one embodiment, security manager 104

prevents the action from occurring while permitting the remainder of the code to

execute. In an alternative embodiment, security manager 104 prevents further

execution of the code in its entirety upon encountering an unauthorized action in the

code. In one embodiment, security manager 104 also restricts access to the native

operating system to only certain pieces of code, controls access to pieces of code that

can access the native operating system, ensures that all calls to the native operating

system are subject to the security policy of the native operating system, and restricts

calls made to the various Application Programming Interfaces (APIs) available within

the agent (e.g., a Java security Manager).

Figure 2 illustrates the process by which a source system causes a particular

piece of code to execute on a remote system. Referring to Figure 2, the process begins

by one of receivers 101A._.N in communication interface 101 receiving a request to

execute a piece of code (processing block 201). In response to the request, message

handler 101B identifies the piece of code to be executed based on identifying

information in the request (processing block 202). In one embodiment, message handler

101B identifies the piece of code by an ID number that is included in the request.

Then, message handler 101B tests whether the code to be executed is resident on

the remote system (processing block 203). In one embodiment, using the ID number

obtained from the request, message handler 101B accesses code location table 103E in

database 103 that identifies code is resident on the remote system along with its storage

location. Message handler 101B searches code location table 103E to locate the ID

number from the request. If message handler 101B finds a matching entry, the code is

resident on the remote system. If message handler 101B cannot find an entry, then the

code is not located on the system.

If the code is resident on the system, message handler 101B causes code execution block 120 to execute the code (processing block 204) and the process ends. In one embodiment, upon finding the ID number (extracted from the request) in code

location table 103E, message handler 101B obtains the pointer to the piece of code for

that particular ID number and forwards the pointer to code execution block 120, which

uses the pointer to access and execute the code.

If the code is not resident on the system, message handler 101B signals code

loader 102 to obtain the code (processing block 205). Code loader 102 loads the code

from a trusted source and ensures that the code is safe to execute on the remote system

(processing block 206). Once code loader 102 determines the code is safe to execute,

code loader 102 causes code execution block 120 to execute the code while security

manager 104 ensures no unauthorized actions are performed (processing block 207).

Security manager 104 monitors execution of the code and prevents execution of

non-allowed operations. For example, even if code is trusted, security manager 104 can

prevent certain actions or operations from occurring such as, for example, deleting files

or opening a network connection. In one embodiment, prior to an operation occurring,

security manager 104 accesses database 103 to determine if the action is indicated as

being allowed in the list of allowed actions 103D. In one embodiment, in response to

identifying a non-allowed operation, security manager 104 prevents the non-allowed

operation from occurring but permits the execution of the code to continue. In an

alternative embodiment, in response to identifying a non-allowed operation in the code,

security manager 104 prevents the code from executing any further.

Security manager 104 may also be responsible for implementing operating

system security measures. For example, security manager 104 may request

authentication information to perform selected operations. In one embodiment, the authentication information comprises a user ID and password. If the correct

authentication information is entered by a user, security manager 104 permits the

selected operation to proceed. In one embodiment, security manager 104 performs this

function by accessing of list of actions requiring authentication information from a

memory or storage and requiring the authentication information for the specific actions

listed. These actions may be those which are handled by one or more utility application

programming interfaces (API) or codes that are called in the agent to perform one or

more designated functions. For instance, a utility code may be called to delete files or open a network connection.

Note that all operations whose execution can be controlled may comprise one or

more instructions. Therefore, the monitoring that is performed by security manager 104

to prevent execution of unauthorized operations may be performed at the instruction

level or higher depending on the embodiment.

Figure 3 is a flow diagram of one embodiment of the process of code loader 102

loading code from a trusted source and ensuring that the code is safe to execute on the

remote system. In one embodiment, code loader 102 requests and obtains the non¬

resident code by contacting one or more of the trusted sources on the list of trusted

sources 103A to determine if the desired code is available from that trusted code source.

Referring to Figure 3, the process begins by code loader 102 accessing the list of

trusted sources 103A to obtain a trusted source and obtain information allowing it

contact the trusted source (processing block 301). Using that information, code loader

102 contacts that particular trusted source and requests the desired code (processing

block 302). A test determines if the trusted source has the code (processing block 303). If the trusted code source does not have the requested code, then processing

loops back to processing block 302 where code loader 102 obtains the next trusted

source on the list and the code requesting process continues. Code loader 102 repeats

this looping process until the desired code can be found on one of trusted code sources

on the list of trusted code sources 103A. In the event that none of the trusted sources in

the trusted source list 103 A in database 103 have the desired code, the operation fails

and the remote system will not execute the code.

If the trusted code source has the requested code, code loader 102 receives the

code sent from the trusted code source (processing block 304). Once the code has been

received, code loader 102 verifies that the code is signed by one of the trusted

authorization parties (e.g., a trusted certification authority) that it recognizes by

accessing the list of certifying authorities 103B in database 103 (processing block 305)

and verifying the digital signature on the code as belonging to one of the listed

certifying authorities (processing block 306). In one embodiment, the code has been

encrypted using a certifying authority's private key and the list of certifying authorities

103B includes the public key of each of the listed certifying authorities. Using the public

key, code loader 102 is able to decrypt the encrypted code, thereby verifying its

signature.

Once the code has been certified as safe, code loader 102 determines whether the

code should be rejected by accessing database 103 to obtain the list of allowed code

103C (processing block 307) and comparing the list to the code that was loaded from the

trusted source to determine if the code is allowed to be executed on the remote system (processing block 308). If the code is not allowed, code loader 102 prevents the code from executing (processing block 309). In one embodiment, code loader 102 doesn't

permit the code to be stored on the remote system.

In an alternative embodiment, the process of determining whether the code is

allowed (processing blocks 307, 308, 309) is performed prior to obtaining a trusted

source from the list (processing block 301), retrieving the code from a trusted source,

and verifying the code is from a certified authority. In this manner, the remote system

avoids loading code that is not going to be allowed to execute.

If the code is allowed, code loader 102 stores the code at a location in memory

available to the remote system (processing block 310) and updates code location table

103E to identify the location of the code in memory (processing block 311). In one

embodiment, code loader 102 updates code location table 103E by storing both the ID

number associated with the code and the pointer to the code in the table 103E. In an

alternative embodiment, message handler 101B may create an entry for the ID number

identifying the code and code loader 102 updates the pointer information for that

particular ID number after storing the code in memory. In still another embodiment,

code loader 102 provides both the ID number and the pointer information to message

handler 101B to allow message handler 101B to update code location table 103E. With

the location table updated, message handler 102 provides the pointer pointing to the

location code in memory to code execution block 120 to cause code execution block 120

to execute the code. In an alternative embodiment, code loader 102 causes code

execution block 120 to execute the newly loaded code.

Whereas many alterations and modifications of the present invention will no

doubt become apparent to a person of ordinary skill in the art after having read the foregoing description, it is to be understood that any particular embodiment shown and

described by way of illustration is in no way intended to be considered limiting.

Therefore, references to details of various embodiments are not intended to limit the

scope of the claims which in themselves recite only those features regarded as essential

to the invention.

Thus, a management agent and a method of having a source system cause a remote system to execute code has been described.

Claims

CLAIMSWe claim:

1. A remote system for receiving a request from one or more source systems to execute code with a code execution block in the remote system using an agent, the agent comprising: an interface to receive the request from either direct or indirect connections, the interface having a handler to signal the code execution block to execute the code if the code is resident on the remote system; a code loader to load nonresident code from a trusted code source in response to the interface being unable to locate the code, the code loader comprising a certification block to verify the code loaded from the trusted code source has been certified as safe by a trusted authority; and a code authorization block to verify the code is authorized to be executed by the code execution block.

2. The system defined in Claim 1 wherein the request includes an identifier to allow the interface to identify the code.

3. The system denned in Claim 1 wherein the indirect connection comprises an electronic mail channel.

4. The system defined in Claim 1 wherein the agent further comprises a database coupled to the interface and the code loader.

5. The system defined in Claim 4 wherein the database stores a code location table, and wherein the handler obtains an identifier identifying the code from the request and determines whether the code is resident on the remote system by determining whether the identifier is in the code location table.

6. The system defined in Claim 5 wherein code location table contains a pointer to the code and the handler obtains the pointer upon locating the identifier in the code location table and send the pointer to the code execution block to signal the code execution block to execute the code stored at the location designated by the pointer.

7. The system defined in Claim 4 wherein the database stores a list of trusted

sources and the code loader accesses the list to obtain a first trusted source to contact in

order to obtain the code.

8. The system defined in Claim 7 wherein the code loader contacts the first

trusted source using contact information stored in the database for the list of trusted

sources.

9. The system defined in Claim 7 wherein the code loader accesses the list

again to obtain a second trusted source to contact in order to obtain the code if the first

trusted source does not contain the code.

10. The system defined in Claim 4 wherein the database stores a list of

certifying authorities, and the code loader accesses the list to determine if code loaded

from the trusted source is certified by at least one of the certifying authorities.

11. The system defined in Claim 10 wherein the code loader prevents the code

from executing if the code loader determines that the code is not certified by at least one

certifying authority in the list of certifying authorities.

12. The system defined in Claim 4 wherein the database stores a list of

authorized code, and the code loader accesses the list to determine if code loaded from

the trusted source is authorized as indicated by the list of authorized code.

13. The system defined in Claim 12 wherein the code loader prevents the code from executing if the code loader determines that the code is not authorized as

indicated by the list of authorized code.

14. The system defined in Claim 4 wherein the database stores a list of

authorized code, and the code loader accesses the list to determine if code to be loaded

is authorized as indicated by the list of authorized code.

15. The system defined in Claim 12 wherein the code loader prevents the code

from loading if the code loader determines that the code is not authorized as indicated

by the list of authorized code.

16. The system defined in Claim 1 wherein the agent further comprises a

security manager to prevent unauthorized actions in the code from being performed.

17. The system defined in Claim 16 wherein the database stores a list of

authorized actions, and the security manager accesses the list to determine if actions in

the code being executed by the code execution block are authorized and prevents any

unauthorized actions from being performed.

18. The system defined in Claim 1 wherein request comprises a universal

request recognizable by a plurality of agents.

19. A method for executing code with a remote system

receiving a request;

identifying code to be executed from the request;

determining if the code is resident on the system;

causing execution of the code if the code is resident;

signaling the code loader to load the code, loading the code from a trusted source

and confirming the code is safely executable if the code is not resident.

20. The method defined in Claim 19 wherein signaling the code loader to load

the code comprises:

accessing a list of allowed code;

determining if execution of the code is allowed; and

preventing code from being loaded if code is not allowed.

21. The method defined in Claim 19 further comprise:

accessing a list of allowed code;

determining if execution of the code is allowed;

preventing code from being loaded if code is not allowed;

otherwise:

obtaining a trusted source from a list of trusted sources;

requesting the code from the trusted source;

determining if the trusted source has the code being requested; and

repeating the steps of obtaining a trusted source from a list and requesting

code from the trusted source if the first trusted source does not have the code.

22. The method defined in Claim 19 further comprising:

obtaining a first trusted source from a list of trusted sources;

requesting the code from the first trusted source;

receiving an indication that the first trusted source has the code being requested;

receiving the code from the first trusted source; and

verifying that the code has been certified by a certifying authority.

23. The method defined in Claim 22 wherein verifying that the code is from a

certifying authority comprises verifying a digital signature on a code.

24. The method defined in Claim 22 further comprising:

accessing a list of allowed code;

determining if execution of the code is allowed; and

preventing code from being loaded if code is not allowed.

25. The method defined in Claim 19 wherein the step of signaling the code

loader to load the code comprises:

obtaining a trusted source from a list of trusted sources;

requesting the code from the trusted source;

determining if the trusted source has the code being requested;

repeating the steps of obtaining a trusted source from a list and requesting code

from the trusted source if the first trusted source does not have the code; receiving code from the trusted source;

accessing lists of certifying authorities; and

verifying that the code has been certified by a certifying authority.

26. The method defined in Claim 25 wherein verifying that the code has been

certified by a certifying authority comprises verifying a digital signature

of the code.