Feb. 9, 2010 ICACT 2010@Phoenix Park, Korea 1

A Low-Cost Runtime-Privilege Changing Systemfor Shared Servers

Daisuke Hara and Yasuichi Nakayama

The University of Electro-Communications, Tokyo, Japan

2

Outline

Introduction Background

– Increase in end users’ Web contents– Problems of sharing a Web server– Existing approaches about runtime privilege

Proposal: A Low-Cost Runtime-Privilege Changing System for Shared Servers

Evaluation Conclusions

3

Introduction

Problem of sharing a Web server– Malicious users that share the server can potentially

steal, delete, or tamper with other user’s files. Proposal: A low-cost runtime-privilege changing

system for shared servers Contributions:

1. We have clarified the security problems in a shared server.

2. We have clarified runtime privileges in UNIX-like OSes, existing approaches to the security problems, and their limitations.

3. We have described our design of a low-cost runtime-privilege changing system and our implementation of it for a Web server on a Linux OS.

4

Background

More people are creating their own content and publishing it on the Web as the Internet grows in popularity.– End users create weblogs, wikis, CMSs.

Shared hosting services are widely used.– Many customers share a server.

100s - 1000s sites/server

– low price & flexible custom CGI, etc.

5

Hosting Service

Shared hosting service vs. Dedicated hosting service

Shared hosting service Dedicated hosting service

Analogy of houses apartment / condominium single-family house

the number ofWeb sites : Web serverprograms : machines

N:1:1*N = 100s - 1000s

1:1:1

available machine resource(e.g. CPU, memory, disk)

limited (share) all (dedicate)

fee low (a few $/month) expensive

•Suitable for end users•Target of our study

…Web site

machine

Web server program

…

6

Problem of sharing a Web server

Processes of a Web server program (e.g. Apache)– A parent process run under the privilege of a root user.

binding port 80

– Many server (child) processes run under the privilege of a dedicated user (e.g. apache, www-data, www).

processing requests

Read, write, execution permission on these content files must be granted to an other.– UNIX permission model: owner/group/other

7

Problem of sharing a Web server (cont.)

Malicious users that share the server can illegally steal, delete, or tamper with other user’s files.– (i-1) command attack, (i-2) HTTP attack

Server process

www

www

www

www

・・

・

User account

・・

・ ・・

・

User’s file

Webserver Web client

(i-1)

(i-2)

(0) File permission• rw-/---/r-- (static contents (e.g., HTML and image files))• rw-/---/rw- (e.g., log files, wiki’s data files)• rwx/---/r-x (CGI scripts)

HTTP

Command-line tools

Malicioususer

A

B

C

(1) receive HTTP request

(2) process request

(3) send response

www: runtime privilege

8

Existing Approaches about Runtime Privilege

Securityin Server

Basic Performance(Throughput/Latency

)

Site-numberScalability

Generality

Container/VM

excellent excellentpoor

(overhead ofvirtualization)

poor(modifications

of kernel)

PHPsafe mode

good excellent excellentpoor

(PHP-specific)

POSIX ACL(with suEXEC)

goodpoor

(twice fork&exec)excellent good

(vanillaApache)

poor excellent excellent good

Existing approaches solve a portion of the security problem, but they either lack performance, site-number scalability, or generality.

9

Design - Change in Runtime Privilege -

Server processes are launchedunder the privilege of a root user.

(1) When a request is received, (2) the server process changes its runtime privilege (effective user ID/group ID) to an ordinary user/group.– by using seteuid()/setegid() system calls

(3) It processes the request and (4) sends the response.

(5) It changes its runtime privilege back to 0 (root).

10

root

Design - Change in Runtime Privilege - (cont.)

Server process

root

root

root

C

・・

・

User account

・・

・ ・・

・

User’s file

Oursystem Web client

A

B

C

(1) receive HTTP request

(2) seteuid(C) & setegid(C)(3) process request(5) seteuid(0) & setegid(0)

(4) send response

www: runtime privilege

File permissions are granted to only an owner for any content. => Secure

similar to Samba

(0) File permission• rw-/---/--- (static contents (e.g., HTML and image files))• rw-/---/--- (e.g., log files, wiki’s data files)• rwx/---/--- (CGI scripts)

11

Design - Change in Runtime Privilege - (cont.)

Malicious users cannot illegally steal, delete, or tamper with other user’s files.

Server process

root

root

root

C

・・

・

User account

・・

・ ・・

・

User’s file

Web client

(i-1)

(i-2)

HTTP

Command-line tools

Malicioususer

A

B

C

(1) receive HTTP request

(2) seteuid(C) & setegid(C)(3) process request(5) seteuid(0) & setegid(0)

(4) send response

www: runtime privilege

(0) File permission• rw-/---/--- (static contents (e.g., HTML and image files))• rw-/---/--- (e.g., log files, wiki’s data files)• rwx/---/--- (CGI scripts)

Oursystem

12

Design - Limitation with Changing Runtime Privilege by User Scripts -

Challenge: User scripts (e.g. CGI) usually can invoke setuid()/setgid() as well as our system can.=> Malicious users potentially can appropriate a root

privilege.

Solution: Our system hooks calls for a series of setuid()/setgid() and disables them.=> Our system can only change the runtime privilege.

13

Implementation

We implemented our system for anApache HTTP server 2.2.10 on a Linux OS.

The function for changing the runtime privilege was implemented as a module, mod_seteuid.so, on an Apache.

The function that limits user scripts when their runtime privilege is changed was implemented as a shared object, setuid_hooks.so, outside of an Apache.

14

Evaluation

Experimental environment

Client & Server

CPU AMD Opteron 240EE 1.4 GHz x 2

Memory 4 GB

OS Cent OS 5.3 (Linux 2.6.18)

NIC Broadcom BCM5704C (1 Gbps)

15

Basic performance evaluation

Aim:– to determine useful performance of our syste

m Systems for comparison:

– vanilla Apache Benchmark:

– httperf benchmark ver. 0.9.0– We sent requests to the PHP script (just calls

a phpinfo()) and measured the response throughput.

16

Basic performance evaluation (cont.)- throughput -

The throughput with our system was, on average, 0.5% lower than that with Apache and was a maximum of 4.7% lower.

The overhead of our system is very low.

0

100

200

300

400

500

600

700

800

100 200 300 400 500 600 700 800 900 1000

Request frequency (N/s)

Thr

ough

put (

N/s

)

Apache

Our system

17

Basic performance evaluation (cont.)- latency -

The latency with our system was, on average, 31.6% higher than that with Apache and was a maximum of 59.9% higher.– These were due to the overhead of the hook operations.

Because the maximum latency with our system was 1.1 seconds,it should be used for practical Web servers.

0

200

400

600

800

1000

1200

100 200 300 400 500 600 700 800 900 1000

Request frequency (N/s)

Late

ncy

(ms)

Apache

Our system

18

Conclusions

Proposal: – A low-cost runtime-privilege changing system for shar

ed servers Contribution:

1. We have clarified the security problems in a shared server.

2. We have clarified runtime privileges in UNIX-like OSes, existing approaches to the security problems, and their limitations.

3. We have described our design of a low-cost runtime-privilege changing system and our implementation of it for a Web server on a Linux OS.

Our evaluation results demonstrate that our system solves the security problems in a shared server with little performance degradation.

19

Future Work

Applying a secure OS and POSIX capabilities to our system

Evaluation with real applications Applying the concept of our design to

other server programs that provide service to many users

20

Thank you.

Any questions/comments?

21

Existing Approaches about Runtime Privilege- POSIX ACL -

Providing access control for each user– enhancement of UNIX permission model, owner/grou

p/other Command & HTTP attack => prevented

– with suEXEC Problem: Low throughput

(dynamic contents)– suEXEC cannot achieve the speed of

server-embedded interpreters(e.g. PHP, mod_ruby) because it needs process creation and terminations twiceafter each request.

www

A

To be terminated

fork(), execve()

root⇒A

setuid(),setgid()

fork(), execve()

22

Existing Approaches about Runtime Privilege- Secure OS -

Secure OSes can restrict root user’s operations by minimizing scope of filesystem where it can access.– Mandatory access control (MAC) enforces ac

cess control for all users and processes without exception.

– In the least privilege security model, a higher-than-needed privilege level is not granted to users and processes.

Command attack => prevented HTTP attack => cannot be prevented

23

Existing Approaches about Runtime Privilege - Container and Virtual Machine -

Container: OS-level virtualization methods– Multiple containers with server software programs can

run concurrently in an OS. => Secure Virtual Machine (VM)

– Multiple OSes with server software programs can run concurrently on the same server machine. => Secure

Problem: – Overhead of virtualization

=> low scalability of the number of sites in a server– modification of kernel

=> low generality

24

Existing Approaches about Runtime Privilege- Harache/Hi-sap -

Our previously proposed Web server systems– solve the security problems in a shared server

Harache– Pros: It has up to 1.7 times the performance of suEXE

C.– Cons: it cannot achieve the speed of server-embedde

d interpreters because it needs aprocess termination after each HTTP session.

Hi-sap– Pros: It speeds up server-embedded

interpreters. up to 14.3 times the throughput of suEXEC

– Cons: Maintenance and operationcost of many server softwareprograms is high.

root

A

To be terminated

setuid(),setgid()

A

Reusable

forwardDispatcher

B C

workers

25

Existing Approaches about Runtime Privilege- POSIX capabilities -

a separation of root privilege into a set of capabilities=> It can minimize privilege of server processes.

Linux kernel 2.6.30 defines 34 capabilities. – CAP SETUID/CAP SETGID

invoking a series of setuid()/setgid()

– CAP NET BIND SERVICE binding well-known ports

command & HTTP attack => cannot be prevented

26

Applying POSIX capabilities and a secure OS

Minimizing scope of server processes’ privilege (POSIX capabilities) and scope of filesystem where server processes can access (secure OS)

scop

e of

file

syst

em w

her

e se

rver

pro

cess

es c

an a

cces

s

scope of server processes’ privilege

applyinga secure

OS

CA

P_S

ET

UI

DC

AP

_SE

TG

ID

CA

P_C

HO

WN

CA

P_D

AC

_OV

ER

RID

EC

AP

_DA

C_R

EA

D_

SE

AR

CHC

AP

_FO

WN

ER・・・

CA

P_M

AC

_OV

ER

RID

EC

AP

_MA

C_A

DM

IN

applyingPOSIX capabilities

whole filesystem

working areaofApache

Limiting the scope of theeffect of appropriated

server processes