mod_mruby and mod_process_security

mod_mruby and mod_process_security

As the recent deployment of Cloud Computing, Web services have been becoming sophisticated like cloud services or social network services. We design and implement infrastructure software for more sophisticated web services. Today we present two pieces of software of some our works for Apache httpd. First, mod_process_security is a high performance access control architecture separating privilege by a thread on a web server. Second, mod_mruby is a Web server extension mechanism using embeddable scripting language mruby. mod_mruby allows to extend the functionality of Apache easily by implementing a mruby script.

2b692bd83f4418103142a053ecf5ff59?s=128

MATSUMOTO Ryosuke

April 11, 2013
Tweet

Transcript

  1. Design and Implementation of Infrastructure Software for More Sophisticated Web

    Services Kyoto University Okabe Lab MATSUMOTO Ryosuke
  2. Contents 1. Introduction 2. mod_process_security 3. mod_mruby

  3. Introduction

  4. Introduction • Background • As the recent deployment of Cloud

    Computing • Web services have been becoming sophisticated • Cloud services(SaaS, Paas, Iaas), SNS • Our Study • Design and implement infrastructure software for more sophisticated web service • Security, Performance, Large-scale, extended, operation- technology • We present two pieces of software for Apache httpd 1. mod_process_security - High performance access control 2. mod_mruby - Very useful extension mechanism for httpd
  5. mod_process_security

  6. Contents – mod_process_security 1. Introduction 2. Access Control on Web

    Servers 3. Proposed Access Control Architecture 4. Experiment and Evaluation 5. Conclusion
  7. 1. Introduction - mod_process_security -

  8. Background • Deployment of Cloud Computing • Cost: Reducing the

    total cost of ownership (TCO), including hardware, software and operation-technology • Security: Confidentiality, Integrity and Availability • PaaS (Platform as a Service): Large-Scale Shared Web Hosting Service, or so-called “Virtual Hosting” • Many Web sites share a single Operating System as well as HW resource. • Separation among sites is implemented using mechanism ether in OS or in the Web server.
  9. Background • Discretionary Access Control (DAC) : the access control

    model on UNIX and Windows OS "as a means of restricting access to objects based on the identity of subjects and/or groups to which they belong. …” (Wikipedia) • There are some problem both in security and performance. • Ex) suEXEC for CGI on Apache HTTP Server • CGI method: low performance Run dynamic contents securely and fast on large-scale shared Web hosting services
  10. Dynamic Contents on a Web Server • CGI is low-performance

    • DSO (Dynamic Shared Object) is enough fast, but… Server Process CGI Process Program Server Process Program CGI DSO embedded Interpreter previously bottleneck Engineers’ needs to use DSO on a shared web hosting.
  11. Problem in Dynamic Contents Problem in access controls – DSO

    • Architecture separating privilege by a server process • Serious performance degradation when securely executed – CGI • Architecture separating privilege by a CGI process each • Intrinsically low performance in creating a child process – Existing access controls are provided by the execution methods each. • CGI , DSO, or other Interpreters • Complicated and user-unfriendly settings In executing dynamic contents on a shared Web hosting service, – Use of CGI is almost mandatory for security – If using DSO, separating privilege by a daemon process or VM ⇒ Too much overhead
  12. Our Research “Secure and high-performance access control architecture on large-scale

    shared Web virtual hosting” • We propose a thread-based security mechanism, and implement as a module “mod_process_security” • Architecture separating privilege by thread • Performance degradation is low, if using DSO • Enough security • Independent from the program execution method, either CGI or DSO • As an module for Apache HTTP Server on Linux
  13. 2. Access Control on Web Server - mod_process_security -

  14. Overview of Access Control on a Web Server • Apache

    HTTP Server( don’t use access controls) • Using VirtualHost for a huge number of hosts to reduce HW costs. • Handling all requests by the privilege of server processes. • Files can be read via programs of any other host areas. • Basic architecture of access controls • Dynamic contents run with the privilege of the contents. • Preventing access to other virtual host area. • suEXEC, mod_suid2 or mod_ruid2 and so on… OS Web Service A Web Service B Virtual Host B Virtual Host A × × × × Single server process Setting the privilege of the contents at each host area.
  15. execve() Child Server Process (owner : apache) CGI Process (owner

    : root) index.php (owner: user1) fork() execve() suexec-program CGI Process (owner : user1) setuid(), setgid() terminate process Parent Server Process (owner : root) bottleneck CGI suEXEC Archtecture
  16. run Parent Server Process (owner : root) Child Server Process

    (owner : apache) Set capability index.php (owner: user1) Set cap(Linux capability) Child Server Process (owner : user1) Set capability setuid(), setgid() setuid(), setgid() terminate process × DSO mod_ruid2 Architechture bottleneck Unset cap Changing the privilege of Server Process ×
  17. 3. Proposed Access Control Architecture - mod_process_security -

  18. Proposed Access Control Architecture - mod_process_security - 1. Reducing the

    bottleneck using a thread • Creating a thread instead of forking a process • separating privilege by the thread • Do NOT have to terminate server processes 2. Independent of executing methods • Do Not have to install an access control software individually for CGI or DSO 3. Installing and Setting are easy • Apache module • User-friendly specification
  19. execve() Child Server Process (owner : apache) Control Thread (owner

    : apache) index.php (owner: user1) Create thread, set cap Control Thread (owner : user1) setuid・setgid, unset cap destroy thread Parent Server Process (owner : root) CGI mod_process_security CGI Process (owner : user1) terminate process CGI Specification
  20. Child Server Process (owner : apache) Control Thread (owner :

    apache) Create thread, set cap Control Thread (owner : user1) setuid・setgid, unset cap destroy thread Parent Server Process (owner : root) DSO mod_process_security run index.php (owner: user1) DSO Specification
  21. 4. Experiment and Evaluation - mod_process_security -

  22. Experiment Clinent Machine CPU Intel Core2Duo E8400 3.00GHz Memory 4GB

    NIC Realtek RTL8111/8168B 1Gbps OS CentOS 5.6 Web Server Machine CPU Intel Xeon X5355 2.66GHz Memory 8GB NIC Broadcom BCM5708 1Gbps OS CentOS 5.6 Middle Ware Apache 2.2 • Measuring response per second from a Web server • Generating requests per second from a client to a Web server • Sent requests to the PHP program and measured the response throughput • Printing phpinfo program(54KB), Benchmark software(httperf 0.9.0)
  23. Throughput 0 500 1000 1500 2000 2500 3000 Responses/sec Requests/sec

    DSO(mod_process_security) DSO(not using access control) DSO(mod_ruid2) CGI(not using access control) CGI(suEXEC) CGI(mod_process_security) DSO(mod_process_security ): Low throughput degradation DSO(mod_ruid2): about 4.5 responses for all requests Access control for CGI Low performance degradation CGI (Enlarge next slide) DSO
  24. Throughput for CGI 100 120 140 160 180 200 100

    200 300 400 500 600 700 800 900 1000 Responses/sec Requests/sec CGI(not using access control) CGI(suexec) CGI(mod_process_security) Not using access control、 mod_process_secuiry、 suEXEC
  25. 5. Conclusion - mod_process_security -

  26. Conclusion 1. Fast and secure access control on multitenant applications

    • High performance access control architecture for DSO • Use computing resource efficiently ⇒ Low cost 2. Independent of executing methods like CGI or DSO • Easy to install • user-friendly configure ⇒ In this architecture, you can withstand sophisticated Web services considering multitenant applications and Low cost hosting services
  27. mod_mruby

  28. Contents – mod_mruby 1. Background 2. Extension Mechanizm like Apache

    Modules 3. mruby 4. mod_mruby 5. Performance Evaluation 6. Conclusion
  29. 1. Background - mod_mruby -

  30. More Sophisticated Web Services • The recent deployment of Web

    services • Cloud Service, SNS Service • Increasing demand for Web servers • Tuning for Web servers is very important • Problemse of security, performance, operation-technology • It’s difficult to optimize only Web contents • You will also need to extend Web server software • Security on middle-ware layer • Auto scaling Web server • Resource tuning flexibly
  31. Extend Web Server Software • Extention mechanism is very complicated

    • For example, Apache Modules or Nginx Modules • Implemented by C – Low productivity and maintainability • Require compile before • Require deep understanding about internal specifications • Implement extended mechanism using scripting language • Require low performance deradation • Require modifiable code without restarting httpd Recently Performance and Lightweight by C ⇒ Productivity and maintainability by scripting language
  32. Our Study • mod_mruby – New Extension Mechanism for Apache

    • Features of mod_mruby 1. High performance 2. Change a code for Apache extensions without restarting httpd 3. Write your own Apache modules by Ruby • Control Apache httpd by Ruby • Proxy, Redirect, Access Control, VirtualHost and Server Status • Use mruby – New Embeddable Scripting Language • Lightweight memory footprint, High Performance, Embeddable C Applications, High portability • Same Ruby coding style Propose mod_mruby and Evaluate performance
  33. 2. Extension Mechanism like Apache Module - mod_mruby -

  34. Extension Mechanism for Apache httpd • Apache Module • a

    modular concept to provide functions except the core ability • Apache API to Extend functions by Apache module • Pluggable , Fast, Lightweight, Implemented by C • Low productivity, Low maintainability • having to compile, deep understanding Apache httpd internal Apache Core Apache module 1 Apache module 2 Apache module 3 ・ ・ ・ ・ Apache module n Apache API Require restarting httpd for changing an Apache module
  35. Existing Extension Mechanism by Script Lang • mod_lua , mod_perl,

    mod_ruby, mod_python and so on… Apache module 1 script 1 Apache module 2 Apache module n mod_*** script 2 ・ ・ ・ ・ ・ ・ ・ script n Apache Core Apache API API Do NOT require restarting httpd for changing the code
  36. mod_hello mod_perl mod_ruby mod_lua mod_mruby language C Perl ruby Lua

    mruby Init VM State ** Before Before Each time Before Load libraries ** Before Before Each time Before compile Each time Before Before Each time Before Change code NG OK OK OK OK Global variable Sharing Sharing Sharing NOT Sharing NOT Sharing Performance (Response/sec) 9861.17 3346.38 4769.04 5209.11 --- Existing Extension Mechanism by Scripts
  37. 3. mruby - mod_mruby -

  38. mruby • Recent embedded software development • Implemented by C

    ⇒ problem: Improve productivity • Quick delivery, High quality, Large-scale • Similar problems of our study • Lua is quite often used in embedded software development • Ruby is quite often used in a Web service and have high productivity • Yukihiro Matsumoto implement mruby • In collaboration with embedded engineers and researchers • Sponsored by he Regional Innovation Creation R&D Programs of the Ministry of Economy, Trade and Industry of Japan. • 「Research and Development of Embedded Platform Using Lightweight Ruby」 • (In Japanese)「軽量Rubyを用いた組込みプラットフォームの研究・開発」 • April 2012 mruby Released Minimal implementation, Embeddable, Matz, Considerable active committers have "M" as their name initials, somehow. = mruby
  39. mruby • The lightweight implementation of the Ruby language •

    complying to (part of) the Ruby ISO standard • linked and embedded within your C application 1. Performance 2. Lightweight memory footprint 3. Productivity: Ruby description 4. Portability: Compliant C99 5. Pluggable Module, Class, Method 6. Operate independently of OS or Filesystem • Most-watched Features of mruby for mod_mruby • Workable multiple interpreter on a thread • Workable multiple code on an interpreter Remarkable
  40. 4. mod_mruby - mod_mruby -

  41. mod_mruby • Features 1. Control Apache by Ruby description 2.

    High performance 3. Modifiable code without restarting Apache httpd 4. Global variable is NOT influenced by each other Ruby code • mod_mruby exmaple • Proxy • Redirect • Access control • Auth • Virtual host
  42. Proxy by mod_mruby

  43. Basic Auth by mod_mruby

  44. Virtual host by mod_mruby

  45. suEXEC by mod_mruby

  46. Access control by traffic

  47. Existing Performance Architecture • mod_lua is the fastest extension mechanism

    for Apache – Lua is the fastest scripting language[1] – mod_lua[*1] Improve performance and maintainability • Maintainability: Improve mod_perl or mod_ruby – Load and free interpreter for every running code – Global variables is NOT influenced by each other code • Performance: Faster than mod_perl or mod_ruby – Programing language Lua itself is very fast – Low memory consumption » load and free interpreter for every running code Our goal: mod_mruby is faster than mod_lua and Global variables is NOT influenced by each other code [1] Attractive Chaos: “Programming Languages Benchmarks”, http://attractivechaos.github.com/plb/ [*1] Apache httpd 2.4.3
  48. Architecture of mod_lua Allocate Virtual Machine State(Lua_state) Load Libraries Parse

    Generate byte code Run on Virtual Machine Hook a Lua script Read a Lua script mod_lua Architecture Bottleneck Close Virtual Machine State
  49. Difference between mruby and Lua about VM State • In

    case of sharing Virtual Machine State by multiple code – Lua • Can call a function from other bytecode on same state • A script is influenced by other script • Global variables also are influenced by each other bytecode – Programmers are associated with variables violation risks. ⇒ mod_lua have to allocate a virtual machine state for each bytecode after hooking script. – mruby • mruby store a bytecode to “irep table” • A mruby script is NOT influenced by other script – If Sharing virtual machine state – Unless you define a method to access “irep table” in a C Application
  50. Architecture of mod_mruby - chart Parse Generate bytecode into irep

    table Run on Virtual Machine Hook a mruby script Read a mruby script Shared Virtual Machine state (mrb_state) and Libs mod_mruby Architecture A Virtual Machine State For a server process Free only the bytecode from irep table
  51. Architecture of mod_mruby - overview ・ ・ ・ ・ VM

    State A (mrb_state) Bytecode Parent process Child process A Child process B • Relation httpd process with mruby – A Child processes has a Virtual Machine and a VM State – Stored a bytecode into “irep table” on a VM State – freed only the bytecode after each session • Low memory consumption Libraries Virtual Machine A irep table VM State B (mrb_state) Bytecode Libraries Virtual Machine B irep table
  52. mod_mruby and ngx_mruby • ngx_mruby • Control nginx by Ruby

    description • Control Some Web server software by same description • Web engineers can extend a Web server function easily • Can write any Web apps and Web server extension in the same way Apache API mruby script 1 mod_mruby mruby script 2 ・ ・ ・ ・ mruby script n Nginx API ngx_mruby mruby script 3 Apache Core Nginx Core mruby API for Web
  53. 5. Performance Evaluation - mod_mruby -

  54. Experiment Client CPU Intel Core2Duo E8400 3.00GHz Memory 4GB NIC

    Realtek RTL8111/8168B 1Gbps OS CentOS 5.6 Web server CPU Intel Xeon X5355 2.66GHz Memory 8GB NIC Broadcom BCM5708 1Gbps OS CentOS 5.6 Middle Ware Apache 2.2 • Evaluate performance by accessing from a client to a Web server • “hello world” program • Concurrency 100, Total access one hundred thousand • Tuning httpd NOT to terminate server processes
  55. mod_hello mod_perl mod_ruby mod_lua mod_mruby language C Perl ruby Lua

    mruby Init VM State ** Before Before Each time Before Load libraries ** Before Before Each time Before compile Each time Before Before Each time Before Change code NG OK OK OK OK Global variable Sharing Sharing Sharing NOT Sharing NOT Sharing Performance (Response/sec) 9861.17 3346.38 4769.04 5209.11 9021.54 Result
  56. Result • Performance comparison – mod_mruby is 83.4% of mod_hello

    – mod_lua is 52.8% of mod_hello – mod_ruby is 48.3% of mod_hello – mod_perl is 33.9% of mod_hello • difference between mod_mruby and mod_lua – mod_mruby Share a VM Sate(mrb_state) and Libraries – mod_lua do NOT Share • Global Variables are influenced by each code if mod_lua share state
  57. 6. Conclusion - mod_mruby -

  58. Conclusion • Propose mod_mruby and evaluate performance • Performance •

    The fastest than existing any extension mechanism by scripting language • Productivity • Balance between performance and productivity • Write by Ruby description • Can write any Web apps and Web server extension in the same way • Do NOT have to compile • Maintainability • Change code without restarting httpd • do NOT have to pay attention to global variables and function violation risks mod_mruby have a good balance of performance, productivity and maintainability
  59. Future Research Plans • Encourage using mod_mruby • Now releasing

    in https://modules.apache.org/ • We plan to design new virtual host architecture by combining mod_process_security with the module that can manage resources more flexibility on each virtual host. • We’d like to implement these modules using mod_mruby.