Universal Web Server for Web Service Components

Transcription

1 Universal Web Server for Web Service Components Proposal Submitted to the Department of Computer Science University of Cape Town By Reinhardt van Rooyen and Andrew Maunder August 2004

2 1. Introduction and Background 1.1 Introduction Over the last ten years, the Web has rapidly grown to the extent where all businesses and organisations, no matter how large or small, desire some sort of Web presence. The Web page might contain completely static content that only changes when updated by the Web page administrator. The most recent approach is to allow a Web page to show different content in response to the type of requests sent to the Web server. This is described as a page containing dynamic content. Figure 1 shows a typical situation where a Web browser formulates a request message according to the relevant action performed by a user and sends that request to a Web server. The Web server then routes the request message to the applicable server application. The request is analysed and a response message is generated. This message is sent back to the Web browser for display. The Web server application could be a PHP, Perl or ASP script, Java servlet or any other server application. Web servers run as nobody, which means that the Web server processes run with very few privileges this includes access to users data. The reasoning behind this technique is that if the security of the Web server is compromised, the resultant rogue processes will not be able to access any other files on the server. The security of the rest of the system is ensured. Running the Web server as nobody does not provide a useful solution to the contextswitching problem. Processes created by a Web server running as nobody may only access globally accessible files. In a multi-user environment, such as a university Web server, it is not desirable to store users source code files in a single coderepository. It is even less desirable to have all files in a single repository and to set them to be globally accessible. Any process running on the server has the opportunity to modify and even destroy such files. 1.3 Multiple Language Support Various Web application languages and toolkits are currently available for server side development. The most popular of these being PHP, ASP and Java Servlets. A modern Web servers instance is unable to support all the language modules available. Many modules require modifications to be made to the server configuration, resulting in incompatibilities with other language modules. 1.4 Market Survey A small survey of popular, local Web hosts revealed a number of interesting facts about the services that they provide. These services are summarised in table 1. Figure 1: A typical Web server interaction 1.2 Context Switching Current Web servers primarily utilise a single directory to store application code; a common example is the cgi-bin directory of the Apache Web server. All code, such as Perl or CGI scripts, are stored in that single directory, irrespective of who the owner of the script is. A serious problem arises from this single code-repository scheme. In order for a Web server process to access the required piece of code, the process must have the appropriate access rights to be able to read or write the source code. Unfortunately most Unix based Host Name Services Provided WebOnline PHP on high end packages, no Java Servlet or JSP support Afrihost Java Servlet support with dedicated personal Tomcat server, PHP support with access to MySQL database. Circular No Java Servlet or JSP support, PHP Systems support with access to a MySQL data base. DigitalHost No Java Servlet or JSP support, PHP support available Table 1 The results confirm our statement that many Web hosts still provide support for a limited number of development languages. Further investigation revealed that a quarter of the hosts provided PHP without Java Servlet support. Those that did support both languages did so by providing a private instance of a 2

3 Tomcat server that would service all Servlet requests. Our project will investigate the possible reasons for the lack of concurrent support for Java Servlets and PHP. We will propose a secure architecture that will solve the support problem and provide test results that prove that the performance of the proposed system is comparable with previous systems. 2. Previous or Related Work 2.2 The Common Gateway Interface (CGI) The Common Gateway Interface (CGI)[3] provides a standard interface for Web applications to receive requests and pass application-generated responses back to the calling Web server. CGI provides many benefits, which include: Simplicity of the CGI commands. CGI applications can be written in any programming language CGI applications run in a separate process from that of the Web server, thus isolating the Web server processes from dangerous CGI processes. CGI applications can run on a variety of Web server architectures. There are some inherent problems with the CGI mechanism. Most importantly, the performance of CGI applications running on the Web server is poor. A new process is started to handle each request for a CGI application. Once an appropriate response has been generated, the CGI application process is destroyed. The excessive process initialisation overhead makes the CGI mechanism unacceptable for high performance Web servers. 2.3 FastCGI FastCGI[3] provides a fast, open and secure Web server interface that solves the performance problems that are inherent in CGI, without introducing the overhead and complexity of proprietary API s. The FastCGI interface provides many of the benefits provided by CGI, such as process isolation, language and architecture independence. The persistence of FastCGI processes is one of the major advantages it possesses over the traditional CGI system. 2.4 CGIWrap CGIWrap[5] is a wrapper script that allows a server to execute non-trusted (i.e. the script was not made by the Web-master or employee) scripts in a controlled, limited environment. The wrapper provides the following functions. The process executing the script has the same privileges as the owner of the script. Resource ceilings are set to limit the resources used by a script to protect Web server. Auditing trail that leads directly to faulty scripts. The wrapper is suid to root and can therefore change its process ID to match that of the script it must run. This is desirable as now an non-trusted script will be run with no privileges but a highly trusted script (i.e. one written by the host system Web programmer) will allowed to run with much greater privileges. 2.5 Sandboxes The sandbox[9] security model is allows a system to run non-trusted scripts and programs in an isolated environment. The sandbox idea is analogous to a quarantined area during the outbreak of a disease. A subject leaving the infected area is detained in the quarantined area so that the medical staff can monitor them to see if they show any symptoms of the disease. In a similar way the server can create a restricted area where the script or program may run, thus restricting the parts of the system that the script can access. The server can then monitor the actions of the script during execution, providing it with limited CPU time and memory. If the script is found to be malicious, the resultant damage to the system will be minimal. Sandboxes are currently part of the Java Security Model.[9] 2.7 Secure Box (SBox) The SBox[5] system takes the CGI wrapper idea a bit further. It creates a restricted area for the target script s process to exist. The script that is possibly infected with a bug or dangerous error, is kept in one place and only has access to the files in the quarantined area. The SBox system can perform the following operations: 3

4 Checking that the script is run in the appropriate environment or area. Verifies that target script has no vulnerabilities. Performs chroot operation to the directory that contains the target script and authors other files i.e., HTML files. Sets the limit for a target script s resource usage i.e., CPU, disk and memory usage. Lowers the priority of the target scripts process. Runs the target script. 2.8 SpeedyCGI SpeedyCGI[8] is a persistent Perl interpreter that was introduced to attempt to reduce the cost of starting a new process every time a request is received. The Perl process does not exit or die once a request has been serviced, the SpeedyCGI system attempts to prolong the lifetime of the process and thereby allow it to service further requests. 2.9 suexec The Apache research group developed the suexec[7] feature for their Apache Web server and introduced it with Apache version 1.2. suexec allows Apache users to run CGI scripts/programs under user IDs that are different from the user ID of the calling Web server. Without the use of suexec, the CGI script/program will run under the same user ID as the Web server, typically this ID is nobody. Apache spawns a child process that executes the suexec binary and then passes the scripts details to it. The suexec process then edits its environment variables so as to create an appropriate environment for the process to execute in. Finally, the script executes in this environment. Their solution hinges on the use of the UNIX setuid and setgid commands to create suexec, which is considered as a setuid wrapper program Summary Table Product Context Persistence Languages Name Switching Supported Supported Supported FastCGI No Yes Various CGIWrap Yes No Various SuExec Yes No Various Mod_PHP No Yes PHP SpeedyCGI Yes Yes Perl SBox Yes No Various Java Servlets No Yes Java Table 2 A viable solution to these problems would have to provide three essential features, they are: support of context switching, persistence of processes and the support of any development language. Table 2 clearly shows that there is currently no all-encompassing solution that provides all the features described above. Our research team will attempt to design and implement a system that will provide support for all three essential features. 3. Project Overview Investigation We propose the development of a universal Web server that provides a secure, language neutral platform for the execution of Web server components. Such a project would have to address some very relevant issues. These have been alluded to in previous sections and can be summarised by the following: 1. Is it possible for a single Web-server instance to service all Web components hosted on the system, irrespective of their implementation language? 2. Can a Web-server or subset of the Webserver system perform a context-switch that will allow server scripts to be run with the same privileges as the script owner? 3. Is it feasible to create an instance of a language interpreter that handles requests for a specific user-context? 4. Will it be possible to provide script isolation whereby malicious scripts are prevented from accessing and possibly damaging other scripts. 5. Can the resources allocated to script processes be strictly controlled? 4

5 3.1.2 Importance A single, universal Web server is beneficial for the following reasons. Increased security: Only a single Web server needs to be running on a server machine, thereby limiting the access points to the system. The advanced security framework provides script isolation and access control, thus ensuring heightened protection of system and user files. during each benchmark. An example could be the total time taken to produce a response for a given test request. 3.2 System Overview Key Features of System The key features of our X-Switch system are listed below and summarised in Figure 2: Simplicity of deployment: The ability to place a Web component, written in any language, into a user s personal directory and have the server find and execute it. No changes to coding style: The user will not have to add additional lines of code to his script or program to ensure system compliance Methods The following provides an overview of the approach to be taken: Identify the attributes of existing solutions that enable it one to solve a subset of the problem domain. This could be done by a code step-through or the creation of complex test cases to identify the shortcomings of the existing products. Construction of a framework and protocol that will allow a request message to be routed from the Apache Web server to the main modules. A context switch must be performed before any interpreter processes are created. The context-switching module should be able to read the ID of the requested program or script and then perform the switch. The subsequent process will have exactly the same privileges as the owner of the script. Once the process has been created, it should remain persistent to service any subsequent requests for it. A load-balancing module must manage the life-cycle of the persistent objects to ensure that every program or script has sufficient processes to handle its requests. Any process that remains idle for a prolonged period should also be destroyed. Existing systems will be tested for the establishment of performance benchmarks. The system can then be accurately evaluated according to its performance Figure 2: Proposed system design Addition of a unique Apache module to route all PHP and Java Servlet request to the context-switch module. Creation of a context-switching module that is decoupled from the Apache Web server. A persistent process manager that caters for a multi-user environment thus ensuring efficient load balancing. Modular script engines to be created that will provide a well-defined interface for reliable control as well as a robust framework to aid future integration of additional language interpreters. A secure framework for process isolation and resource monitoring Design Challenges Context Switch When designing the context switch module (X-Switch) several aspects have to be taken in consideration. Security of module: The X-Switch module must be run as ROOT to enable it to perform the context switch. If the module s security is compromised, the attacker will have access to the whole server system. Initialisation of Processes: Once the context switch has been performed, the appropriate engine process must be initialised to execute the desired script. 5

6 Process Resource Ceiling: A user script must have a limited amount of resources allocated to it. These include CPU time, memory and allocated disk space. Process Isolation: The system should create a sandbox for the script process to run in. The script process will then only have access to the files in its sandbox directory Design Challenges Persistence of Processes Process Re-use: Once the context switch has occurred, the system must ensure that all PHP or Servlet engine processes remain persistent. This allows them to handle subsequent requests for the same script Design Challenges Load Balancing Number of processes: The X-Switch system should be able to dynamically increase the number processes available in a particular context. This is desirable if the number of requests for a particular script increases. Termination of Processes: Once the number of requests for a particular script decreases the X-Switch module should terminate the unused processes to free up the resources they utilised. 3.3 Proposed System Design Design Considerations The Apache module: The Apache Web server is the most widely used Web server at present. In addition, the source code is freely available thus ensuring the availability of an extensive knowledge base of related uses, errors and technical material. Apache provides a modular design strategy that allows seamless integration of functional units. Inter process communication (IPC): Effective communication is essential for modular interoperability. We will investigate the two most popular mechanisms of IPC. The first being the Unix named pipe. This is a FIFO (first in, first out) file that can be opened and messages placed inside it by the creator process. The consumer process then reads or consumes the data from the pipe. The procedure works in the opposite direction as well (duplex). The alternative to named pipes is the use of TCP/IP sockets. A socket can be seen as the end point for IPC. The TCP/IP protocol provides a reliable, connection orientated communication channel that is bound to the socket. A client can then read from or write to the socket. IPC is necessary in two distinct areas of the X- Switch system. Firstly it is required between the Apache Web server module and the X- Switch module. Secondly it is required between the X-Switch module and the script engines. An investigation will highlight any performance differences that exist between the two approaches and attempt to apply the technique that is best suited to our requirements. Key factors include communication overhead and scalability. X-Switch Module: The X-Switch module can be seen as the middle tier of the system. The module can therefore successfully act as a request routing intermediary. Secondly but more importantly, the X-Switch module will need to provide a context switching facility that permits the PHP or Servlet engine processes to be executed under a different ID from that of the Web server. Script Engine: The script engine design will follow a suitable modular pattern and implement a well-defined interface. The interface will provide the required interoperability between the X-Switch module and the engines. Each engine will be required to initiate its interpreter process and then provide the appropriate process I/O and resource management. The initial system will provide engine modules for handling requests for popular PHP and Java Servlet Web programming languages Resources Required The following equipment will be required: Unix/Linux based server PC with ROOT access, capable of running PHP and Java interpreters as well as the Apache Web Server. Linux/Windows 95/98/2000/XP client PC with a Web compatible browser. The following software resources will be required: Apache Web Server. Java interpreter. PHP interpreter. A standard Java interpreter and compiler. A standard C compiler. 6

7 3.4 Impact Evaluation techniques Impact of a universal Web server The following evaluation techniques will be used: The concept universal Web server provides a system that allows a user to deploy a Web component quickly and easily. A secure server process with identical access rights as the user, interprets the component source code. This ensures the user that no other process can read, write or destroy his scripts. A universal Web server will require only a single instance to service requests for Web applications implemented in any language. 3.5 Evaluation of system Success factors The success of the project will be evaluated according to following criteria: Simplicity of script deployment: The user should be able to place his scripts into his own personal directory on the server disk. The X- Switch system should automatically find and execute the script when needed. There should be no need for additional deployment details or script code. Thus if a script executes correctly on the user s development system, it should do the same on the X-Switch server system. Co-Existence of sandboxes: A script should be executed by a process with identical access rights as the script owner. If a script is placed in a personal sandbox, the script processes will not be able to access files in other sandboxes. Co-existence of sandboxes ensures file security on a multi-user, Web server system. Response Time of System: The viability of the X-Switch project hinges on the response time of the system. Should the X-Switch system perform better than previous systems (see section 2), the project will be considered highly successful. Each task will have a minimum required response time allocated to it. Security of Web Server and Script Processes: An important component of the project is Web server security. Successful context switching and process isolation will limit the accessible domain of any script, thus rendering all system files inaccessible. Benchmarking: Performance benchmarks may be established by testing the existing products, discussed in Section 2, with a variety of input data. The product, input data and the resultant data must be well documented to allow for experiment replication and comparison. The input data should test all the functionality of the system, from normal operations to extreme conditions. The test data documented will be used as input to our system and the results captured. Accurate replication of the experiments will ensure that our results are comparable un-biased. The proposed benchmarks will evaluate the following: 1. System performance when multiple clients attempt to access the same script. Will the system balance the uneven load effectively? 2. System performance when there are many clients attempting to access different scripts simultaneously. Can the system service each request within a reasonable time frame? 4. Implementation Plan 4.1 Time Line See Time Line 1, Appendix A 4.2 Deliverable Items See Table 3, Appendix A 4.3 Milestone Descriptions and Completion Criteria 1. Definition of Interfaces and Communication Protocols: The modular interfaces are defined, according to final system-architecture designs. The runtime, data flow of the system plays a major role in determining the operations that will need invocation. Interface structure is inherited from the operational information collected. Finally, a communication protocol must define the messages required for modular communication. 2. Definition of Context Switching and Apache Module: The functional roles of the Apache and context switching modules are finalised. Pseudo-code depicting the methods and operations 7

8 required to perform the required functions must be included. 3. Definition of PHP and Servlet Engines: The run-time environment for a languageinterpreter process is defined, including initialisation variables, resources and process I/O handling. 4. Creation of modular testing framework and synthetic data generators: Modular test cases are constructed, including documentation of the correct result sets. Sample data generators are to be used to synthesise modular data flow for testing purposes. This also allows for protection against the delayed completion of a critical module. Testing is permitted to continue by using the synthesised data sets. 5. Implementation of Interfaces and Protocols: The final coding of the interfaces and protocols has taken place. White box testing must be performed by the programmer and the results documented. 6. Implementation of Context Switching and Apache Module: The final coding of the context switching and Apache modules has taken place. White box testing must be performed by the programmer and the results documented. 7. Implementation of PHP and Servlet Engines: The final coding of the context switching and Apache modules has taken place. White box testing must be performed by the programmer and the results documented. 8. Testing of individual modules: Black box testing of each module is performed. The results are compared to the documented results collected during the completion of section Testing of complete system: The complete system is assembled and documented test cases are applied. The results are compared to the result sets obtained in section Task Allocation The task allocation plan for the project is derived from the system structure. Below is a listing of the group member followed by the system component name together with the set of tasks associated with it. Interface Definitions: The first task will be for the project members to define the modular interfaces and the format of the messages to be passed between them. This will allow test data generators to be created before the implementation of the modules occur. Member name: Andrew Maunder The Apache module: Apache module research, design of module, definition of module interfaces, implementation of module, module testing and implementation of simulation data sets to prevent project. Protocol implementation: Identification of messages required, protocol design, protocol implementation, data-marshalling. Servlet engine integration: Researching PHP interpreter operation, process environment management, process I/O handling and resource usage. Apache module and Servlet engine testing and validation: Creation of test cases and result sets, development of synthetic test data generators, white and black box module testing, black box system testing. Finally, benchmark tests will be applied to the system to establish whether its performance falls within an acceptable range. Member name: Reinhardt van Rooyen Context switch (X-switch) module: Research of Unix process management, context switching, access control, module design and implementation, load balancing schemas including process life-cycle control. PHP Engine Integration: Researching PHP interpreter operation, process environment management, process I/O handling and resource usage. Context switch and PHP engine testing and validation: Creation of test cases and result sets, development of synthetic test data generators, white and black box module testing, black box system testing. Finally, benchmark tests will be applied to the system to establish if its performance falls within an acceptable range. Module failure action plan: Test data synthesis: The well-defined modular interfaces allow separate test data generators to simulate the correct data output of a failed module. 8

9 5. References 1. Apache Software Organisation., 2004, Apache suexec Support Technical Document. Available at: (Accessed 2 July 2004) 2. Sun Microsystems The Java Servlet API: White Paper. Available at: (Accessed 20 July 2004) 3. Open Market Inc FastCGI: A high performance Web server interface. Available at: (Accessed 21 July 2004) 4. Knambatti, M. 2001, Named pipes, sockets and other IPC. Technical Report, Arizona State University. 5. Stein., L., sbox: Put CGI scripts in a box. Technical Report, Cold Spring Harbour Laboratory. 6. Laurie B., and Laurie P., Apache: The definitive guide. O Reilly, Sebastopol, CA, Coar., K., suexec and Apache: A tutorial, Apache Software Foundation. Available at: (Accessed 29 July 2004) 8. Horrocks, S. 2003, Speedy CGI. Available at: (Accessed 31 July 2004) 9. Sun Microsystems The Java s security architecture. Available at: (Accessed 28 July 2004) 9

10 7. Appendix A: Table 3 Deliverable Item Description Date (2004) 1. Project Proposal Completed 5 August 2. Presentation & Web Page Completed 12 August 3. Project Commences 16 August 4. Report: Definition and theory (Background) 27 August 5. Report: Chapter on Design 16 September 6. First Implementation Running 25 September 7. Evaluation of first implementation 25 September 8. Report: Evaluation and Testing 5 October 9. Paper: First Draft 6 October 10. Report and Poster: First Draft 8 October 11. Final paper hand in 13 October 12. Final Report hand in 15 October 13. Poster hand in as well as Web site updated with project outcome 15 October 14. Project demonstration to project supervisor and second reader October 15. Final project demonstration 8-12 November 10

11 Chart 1: 11