Monitor and Control of Mobile Agent Applications

Monitor and Control of Mobile Agent ApplicationsPaolo Bellavista, Antonio CorradiDipartimento di Elettronica, Informatica e Sistemistica, Università di BolognaViale Risorgimento, 2 - 40136 Bologna - ItalyPh.: +39-051-2093001 - Fax: +39-051-2093073E-mail: {pbellavista, acorradi}@deis.unibo.itCesare StefanelliDipartimento di Ingegneria, Università di FerraraVia Saragat, 1 – 44100 Ferrara - ItalyPh.: +39-0532-293831 - Fax: +39-0532-768602E-mail: cstefanelli@ing.unife.itAbstractMobile agents raise significant security concerns that have been the focus of several research activities. However, some security-related issues, such as the protection against denial of service attacks and the accounting of agent resource consumption, still need further investigation. Solutions to these problems require monitoring the resource state during agent execution, in order to control and possibly limit resource usage. The paper presents solution guidelines for the on-line monitoring and control of Java-based mobile agents. In particular, it describes the implementation of MAPI, an on-line monitoring component integrated in the SOMA mobile agent platform. MAPI exploits the JVMPI and JNI technologies to achieve full visibility of the state of both Java and platform-dependent resources from within the Java Virtual Machine.1IntroductionNotwithstanding the advantages of the Mobile Agent (MA) technology in several application domains, and the availability of many MA platforms, we still lack examples of medium- and large-scale MA-based "industrial" services. One of the motivations stems from the fact that software companies still have doubts about the exploitation of the MA technology, mainly because of security problems.Researchers have obtained significant results in the MA security area, both in protecting execution environments from running agents and in defending agents from their current contexts of execution [1] [2]. Most MA platforms permit to define and enforce policies to rule the agent access to available resources. The enforcement of security policies depends on a preliminary phase of authentication of the agent responsible, usually called agent principal, and on the association of the principal with the correct access permissions. Different MA systems provide different levels of flexibility for agent authentication (e.g., based on code source, on credentials, or both) and for expressing access control policies (e.g., role-based access [3]).Investigation supported by the Italian “Consiglio Nazionale delle Ricerche” in the framework of the Project “Global Applications in the Internet Area: Models and Programming Environments” and by the University of Bologna (Funds for Selected Research Topics: "An integrated Infrastructure to support Secure Services").However, traditional access control techniques are not targeted to protect against such security attacks as denial-of-service, and cannot support the accounting to agent principals of resource consumption. These issues require to support the measurement, the monitoring and the limitation of resource usage of running agents while they execute. For instance, even if several agents of the same principal are authorized to execute on one host, the administrator may want that the total CPU time consumed by those mobile agents do not overcome a specified percentage threshold, to preserve the availability of other services running on that host. Similarly, an authenticated agent may have the permission to open network connections on one host, but should be accounted for the amount of generated traffic. We claim that the possibility to monitor and control resource usage during agent execution, i.e. agent on-line monitoring, is a critical factor for the acceptance and the diffusion of the MA technology.All recent MA platforms use Java as the implementation language. The adoption of the Java platform presents undeniable advantages for MA systems (dynamic class loading, serialization, security mechanisms and policies, directly provided as basic facilities of the language environment). However, the Java Virtual Machine (JVM) level of abstraction tends to hide platform-dependent information and seems an obstacle when dealing with on-line monitoring. Some extensions of the Java technology can help in overcoming this transparency: the JVM Profiler Interface(JVMPI) [4] exports several JVM internal events for debugging and monitoring purpose, while the Java Native Interface (JNI) [5] permits to integrate Java programs with platform-dependent executable code.We claim that the on-line monitoring functionality should be considered a basic facility of any MA platform. The availability of a monitoring component integrated in an MA system permits to control agents at runtime, and to enable corrective actions to enforce the desired policies in resource usage. In addition, the same monitoring component gives mobile agents the visibility of the current state of the systems where they operate, thus facilitating the implementation of MA-based distributed monitoring tools.We have defined a Monitoring Application Programming Interface (MAPI) and implemented it as a monitoring component of the Secure Open Mobile Agent (SOMA)* platform [6] [7]. The MAPI implementation exploits JVMPI to collect several application-level events produced by Java applications (e.g., object allocation and method invocation). In addition, it employs the JNI technology to make possible the integration with platform-dependent native monitoring mechanisms, that we have currently implemented for Windows NT, Solaris and Linux.2Technologies for On-line Monitoring of Java-based Mobile AgentsWe define JVM resources all the resources supported by the JVM and visible to a Java-based running agent. The set of JVM resources coincides with the local and remote resources accessible as Java objects. We call Operating System (OS) resources all other execution resources used by Java-based running agents but transparent because of the abstraction layer of the virtual machine. For instance, authorized Java agents use CPU, memory, and in/out bandwidth of their current execution environment, but the JVM limits their visibility of the usage of these resources, e.g., the effective CPU time and the allocated memory of a specific agent thread.The Java programming environment provides mechanisms to control the access to any JVM resource. Java-based MA platforms exploit the Java SecurityManager, either in its basic version or in a proprietary specialization: in this way, MA platforms can control the JVM resource access via the definition of suitable permission classes and security policies. Nevertheless, the SecurityManager mechanism can only control Java code access * SOMA is available at http://lia.deis.unibo.it/Research/SOMA/permissions. Mobile agents also require other mechanisms and tools, able to dynamically ascertain the quality of usage in accessing resources, both JVM and OS ones.Therefore, MA systems call for facilities for on-line measurement and control of resource consumption in Java. Two solution guidelines are feasible.The first is to build ad-hoc resource managers for any type/instance of resource potentially accessible by mobile agents, and to force agents to work on resources only via these intermediary entities. In this case, agents have no direct visibility of resources, and always pass through resource proxies. This solution requires to write at least one manager for each type of recognized resource, and also imposes the overhead of a proxy.The second possibility is to organize an on-line monitoring service that inspects the state of both JVM and OS resources during agent execution. This is possible by exploiting both JVMPI and JNI technologies to extend the visibility achievable from within the JVM.JVMPI can help in monitoring and controlling the consumption of Java resources. JVMPI is an experimental interface featured by the Java 2 platform and mainly designed to help developers in the debugging of Java applications. JVMPI is a two-way API between the JVM and a dedicated profiler agent. In one direction, the JVM notifies several internal events (e.g., Java thread state change, class loading operations, object allocation/deallocation) to the profiler agent. In the other direction, the profiler agent can enable/disable the notification of specific types of events and can perform some limited management actions on the JVM (e.g., suspend/resume Java threads and enable/disable/force the garbage collector execution).JNI is the standard way to invoke platform-dependent code with visibility of OS resource state within the standard JVM. JNI is a two-way API interface that permits Java threads to invoke native methods, i.e., platform-specific functions typically written in C/C++, usually available as Windows NT Dynamic Link Libraries (DLL) and as Shared Object (SO) libraries under Solaris and Linux. In one direction, any Java program can invoke a native method, simply by declaring the method with the keyword native and with no body. After the binding obtained by calling the System.loadLibrary() method, the JVM uses JNI to call the requested function in the native library during the execution. JNI specifies the mode of method invocation: for instance, it rules how to perform parameter marshalling/unmarshalling between the Java invoking thread and the invoked native method. In the other direction - from the native library to call JVM entities), JNI provides native methods with callbacks to the Java environment and to the invoking Java object, that can access and modify object values, call Java methods, and raise Java exceptions.3Local Monitoring and Control of SOMA AgentsSOMA is an MA framework that provides services for agent migration, naming, communication, security and interoperability. It has been designed in a modular way, as a set of layered middleware services to support the implementation of SOMA-based applications (see Figure 1), by using a Java implementation to achieve portability. SOMA mobile agents allow the dynamic installation and the extension of infrastructure/service components by permitting code migration during execution. Other articles [6] [7] give a general presentation of the SOMA platform and of its middleware services, while here we focus on the specific solutions adopted for the monitoring and control of SOMA agents.Any SOMA execution environment can host an on-line monitoring component, called MAPI, that is able to inspect the state of local JVM and OS resources, and to operate simple management actions on local mobile agents. The MAPI component is optional to reduce the space needed for SOMA installation, and can eventually be added at runtime.SOMAServices Figure 1MAPI monitors the state of resources used by agents at any single host, and exploits the SOMA platform itself to coordinate different local monitoring entities (see Section 4). This organization achieves a global vision of the monitored distributed infrastructure and performs the on-line management of SOMA-based services.Figure 2 shows the architecture of the MAPI component, implemented by the ResourceManager class. ResourceManager exploits an ad-hoc profiler agent to gather application-level information about any Java thread running on the monitored target. The MAPI profiler agent collects and processes JVMPI events on-line, to offer concise monitoring indicators during service execution. The JVMPI-based monitoring functions are portable for any architecture that can host the JVM version 2. ResourceManager exploits JNI to integrate monitoring functions implemented as native libraries for different platforms (WindowsRM DLL on Microsoft Windows NT 4.0, SolarisRM SO on SUN Solaris 2.7, and LinuxRM SO on SuSE Linux 6.2). At run-time the ResourceManager class transparently loads the correct native library for the current monitored target, thus providing MAPI users with the required platform independence.MAPI provides the set of monitoring methods reported in Figure 3. They return concise monitoring parameters to summarize the current state of all resources on the local host. The MAPI intrusion can be tuned to service-specific time requirements: all MAPI methods have amsec invocation parameter that indicates the millisecond interval of invoking native libraries and of refreshing indicators about the collected JVMPI events.package res;public class ResourceManager{String getOS(); // current operating system ProcessInfo[] getProcessInfo(long msec);ProcessInfo getProcessInfo(int pid,long msec);ThreadInfo getThreadInfo(Thread thread,long msec);NetworkInfo getNetworkInfo(long msec);FileSystemInfo[] getFSInfo(long msec);FileSystemInfo getFSInfo(int pid,long msec); }public class ProcessInfo{int pid; // Process IDString name; // Namefloat cpu; // %CPUlong time; // CPU timelong physMem; // Physical memorylong virtMem; // Virtual memorylong totalMem; // Total phys. memoryThreadInfo[] thread;} // Thread infopublic class ThreadInfo{int tid; // thread idfloat cpu; // %CPUlong time;} // CPU timepublic class JavaThreadInfoextends ThreadInfo{Thread thread; // thread objectint classLoad; // # loaded classes int monContended; // # monitorsint objAlloc; // # objectsint objLiveAlloc; // # live objectsint objSize; // heap allocationint objLiveSize; // live heap alloc.int methodCall; // invoked methodsint tcpRead; // TCP read opsint tcpWrite; // TCP write opsint udpReceive; // UDP read opsint udpSend; // UDP write opslong time;} // life timepublic class NetworkInfo{int udpPackIn; // # UDP packets in int udpPackOut; // # UDP packets out int udpPackInErr; // # UDP errorsint tcpConn; // # TCP connections int tcpSegIn; // # TCP segments in int tcpSegOut; // # TCP segments outint ipPackIn; // # IP packets inint ipPackOut; // # IP packets out int ipPackInErr; // # IP errors}public class FileSystemInfo{Int pid; // process IDString name; // process Namelong available; // total FS avail.float available%; // as above, perc.FileInfo[] openFiles;}public class FileInfo{String absFileName;// abs. file namelong time; // time from openingint modalities;// 0 only reading,// 1 only writing, 2 both int readOps; // # read ops in session int writeOps;// # write ops in session }Figure 3. The ResourceManager class interface.MAPI methods return an object (or an array of objects) of the three classes ProcessInfo, NetworkInfo, and FileSystemInfo. The ProcessInfo object maintains all data related to the current pid process. Monitored data include the CPU usage (percentage and total time) for any specified process, its allocated memory (physical and virtual), and miscellaneous information on its composing threads. It is possible also to obtain additional data about the threads possibly contained in a process. In case of JVM threads (e.g., when monitoring SOMA agents), the tool collects data about the reference to the Java thread object, the number of loaded classes, used monitors, allocated objects, invoked methods, and network operations. For non-Java threads, MAPI provides the thread identifier and the percentage/effective time of CPU usage.The NetworkInfo class reports aggregated data about the utilization of the communication infrastructure in the target host. Monitored data include the total number of sent/received UDP/IP packets, of TCP connections and sent/received segments, and of received UDP/IP packets with errors. These parameters are useful to evaluate the traffic and to identify congestion situations in the network locality of the monitored host.Finally, the FileSystemInfo class maintains information about the file system of the target (disk free space and its percentage on total size) and, in particular, about currentlyopened files: for any active process and for any file opened in the current session, the class can return the opening time, its opening mode (read/write/both/locked), and the number of read/write operations.4Distributed Monitoring and Control of SOMA AgentsThe MAPI component exploits several on-line monitoring indicators to control the operations of all SOMA local agents. In addition, mobile agents act as distributed components over distributed systems, and they are the solution to monitor and control the distributed state of resource consumption. For instance, a service administrator can enforce policies involving a set of distributed resources, e.g., "the total CPU time per day consumed by all SOMA agents of principal A is lower than xxx sec".We are working on the implementation of this distributed monitoring and control of SOMA agents. We have designed and implemented two types of SOMA agents (monitoring managers and monitoring slaves), both employing MAPI functionality. Each slave agent monitors all SOMA agents running on one target, while the manager agent commands the slaves, puts together their local monitoring data and presents the results to system administrators. We currently use one manager agent to coordinate all slave agents running on the hosts of one administered region. Administered regions can coincide with a local area network or can include different (possibly overlapping) network localities. Slave agents are considered common monitoring facilities, and different authorized managers can command the same slave agent if regions overlap (see Figure 4).From the point of view of inter-agent communication, slave and manager agents can exchange monitoring information and control commands by using the SOMA communication service. The current implementation exploits only asynchronous non-blocking messages sent over either secure or insecure channels (in case of trusted controlled region). Message exchange permits to implement both polling monitoring strategies (manager agents command slaves to return the current value of specific monitoring indicators), and trap-based monitoring strategies (slave agents communicate the overcoming of a predefined threshold to their managers).Any manager agent collects on-line monitoring information in its controlled region, and coordinates the operations of slave agents. In particular, it asks them to gather specific monitoring data, with specified alert thresholds and update frequencies, and can also command slave behavior. In addition, a manager can create new monitoring slaves at run-time to migrate to new targets entering the administered region.Slave agents observe the state of JVM and OS resources by invoking the local MAPI component. Slave agents aggregate and filter monitoring data on their local targets, by calculating even complex health functions. They permit to significantly reduce the network monitoring traffic [8], and autonomously perform local management operations without manager/administrator intervention.We have two types of monitoring slaves: the JVMPISlave and the JNISlave agents. The JVMPISlave agent perform autonomous operations to control and manage agent threads, by exploiting MAPI to obtain JavaThreadInfo monitoring data. It can modify the agent priority and can force agent suspension/termination. For instance, a JVMPISlave agent can control the local memory occupation, and if any agent thread exceeds a specified threshold, it can alert its manager or even terminate the responsible thread if required by the enforced management policy. Any JVMPISlave can tune dynamically the introduced overhead by enabling/disabling the notification of specific kinds of events. In addition, it can modify the frequency to refresh monitored data at runtime.The JNISlave agent is in charge of invoking the MAPI native functions, not only to collect OS resource data, but also to allow local management of non-Java processes. In particular, the JNISlave can yield back the monitoring information organized in NetworkInfo ,FileSystemInfo , and a part of ProcessInfo classes (excluding the JavaThreadInfo one). In addition, similarly to the JVMPISlave, the JNISlave agent can be launched with alert thresholds that the responsible Manager is authorized to modify dynamically: when thresholds are exceeded, the agent can either notify its Manager or take autonomous corrective operations. The JNISlave agent allows the dynamic tuning of the sampling frequency for monitoring data. If the JVMPISlave sample time represents only the refresh interval (JVMPI events are continuously notified, independently of the sampling frequency), the JNISlave sample time represents the interval between successive invocations of the native monitoring functions.The definition and implementation of a unique MAPI is an important contribute towards design simplicity and usability. However, the provision of differentiated JVMPISlave and JNISlave agents is motivated by a clean separation of JVMPI-based subset of monitoring functions. These functions make possible a partial monitoring of also the targets that do not support yet an implementation of the MAPI native monitoring methods (such as HP-UX workstations and PalmOS personal digital assistants).MonitoredLocal Area Network B Local Area Network ALocal Area Network CLocal Area Network DMonitored Region 2JVMPISlaveJNISlave JNI Slave JVMPIJNI Slave JNISlaveSlave JNISlave agent Manager modSampleTime()Figure 5. Manager and slave monitoring agents for the distributed control of SOMA agents.5 Lessons Learned and Directions of Future WorkThe initial tests in controlling resource consumption of SOMA agents have shown, on the one hand, the feasibility of Java-based on-line monitoring, and, on the other hand, the necessity to enable the dynamic tuning of the monitoring overhead by adjusting both the sample frequency and the set of collected data. In normal working conditions, all tests show that monitoringSOMA agents causes a negligible overhead when the sample frequency goes under 0.35 Hz [9].Notwithstanding the encouraging results obtained, much work is still to be done to achieve a complete and flexible control of SOMA agent resource consumption. We are currently working at:experimenting different strategies of distribution for slave and manager agents, possibly related to the topology of networks where SOMA agents operate. We are testing (and evaluating the performance of) solutions with different numbers of managers/slaves for each controlled region/host, even allowing manager agents to be organized hierarchically; defining flexible policies to express distributed state control thresholds, and actions to be performed at their overcoming.References[1]G. Vigna (ed.), Mobile Agents and Security, Lecture Notes in Computer Science, Vol. 1419,Springer Verlag, 1998.[2] A. Corradi, M. Cremonini, R. Montanari and C. Stefanelli, "Mobile Agents Integrity forElectronic Commerce Applications", Information Systems, Special Issue on Information Systems Support For Electronic Commerce, Elsevier, Vol. 24, No. 6, 1999.[3]M. Vandenwauver, R. Govaerts and J: Vandewalle, "Role-based Access Control in DistributedSystems", IFIP Working Conf. Communications and Multimedia Security, 1997.[4]Sun Microsystems - Java Virtual Machine Profiler Interface (JVMPI), /products/jdk/1.3/docs/guide/jvmpi/jvmpi.html.[5]R. Gordon, Essential Java Native Interface, Prentice Hall, 1998.[6]P. Bellavista, A. Corradi and C. Stefanelli, "Protection and Interoperability for Mobile Agents:A Secure and Open Programming Environment", IEICE Transactions on Communications,IEICE/IEEE Special Issue on Autonomous Decentralized Systems, E83-B(5), 2000.[7]P. Bellavista, A. Corradi and C. Stefanelli, "An Integrated Management Environment forNetwork Resources and Services", IEEE Journal on Selected Areas in Communication, Special Issue on Recent Advances in Network Management and Operations, 18(5), 2000.[8] D. Gavalas, M. Ghanbari, M. O’Mahony and D. Greenwood, "Enabling Mobile AgentTechnology for Intelligent Bulk Management Data Filtering", IEEE/IFIP Network Operations and Management Symposium (NOMS), USA, 2000.[9]P. Bellavista, A. Corradi and C. Stefanelli, "Java-based On-line Monitoring of HeterogeneousResources and Systems", 7th Workshop HP OpenView University Association, Greece, 2000.。