Design and Implementation of a Web Server for a Hosting Service

1
Design and Implementation of a Web Server for a
Hosting Service

• Daisuke Hara, Ryota Ozaki, Kazuki Hyoudou,
• and Yasuichi Nakayama
• The University of Electro-Communications, Japan

2
Outline

• Introduction
• Background
• Problems of large-scale hosting service and web
  server
• Proposal - Harache
• Design
• Implementation
• Experiments
• Conclusions

3
Introduction

• Problem of existing web server
• Web contents can be stolen deleted by users
  that share the same server.
• Proposal - Harache
• Server processes run under the authority of the
  file owner.
• Achievement
• Harache solves the problem.
• It achieves useful throughput and high
  scalability.

4
Background

• Popularity of a shared hosting service
• low price flexible
• custom CGI, etc.
• Problems of large-scale shared hosting service
• Web contents can be stolen deleted by internal
  users.

User authority problem
5
Problem attacks from server inside (1)
Internal users can steal delete authentication
contents without authentication.
It is required to grant read permission to an
other. (rw-r--r--)
As website
Bs website
ID Pass
authentication
auth content
auth content
Cs website
browser
steal delete
Server
6
Problem attacks from server inside (2)

• To publish files on the Internet, it is required
  to grant read permission to an other.
• Internal users can steal (cp) delete (rm)
  authentication contents without authentication.
• If it is not required to grant any permissions to
  an other, this problem can be solved.
• POSIX ACL
• It offers access control for every user account.
• By using POSIX ACL, "cp" or "rm" attacks from
  internal users can be prevented.

7
Problem attacks from server inside (3)

• Even if POSIX ACL is used, the problem is
  occurred when server embedded programs are used.
• Although It is not required to grant read
  permission to an other, it is required to grant
  read permission to a special user.
• Server embedded programs (e.g. PHP, WebDAV) also
  run under the authority of a special user.
• For instance, malicious PHP scripts can steal
  delete authentication contents.

8
Proposal Harache

• To solve user authority problem
• Server processes run under the authority of the
  file owner.
• File permission to an other special user is not
  necessary.
• Server embedded programs (e.g. PHP) can be used
  safely conveniently.

9
Design principle

• Dedicated server process is assigned to every
  user.
• Each process runs under the authority of
  different user.
• It gives priority to scalability of the number of
  user.
• At shared hosting service, scalability is
  important.

10
Request processing of existing server
Web Server
special user
special user
special user
?
?
?
GET /userA/

• Request to the As Website
• Processing
• Respond to the Browser

browser
Server Process
11
Request processing of Harache
Harache
root
root
?
root
?
userA
?
?
GET /userA/

• Request to the As Website
• Setuid to userA
• Processing
• Respond to the Browser

browser
Server Process
12
Existing web server vs Harache
13
Implementation

• OS Linux OS with SELinux
• Web server Apache HTTP Server 1.3.33
• new module mod_harache
• preparation for changing the authority
• hacks in CGI processings
• modified module mod_cgi
• changing the authority
• execution of a CGI

14
Procedure for CGI processing existing server

• mod_userdir
• specify a file path from request URI
• mod_cgi
• create a child process (fork())
• execute a CGI (execve())

15
Procedure for CGI processing Harache

• mod_userdir
• specify a file path from request URI
• mod_harache
• specify user name from request URI
• specify UID GID from user name
• assign UID to ap_user_id
• modified mod_cgi
• create a child process (fork())
• change the authority (setuid()/setgid())
• execute a CGI (execve())

16
Experiments (1)

• Purpose To determine that Harache achieves
  useful performance high scalability.

Experimental environments
Fast Eathernet
Gigabit Eathernet
17
Experiments (2)

• Basic performance evaluation
• Apache, Apache with suEXEC were used for
  comparisons.
• We used httperf benchmark.
• We sent requests to a C CGI that displays 10
  KBytes characters.
• Scalability evaluation
• One-to-one was used for comparison.
• It assigns an Apache for each user.
• It can solve user authority problem without
  Apache module development.
• We used Apache HTTP server benchmarking tool
  (ab).
• We sent requests to a C CGI.

18
Basic performance evaluation

• Haraches overhead was low.
• It lost 5.2 of throughput relative to Apache.
• It achieved substantially high throughput
  relative to suEXEC

19
Scalability evaluation

• Haraches scalability is high.
• It achieves substantially higher throughput
  than One-to-one.
• Throughput decrement is low.

20
Conclusions

• Proposal Harache
• Server processes run under the authority of the
  file owner.
• Implementation
• On a Linux OS with SELinux.
• Achievement
• solution of user authority problem
• high security in a server
• low overhead
• high scalability

21

• Thank you.
• Any questions/comments?