Monitor and Control of Mobile Agent Applications

Transcription

1 Monitor and Control of Mobile Agent Applications Paolo Bellavista, Antonio Corradi Dipartimento di Elettronica, Informatica e Sistemistica, Università di Bologna Viale Risorgimento, Bologna - Italy Ph.: Fax: {pbellavista, acorradi}@deis.unibo.it Cesare Stefanelli Dipartimento di Ingegneria, Università di Ferrara Via Saragat, Ferrara - Italy Ph.: Fax: cstefanelli@ing.unife.it Abstract Mobile 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 to monitor 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 and technologies to achieve full visibility of the state of both Java and platformdependent resources from within the Java Virtual Machine. 1 Introduction Notwithstanding 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"). 1

2 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 () [4] exports several JVM internal events for debugging and monitoring purpose, while the Java Native Interface () [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 to collect several applicationlevel events produced by Java applications (e.g., object allocation and method invocation). In addition, it employs the technology to make possible the integration with platformdependent native monitoring mechanisms, that we have currently implemented for Windows NT, Solaris and Linux. 2 Technologies for On-line Monitoring of Java-based Mobile Agents We 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 2

3 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 and technologies to extend the visibility achievable from within the JVM. can help in monitoring and controlling the consumption of Java resources. is an experimental interface featured by the Java 2 platform and mainly designed to help developers in the debugging of Java applications. 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). is the standard way to invoke platform-dependent code with visibility of OS resource state within the standard JVM. 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 to call the requested function in the native library during the execution. 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), 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. 3 Local Monitoring and Control of SOMA Agents SOMA 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. 3

4 SOMA-based Applications Multimedia Distribution Information Retrieval Systems Management SOMA Middleware Services Migration Security Interoperability Control/ Management MAPI Naming Communic. Monitoring Java Virtual Machine Heterogeneous Distributed System Figure 1. The modular service architecture of the SOMA platform. MAPI 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 events on-line, to offer concise monitoring indicators during service execution. The -based monitoring functions are portable for any architecture that can host the JVM version 2. ResourceManager exploits 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. Monitoring Application Programming Interface (MAPI) Resource Manager class MAPI NT ResManager class MAPI SVR4 ResManager class MAPI Linux ResManager class MAPI Profiler Agent JVM Profiler Interface Java Virtual Machine Java Native Interface MAPI WindowsRM DLL MAPI SolarisRM SO MAPI LinuxRM SO Windows NT OS Solaris OS SuSE Linux OS Figure 2. The architecture of our Java-based MAPI. 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 a 4

5 msec invocation parameter that indicates the millisecond interval of invoking native libraries and of refreshing indicators about the collected 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{ public class NetworkInfo{ int pid; // Process ID int udppackin; // # UDP packets in String name; // Name int udppackout; // # UDP packets out float cpu; // %CPU int udppackinerr; // # UDP errors long time; // CPU time int tcpconn; // # TCP connections long physmem; // Physical memory int tcpsegin; // # TCP segments in long virtmem; // Virtual memory int tcpsegout; // # TCP segments long totalmem; // Total phys. out memory int ippackin; // # IP packets in ThreadInfo[] thread;} // Thread info int ippackout; // # IP packets out int ippackinerr; // # IP errors public class ThreadInfo{ } int tid; // thread id float cpu; // %CPU public class FileSystemInfo{ long time;} // CPU time Int pid; // process ID String name; // process Name public class JavaThreadInfo long available; // total FS avail. extends ThreadInfo{ float available%; // as above, perc. Thread thread; // thread object FileInfo[] openfiles; int classload; // # loaded classes } int moncontended; // # monitors int objalloc; // # objects public class FileInfo{ int objlivealloc; // # live objects String absfilename; // abs. file int objsize; // heap allocation name int objlivesize; // live heap alloc. long time; // time from opening int methodcall; // invoked methods int modalities; // 0 only reading, int tcpread; // TCP read ops // 1 only writing, 2 both int tcpwrite; // TCP write ops int readops; // # read ops in session int udpreceive; // UDP read ops int writeops;// # write ops in session int udpsend; // UDP write ops } long time;} // life time 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 currently 5

6 opened 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. 4 Distributed Monitoring and Control of SOMA Agents The 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. 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. agents observe the state of JVM and OS resources by invoking the local MAPI component. 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 and the agents. The 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 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 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. 6

7 The 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 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, the 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 agent allows the dynamic tuning of the sampling frequency for monitoring data. If the sample time represents only the refresh interval ( events are continuously notified, independently of the sampling frequency), the 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 and agents is motivated by a clean separation of -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). Local Area Network B stopagent() Local Area Network C modsampletime() modthreshold() yieldresults() Local Area Network A Local Area Network D Monitored Region 1 Monitored Region 2 Manager agent agent agent Figure 5. Manager and slave monitoring agents for the distributed control of SOMA agents. 5 Lessons Learned and Directions of Future Work The 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 monitoring 7

8 SOMA 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, [2] A. Corradi, M. Cremonini, R. Montanari and C. Stefanelli, "Mobile Agents Integrity for Electronic Commerce Applications", Information Systems, Special Issue on Information Systems Support For Electronic Commerce, Elsevier, Vol. 24, No. 6, [3] M. Vandenwauver, R. Govaerts and J: Vandewalle, " Role-based Access Control in Distributed Systems", IFIP Working Conf. Communications and Multimedia Security, [4] Sun Microsystems - Java Virtual Machine Profiler Interface (), products/jdk/1.3/docs/guide/jvmpi/jvmpi.html. [5] R. Gordon, Essential Java Native Interface, Prentice Hall, [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), [7] P. Bellavista, A. Corradi and C. Stefanelli, "An Integrated Management Environment for Network Resources and Services", IEEE Journal on Selected Areas in Communication, Special Issue on Recent Advances in Network Management and Operations, 18(5), [8] D. Gavalas, M. Ghanbari, M. O Mahony and D. Greenwood, "Enabling Mobile Agent Technology for Intelligent Bulk Management Data Filtering", IEEE/IFIP Network Operations and Management Symposium (NOMS), USA, [9] P. Bellavista, A. Corradi and C. Stefanelli, "Java-based On-line Monitoring of Heterogeneous Resources and Systems", 7 th Workshop HP OpenView University Association, Greece,