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
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.
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
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 context-
switching 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 ‘code-
repository’. 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.
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
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
 • Checking that the script is run in the 2.10 Summary Table
appropriate environment or area.
Product Context Persistence Languages
Switching
• Verifies that target script has no Name
Supported
Supported Supported
vulnerabilities. FastCGI No Yes Various
CGIWrap Yes No Various
• Performs ‘chroot’ operation to the
SuExec Yes No Various
directory that contains the target script
and authors other files i.e., HTML files. Mod_PHP No Yes PHP
SpeedyCGI Yes Yes Perl
• Sets the limit for a target script’s SBox Yes No Various
resource usage i.e., CPU, disk and Java Servlets No Yes Java
memory usage.
Table 2

• 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.
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
3.1.1 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 Web-
server 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
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.
• 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.
3.1.3 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
during each benchmark. An example could
be the total time taken to produce a
response for a given test request.
3.2 System Overview
3.2.1 Key Features of System
The key features of our X-Switch system are
listed below and summarised in Figure 2:
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.
3.2.2 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

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.
3.2.3 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.
3.2.4 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
3.3.1 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.
3.3.2 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
3.4 Impact
3.4.1 Impact of a ‘universal’ Web server
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
3.5.1 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.
3.5.2 Evaluation techniques
The following evaluation techniques will be
used:
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
 required to perform the required functions
must be included.
3. Definition of PHP and Servlet Engines:
The run-time environment for a language-
interpreter 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 4.
9. 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 4.
4.4 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
5. References

1. Apache Software Organisation., 2004, Apache suEXEC Support Technical Document.

Available at: http://httpd.apache.org/docs-2.1/suexec.html.
(Accessed 2 July 2004)

2. Sun Microsystems. 2003. The Java Servlet API: White Paper.

Available at: http://java.sun.com/products/servlet/whitepaper.html
(Accessed 20 July 2004)

3. Open Market Inc. 1996. FastCGI: A high performance Web server interface.
Available at: http://www.fastcgi.com/devkit/doc/fastcgiwhitepaper/fastcgi.htm
(Accessed 21 July 2004)

4. Knambatti, M. 2001, Named pipes, sockets and other IPC. Technical Report, Arizona State University.

5. Stein., L., 2003. 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, 1999.

7. Coar., K., 2000. suExec and Apache: A tutorial, Apache Software Foundation.
Available at: http://www.serverwatch.com/tutorials/article.php/10825_1126991_1
(Accessed 29 July 2004)

8. Horrocks, S. 2003, Speedy CGI.

Available at: http://daemoninc.com/SpeedyCGI/
(Accessed 31 July 2004)

9. Sun Microsystems. 1999. The Java’s security architecture.

Available at: http://java.sun.com/j2se/1.3/docs/guide/security/spec/security-spec.doc1.html.
(Accessed 28 July 2004)

9
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 18-22 October
15. Final project demonstration 8-12 November

10
Chart 1:

11