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 101A2 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.