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.

Transcript

1. Design and Implementation of Infrastructure
   Software for More Sophisticated Web Services
   Kyoto University
   Okabe Lab
   MATSUMOTO Ryosuke
   

   View Slide

2. Contents
   1. Introduction
   2. mod_process_security
   3. mod_mruby
   

   View Slide

3. Introduction
   

   View Slide

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
   

   View Slide

5. mod_process_security
   

   View Slide

6. Contents – mod_process_security
   1. Introduction
   2. Access Control on Web Servers
   3. Proposed Access Control Architecture
   4. Experiment and Evaluation
   5. Conclusion
   

   View Slide

7. 1. Introduction
   - mod_process_security -
   

   View Slide

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.
   

   View Slide

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
   

   View Slide

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.
    

    View Slide

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
    

    View Slide

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
    

    View Slide

13. 2. Access Control on Web Server
    - mod_process_security -
    

    View Slide

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.
    

    View Slide

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
    

    View Slide

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
    ×
    

    View Slide

17. 3. Proposed Access Control Architecture
    - mod_process_security -
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

21. 4. Experiment and Evaluation
    - mod_process_security -
    

    View Slide

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）
    

    View Slide

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
    

    View Slide

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
    

    View Slide

25. 5. Conclusion
    - mod_process_security -
    

    View Slide

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
    

    View Slide

27. mod_mruby
    

    View Slide

28. Contents – mod_mruby
    1. Background
    2. Extension Mechanizm like Apache Modules
    3. mruby
    4. mod_mruby
    5. Performance Evaluation
    6. Conclusion
    

    View Slide

29. 1. Background
    - mod_mruby -
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

33. 2. Extension Mechanism like Apache Module
    - mod_mruby -
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

37. 3. mruby
    - mod_mruby -
    

    View Slide

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
    

    View Slide

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
    

    View Slide

40. 4. mod_mruby
    - mod_mruby -
    

    View Slide

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
    

    View Slide

42. Proxy by mod_mruby
    

    View Slide

43. Basic Auth by mod_mruby
    

    View Slide

44. Virtual host by mod_mruby
    

    View Slide

45. suEXEC by mod_mruby
    

    View Slide

46. Access control by traffic
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

53. 5. Performance Evaluation
    - mod_mruby -
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

57. 6. Conclusion
    - mod_mruby -
    

    View Slide

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
    

    View Slide

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.
    

    View Slide