5.3 The CSM Node
5.3.4 Node Services
Running agents have only one object reference to the execution environment and this is a reference to the ServiceChannel where they can put request for node ser-
vices. The classes that support node services are bundled in the a sub-package of the node namednode.services. To request a service the Agent creates a Serviceobject and puts it into the queue (see figure5.6). Some services generate one or more replies that are delivered back to the agent by the NodeServiceDeliv- ery object of the execution environment. Note, that the delivery is asynchronous, it takes place via a queue. The classServiceis defined as follows:
public class Service {
protected static long current=0; protected long number;
protected int type;
protected java.util.Vector args; ...
}
Each service request is numbered (instance variable number). The (static) class variable currenthelps to guarantee the uniqueness of the number. The typefield identifies the desired service. Different services may need different kinds and numbers of arguments. The built-in Java classjava.util.Vector is a container of an arbitrary number of arbitrary java objects. A vector is thus the ideal type for theargsinstance variable which has to store the arguments for all kinds of service requests. Replies to the service are also delivered in objects of class Service. The type and number field of these objects allow the agent to map a service reply to the request that triggered the reply. In the reply the arguments hold results or status messages of the reply.
The ServiceChannel removes service requests from the queue. It has a Ser- viceList that stores references to a handler for each service type. The ServiceChan- nel calls the appropriate handler and passes the service request to it. The Service- Handler then executes the service operations. It also puts results (if there are some) in the reply queue. The service channel and all service handlers can terminate the agent if the agent requests services without permission or if a serious exception occurs during delivery of the service. The ServiceDatabase stores templates of service handlers. When the execution environment of an agent is constructed (see section5.3.2) the service list for the agent is constructed from the templates in the database according to the policy that is valid for the agent in question.
Supported node services. Here is a list of the node services that the CSM node implementation supports, along with a short description of the service, its argu- ments and its reply behavior:
Self-termination. As mentioned before, the agent has no own thread. In- stead it is invoked by the execution environment every time there is some- thing to do. If the agent wishes to stop these invocations it calls this service.
The node will then deallocate the execution environment and de-register (thus kill) the agent. The self-termination service request has no argument and will trigger no reply to the agent.
Result transmission. The agent can request to send a result object along its open connection. This is the most important node service since it is the only way how the agent can deliver monitoring results to the customer. The open connection that is used for the transmission is usually the one that the agent was delivered on. The service object must contain an object of class clientserver.Resultas argument (see CSM communication in sec- tion5.1). CSM communication is reliable therefore the agent does not get a reply.
Host information. This service provides the agent with general information about the host that executes it. Thus, forwarded agents can check themselves if they monitor traffic at interesting locations. This service request has no arguments. The reply contains three arguments. The reply includes the name (identifier) of the node, the name of the organization owning the node, and the DNS address of the node. These names are encodes as Java character strings.
Timer. Since agents are only invoked when something (e.g. a monitored packet) is delivered an agent cannot perform tasks based on regular time intervals or time-outs. Consider an agent that measures the load of a service that is not used. If no packet is monitored the agent stays passive and cannot report that the service is not used. To alleviate this shortcoming the CSM nodes offer a timer service. The service delivers a reply to the agent everyx jiffies1forntimes. The agent uses two integers numbers as arguments in the request, namelyxandn. Each of thenreplies will ’wake up’ the agent and allow it to e.g. send a report message. The replies contain an integer number that simply contains the reply number.
Change the connection. This service closes the currently open connection and tries to open a new one. This service is important for forwarded agents since these do not have an open connection to their home application. The agent must provide several arguments in the request: a character string for the DNS name of the receiver, an integer number for the port, two boolean values that indicate if the node should encrypt respectively authenticate the connection and, if so, a character string with the identity of the receiving party (used for PGP cryptography). The service handler then disconnects the current connection and tries to establish the new connection. The service reply contains a boolean indicating if the connection was established. To send on the new connection the agent simply uses the ’sending’ service.
1
Stop all agents. This service stops all running agents and deallocates their execution environment. It thus resets the node. This is a privileged service that only authenticated and authorized agents can execute. It takes no argu- ment and does not invoke a reply.
Stop the node. This service leads to the graceful termination of the com- plete CSM node. This is a privileged service that only authenticated and authorized agents can execute. It takes no argument and does not invoke a reply.
Note, that the first five services are considered standard and are provided to all agents. The last two service need explicit permission by the policy (see sec- tion5.3.5). They are useful for managing the CSM nodes. Some interesting but unimplemented node services are described in section6.5.2.
Security of node services. The node services allow the agent to perform actions that otherwise are forbidden and prevented. The agent cannot, for example, open a socket. The security manager would terminate the agent for trying this operation (see section5.5). Node services provide access to dangerous functionality in a con- trolled way. Each agent is associated with a policy that exclusively describes what services are delivered to that agent (see next section). If the agent requests other services or does not provide proper arguments it is killed immediately. The node policy can also mark some services as privileged services. The node stopping ser- vice can for example only be triggered by an agent that was authenticated as being send by a root user of the node. The ServiceHandler accounts the service execu- tion time. This helps to prevent node service based denial-of-service attacks by the agents. Furthermore, each service handler can restrict the number of consecutive service requests. The timer service can e.g. only be called once. All node services are designed to execute quickly and to use little node resources. The timer service e.g. uses a large minimum time between tow wake-ups. The change-channel and sending service enforce that only one connection can be open at any time.
Additional node services. Of course, one may imagine many more useful node services. One service for example could be the migration of an agent. An agent could request that it will be send to another node. It could also request that its state be preserved (strong migration [SBB+
00, BLP00]). Yet, non of the CSM applications described in chapter6need strong mobility. So this is not a supported feature of the CSM node implementation. Instead, agent forwarding is used (see section4.4). However, if a new node service such as strong migration will become needed, adding a new service is no problem. The CSM node developer simply has to provide a new template for the service handler (a subclass of ServiceHandler) which implements the service and add it to the service database.