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

  • 872 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
872
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
4
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. A Low-Cost Runtime-Privilege Changing System for Shared Servers D a isuke H a r a 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:
      • 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
    • Suitable for end users
    • Target of our study
    … Web site machine Web server program … low (a few $/month) limited (share) N:1:1 *N = 100s - 1000s apartment / condominium Shared hosting service Dedicated hosting service Analogy of houses single-family house the number of Web sites : Web server programs : machines 1:1:1 available machine resource (e.g. CPU, memory, disk) all (dedicate) fee expensive
  • 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 Web server 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 Malicious user A B C (2) process request (3) send response www : runtime privilege (1) receive HTTP request
  • 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 .
    good excellent poor (twice fork&exec) good POSIX ACL (with suEXEC) Security in Server Basic Performance (Throughput/Latency) Site-number Scalability Generality Container /VM excellent excellent poor (overhead of virtualization) poor (modifications of kernel) PHP safe mode good excellent excellent poor (PHP-specific) (vanilla Apache) poor excellent excellent good
  • 9. Design - Change in Runtime Privilege -
    • Server processes are launched under 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. Design - Change in Runtime Privilege - (cont.)
    • File permissions are granted to only an owner for any content. => Secure
    root Server process root root root C ・・・ User account ・・・ ・・・ User’s file Our system Web client A B C (2) seteuid(C) & setegid(C) (3) process request (5) seteuid(0) & setegid(0) (4) send response www : runtime privilege 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)
    (1) receive HTTP request
  • 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 Malicious user 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)
    Our system
  • 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 an Apache 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
    Broadcom BCM5704C (1 Gbps) NIC Cent OS 5.3 (Linux 2.6.18) OS 4 GB Memory AMD Opteron 240EE 1.4 GHz x 2 CPU Client & Server
  • 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 of server-embedded interpreters (e.g. PHP, mod_ruby) because it needs process creation and terminations twice after 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 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 a process 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 operation cost of many server software programs is high.
    root A To be terminated setuid(), setgid() A Reusable forward Dispatcher 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 )
    scope of filesystem where server processes can access scope of server processes’ privilege applying a secure OS CAP_SETUID CAP_SETGID CAP_CHOWN CAP_DAC_OVERRIDE CAP_DAC_READ_SEARCH CAP_FOWNER ・ ・ ・ CAP_MAC_OVERRIDE CAP_MAC_ADMIN applying POSIX capabilities whole filesystem working area ofApache Limiting the scope of the effect of appropriated server processes