Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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.

MATSUMOTO Ryosuke
PRO

April 11, 2013
Tweet

More Decks by MATSUMOTO Ryosuke

Other Decks in Research

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