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

1. A Low-Cost Runtime-Privilege Changing Systemfor Shared Servers Daisuke Hara and Yasuichi Nakayama The University of Electro-Communications, Tokyo, Japan ICACT 2010@Phoenix Park, Korea

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: • We have clarified the security problems in a shared server. • We have clarified runtime privileges in UNIX-like OSes, existing approaches to the security problems, and their limitations. • 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 Web server program Web site … … machine • Suitable for end users • Target of our study

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. (1) receive HTTP request 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 • (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) Web server Web client www A www (i-1) www Malicioususer B (3) send response (i-2) www C (2) process request ・・・ ・・・ ・・・ www: runtime privilege HTTP Server process User account User’s file Command-line tools

8. Existing Approaches about Runtime Privilege • 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. (1) receive HTTP request Design - Change in Runtime Privilege - (cont.) • File permissions are granted to only an owner for any content. => Secure • (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 Web client root A root root B (4) send response C root (2) seteuid(C) & setegid(C) (3) process request (5) seteuid(0) & setegid(0) C similar to Samba ・・・ ・・・ ・・・ Server process User account User’s file www: runtime privilege

11. Design - Change in Runtime Privilege - (cont.) • Malicious users cannot illegally steal, delete, or tamper with other user’s files. • (0) File permission • rw-/---/---(static contents (e.g., HTML and image files)) • rw-/---/--- (e.g., log files, wiki’s data files) • rwx/---/--- (CGI scripts) (1) receive HTTP request Oursystem Web client root A root (i-1) root Malicioususer B (4) send response (i-2) C (2) seteuid(C) & setegid(C) (3) process request (5) seteuid(0) & setegid(0) C ・・・ ・・・ ・・・ www: runtime privilege HTTP Server process User account User’s file Command-line tools

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

15. Basic performance evaluation • Aim: • to determine useful performance of our system • 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.

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.

18. Conclusions • Proposal: • A low-cost runtime-privilege changing system for shared servers • Contribution: • We have clarified the security problems in a shared server. • We have clarified runtime privileges in UNIX-like OSes, existing approaches to the security problems, and their limitations. • 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/group/other • Command & HTTP attack => prevented • with suEXEC • Problem: Low throughput(dynamic contents) • suEXEC cannot achieve the speed ofserver-embedded interpreters(e.g. PHP, mod_ruby) because it needs process creation and terminations twiceafter each request. www fork(), execve() root⇒A setuid(),setgid() fork(), execve() A To be terminated

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 access 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 suEXEC. • Cons: it cannot achieve the speed of server-embedded 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 setuid(),setgid() A To be terminated Dispatcher forward A B C workers Reusable

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) whole filesystem scope of filesystem where server processes can access applying a secure OS CAP_CHOWN CAP_DAC_OVERRIDE CAP_DAC_READ_SEARCH CAP_FOWNER ・ ・ ・ CAP_MAC_OVERRIDE CAP_MAC_ADMIN applying POSIX capabilities working areaofApache CAP_SETUID CAP_SETGID Limiting the scope of the effect of appropriated server processes scope of server processes’ privilege