DESIGN AND IMPLEMENTATION OF A WEB SERVER FOR A HOSTING SERVICE Daisuke Hara, Ryota Ozaki, Kazuki Hyoudou, and Yasuichi Nakayama Department of Computer Science The University of Electro-Communications Chofu, Tokyo 182-8585 Japan email:
[email protected] ABSTRACT A web server named Harache is presented. The server runs under the authority of the file owner. Existing servers have problems that occur because of the user authority during execution. When a program that uses a server embedded interpreter, for example PHP, creates data files, the owner of the created files is the special user account that runs a server. Therefore, other users that share the same server can steal and delete these data files. In particular, these problems are serious for a hosting service where many users share a server. Harache has server processes that run under the authority of the file owner. Therefore, Harache can solve these problems that occur because of the user authority. Harache can be used for a hosting service where many people share a server with a reverse proxy. We implemented Harache on a Linux OS with SELinux and performed evaluation experiments to test the system’s effectiveness. Experimental results show that Harache has high performance and scalability.
implemented the web server, Harache. Harache can be used for a hosting service where many people share a server with a reverse proxy. Harache has server processes that run under the authority of the file owner [3]. In this way, the owner of files that a PHP program and WebDAV create is each ordinary user account. Thus, other users that share the same server cannot steal and delete the data files of a PHP program. Also, ordinary users can directly edit files that are created by way of WebDAV. Therefore, Harache can solve problems that occur because of the user authority. We implemented Harache on a Linux OS with SELinux and performed evaluation experiments. Experimental results show that Harache has high performance and scalability. The remainder of this paper is structured as follows. Section 2 describes the background of this work. Section 3 describes the key aspects of our design. Section 4 describes an overview of our implementation of Harache on a Linux OS. Section 5 presents an evaluation of Harache. Finally, Section 6 presents conclusions.
KEY WORDS Web and Internet Systems and Tools, Web Servers, User Authority, Privacy
2
1
This section describes the access control on a server and a hosting service. In this paper, “user” indicates a person who creates a website, and “user account” indicates the user account in the OS.
Introduction
People are increasingly creating their own websites as the Internet grows in popularity. A hosting service, where many users share a server, is commonly used. Existing servers have problems that occur because of the user authority during execution. Programs that are embedded in a server run under the authority of a special user account1 that runs the server. When a PHP [1] program creates data files, the owner of the created files is the special user account. Therefore, other users that share the same server can steal and delete these data files. Also, when WebDAV [2] is used, the files’ owner is also the special user account. Actual file owners of an ordinary user account typically cannot edit these files directly. In particular, these problems are serious for a hosting service where many users share a server. In order to combat these problems, we designed and 1 apache,
477-055
Background
2.1
Access Control on Server
Existing servers run under the authority of the special user account (Figure 1). Although running under this authority improves security against outside attacks, it causes harmful effects for users in the server. First, users must grant read permission of publishing files to the special user account2 . That requires granting read permission to an other which is different from an owner or a group. Therefore, other users that share the same server can steal and execute these files regardless of the restricted access by way of the browser. suEXEC [4] and POSIX ACL [5] were proposed to solve this problem. suEXEC executes a CGI under the authority of the file owner of the CGI. By using this module, 2A
www-data, www, etc.
69
CGI additionally requires the execution permission.
Figure 1. Overview of a request processing: existing server
Figure 2. Overview of CGI processing the execution permission for an other becomes unnecessary. Figure 2 shows the overview of CGI processing. Because suEXEC applies steps (2) and (3) in addition to normal CGI processing, overhead is caused. Additionally, suEXEC is not available for stealing text files. POSIX ACL is an access control mechanism at a filesystem level, and it offers control for every user account in addition to the existing owner-group-other permission. By using this mechanism, the permission of read and execution needs to be granted to only the special user account.
2.2
Hosting Service
Generally, networks with a reverse proxy are used for a hosting service applying load distribution. The procedure is as follows. First, requests are received by a proxy server at the frontend. Then, the proxy server redirects requests to the servers at the backend. Finally, the servers return the responses to clients. Actually, static files are cached at the frontend, and the frontend returns responses to the clients directly. Almost all of the redirected requests to the backend are for dynamic files such as a CGI. Throughput should improve by optimizing the servers at the backend in tune with an intended operation.
However, foregoing mechanisms cannot ensure files are secure if the programs that are embedded in a server are used. WebDAV is an extension of the HTTP 1.1 and offers file management on a server from a client program, for example a browser. Also, PHP scripts are usually executed by the interpreter that is embedded in a server not as a CGI. Similarly, embedded interpreters are commonly used as an alternative for a CGI, such as mod perl [6], mod ruby [7] and mod python [8]. However, POSIX ACL has a lack of utility if the programs that are embedded in a server are used because PHP scripts can read published files of an other user if the read permission is granted to the special user account only. PHP scripts run under the authority of the special user account in the same way a server does. Thus, that means other users that share the same server can steal the published files of other users. Also, when a PHP program creates data files, the users must grant write permission to the special user account. Hence, other users that share the same server can steal and tamper with these data files.
In the meantime, the biggest problem of hosting service providers is server footprints at the data center. It is important from a profit standpoint to house many users in a server. The results of this work can be used for a hosting service where many people share a server with a reverse proxy. The mechanism gives priority to scalability of the number of users in the case of processing dynamic files such as a CGI.
3
This work provides an environment where server embedded programs can be used safely in a situation where many people share a server.
Design
This section describes the design of a server we achieved, Harache. It can be used for UNIX-like OSes.
70
the server processes of these users, thus achieving high scalability. Therefore, more users can be housed in the server.
3.3
Harache brings access control into operation with a secure OS. For UNIX-like OSes, the authority of the administrator account is required to change the authority of a process. Thus, Harache’s server processes start under the authority of the administrator account. Because server processes have been changed to the authority of the file owner when processing requests, starting under the authority of the administrator account is not dangerous. However, the authority of the administrator account in internet servers can be taken over because of a security hole and a misconfiguration. Harache solves this problem by granting only the minimum authority to server processes. Therefore, the damage caused by taking over the authority of the administrator account can be minimized.
Figure 3. Overview of a request processing: Harache
3.1
Access Control on OS
Design Principle
We achieved the server, Harache, which solves problems that occur because of the user authority. As §2.1 described, existing servers have problems when server embedded programs are used. Also, as §2.2 described, many users need to be housed in a server for a hosting service to make it profitable. We designed a server that satisfies these requirements with a hosting service where up to 1,000 people share the server with a reverse proxy. One user account in Harache’s OS was assigned to each user of a hosting service. The design principles of Harache are as follows. First, Harache executes server processes under the authority of the file owner, not as a special user account, to solve problems when server embedded programs are used. Second, it terminates unnecessary server processes when needed to improve scalability of the number of users. Third, Harache brings access control into operation with a secure OS [9, 10] to improve security against outside attacks.
4
Implementation
3.2
We used Apache as the foundation for Harache. Apache accounts for about 70% of the servers on the Internet and is the de facto standard [12]. This implementation uses Apache HTTP Server ver. 1.3.33. An Apache module, mod harache, is the core of Harache. It provides the functionality to change the authority of the server processes to the file owner’s. setuid() and setgid() system calls are used to change the authority. Actually, mod harache creates a child process using a fork() system call before changing the authority. This child process changes its own authority and operates request processing. Then, the process is terminated after each session. Thus, it can prevent unaccessed server processes from causing memory shortage. Therefore, Harache is believed that it can achieve high scalability of the number of users.
This section describes the implementation of Harache based on the design of the previous section. Harache was implemented on an Apache HTTP Server [11] (Apache) on a Linux OS with SELinux. The core of Harache was created as an Apache module, mod harache. In the Linux OS, SELinux restricts the readable area of the server processes to the configuration files of Apache, and the writable area to the log files. It also restricts the executable area to the library directory for the Apache’s execution and the binary directory for the CGI’s execution. The read permission of the user directory is granted only to the directory owner. The write permission of the data directory of the CGIs is similarly granted only to the data directory owner. The details are as follows.
4.1
Server
The authority of the server processes is changed to the file owner’s after Harache receives a request for user directories. A user directory is where a user stores web content. Harache does normal processing after changing the authority. Figure 3 shows an overview of a request processing of Harache. Harache terminates the server processes of users where no access occurs when needed. For UNIX-like OSes, a process occupies memory until its termination. As Harache has server processes for each user, each server process only does one user’s operation. Hence, server processes for users where no access occurs can cause a memory shortage. Harache solves this problem by terminating
71
Server
Table 1. Hardware configuration of experimental environments
Switching Hub
CPU Memory OS NIC CPU Memory OS NIC
Figure 4. Procedure for CGI processing of Harache
5.1
Client Intel Pentium 4 1.6 GHz 512 MBytes Fedora Core 2 (kernel 2.6.10) DEC DECchip 21140 100 Mbps
Server Intel Pentium III Xeon 500 MHz ×4 256 MBytes Fedora Core 2 (kernel 2.6.10) Intel PRO/1000XT PWLA8490XT 1 Gbps
Functional Evaluation
We performed functional evaluation experiments for Harache to determine that Harache has basic functions. First, we performed an experiment to determine that Harache can create user websites while maintaining the privacy and security in a server. We placed a text file, a CGI program file, and a PHP program file in a user directory A owned by user A. The owner of these files was user A. User A was the only one who could read, write, and execute these files. Also, another PHP program file that steals these files was placed in user directory B owned by user B. We then logged in with user B’s account and found that user B could not steal and execute these files directly. Also, we attempted to browse another PHP program file that steals these files and found that these files could not be stolen. However, we were able to browse these files. This substantiates that Harache can create websites but maintain the privacy and security in a server. Second, we performed an experiment to determine if Harache can solve problems when server embedded programs are used. We created a file in a user directory by way of WebDAV. Then, we determined that the owner of the created file was the same as the owner of the user directory. Therefore, file operations can be done by way of WebDAV in combination with a direct login in Harache. In addition, we placed a PHP program file that creates a data file in a user directory and browsed it. Next, we determined that the owner of the created data file was the same as the owner of the user directory. Therefore, other users that share the same server cannot steal and tamper with the data file because the permission for other is unnecessary. This substantiates that Harache can solve problems when server embedded programs are used. These functional evaluation experiments substantiate
A CGI is not executed on Harache initially. A CGI is executed in Apache only when the user identity (UID) that was set in the configuration file (httpd.conf) is equal to the UID of the server process that operates the CGI processing. A CGI in Harache is not executed because the root is set in the httpd.conf, and server processes run under the authority of the file owner. To solve this problem, we assigned the UID of the server process that operates the CGI processing to the variable in Apache, ap user id, which holds the UID set in the httpd.conf. Therefore, Harache can execute a CGI. In addition, mod cgi, which is included with Apache, creates a child process similar to mod harache for a CGI execution. Then, the process is created twice. This is wasteful. In order to solve this problem for CGI processing, mod harache does not create a child process and change its own authority. And, mod cgi changes its own authority. Figure 4 shows a procedure for Harache’s CGI processing. mod harache does steps (2)–(4) of the procedure, and mod cgi does step (6) in addition to steps (5), (7). Also, server processes are changed to the authority of the special user account similar to Apache when it receives a request for somewhere other than a user directory.
5
Network CentreCOM FS909GT V1 1000 BASE-T port ×1 100 BASE-TX port ×8
Evaluation
In this section, we present the results of evaluation experiments with Harache. Table 1 shows the hardware configuration of the experimental environments.
72
Table 2. Changed directives
9
78 6
45
Directive Name StartServers MinSpareServers MaxSpareServers MaxClients
3
0
-2
,- .
/01
: ?=! =# > : A@CB D>FE* G HIGKJ
Default 5 5 10 150
One-to-one 1 1 1 150
Harache 5 5 50 256
! " #$&% ' (*) +
@? ? ACB D ' E$ EC C'
>
Figure 5. Basic performance evaluation: CGI
