OLD | NEW |
(Empty) | |
| 1 Design |
| 2 ====== |
| 3 |
| 4 |
| 5 Overview |
| 6 -------- |
| 7 Allows trying out Skia code in the browser. |
| 8 |
| 9 |
| 10 Security |
| 11 -------- |
| 12 We're putting a C++ compiler on the web, and promising to run the results of |
| 13 user submitted code, so security is a large concern. Security is handled in a |
| 14 layered approach, using a combination of seccomp-bpf, chroot jail and rlimits. |
| 15 |
| 16 *seccomp-bpf* - Used to limit the types of system calls that the user code can |
| 17 make. Any attempts to make a system call that isn't allowed causes the |
| 18 application to terminate immediately. |
| 19 |
| 20 *chroot jail* - The code is run in a chroot jail, making the rest of the |
| 21 operating system files unreachable from the running code. |
| 22 |
| 23 *rlimits* - Used to limit the resources the running code can get access to, |
| 24 for example runtime is limited to 5s of CPU. |
| 25 |
| 26 User submitted code is also restricted in the following ways: |
| 27 * Limited to 10K of code total. |
| 28 * No preprocessor use is allowed (no lines can begin with \s*#). |
| 29 |
| 30 |
| 31 Architecture |
| 32 ------------ |
| 33 |
| 34 The server runs on GCE, and consists of a Go Web Server that calls out to the |
| 35 c++ compiler and executes code in a chroot jail. See the diagram below: |
| 36 |
| 37 |
| 38 +–––––––––––––+ |
| 39 | | |
| 40 | Browser | |
| 41 | | |
| 42 +––––––+––––––+ |
| 43 | |
| 44 +––––––+––––––+ |
| 45 | | |
| 46 | | |
| 47 | Web Server | |
| 48 | | |
| 49 | (Go) | |
| 50 | | |
| 51 | | |
| 52 +–––––––+–––––+ |
| 53 | |
| 54 +–––––––+––––––––––+ |
| 55 | chroot jail | |
| 56 | +––––––––––––––+| |
| 57 | | seccomp || |
| 58 | | +––––––––––+|| |
| 59 | | |User code ||| |
| 60 | | | ||| |
| 61 | | +----------+|| |
| 62 | +––------------+| |
| 63 | | |
| 64 +––––––––––––––––––+ |
| 65 |
| 66 |
| 67 The user code is expanded into a simple template and linked against libskia |
| 68 and a couple other .o files that contain main() and the code that sets up the |
| 69 seccomp and rlimit restrictions. This code also sets up the SkCanvas that is |
| 70 handed to the user code. Any code the user submits is restricted to running in |
| 71 a single function that looks like this: |
| 72 |
| 73 |
| 74 void draw(SkCanvas* canvas) { |
| 75 // User code goes here. |
| 76 } |
| 77 |
| 78 The user code is tracked by taking an MD5 hash of the code The template is |
| 79 expanded out into <hash>.cpp, which is compiled into <hash>.o, which is then |
| 80 linked together with all the other libs and object files to create an |
| 81 executable named <hash>. That executable is copied into a directory |
| 82 /home/webtry/inout, that is accessible to both the web server and the schroot |
| 83 jail. The application is then run in the schroot jail, writing its response, |
| 84 <hash>.png, out into the same directory, /home/webtry/inout/, where is it read |
| 85 by the web server and returned to the user. |
| 86 |
| 87 Startup and config |
| 88 ------------------ |
| 89 The server is started and stopped via: |
| 90 |
| 91 sudo /etc/init.d/webtry [start|stop|restart] |
| 92 |
| 93 By sysv init only handles starting and stopping a program once, so we use |
| 94 Monit to monitor the application and restart it if it crashes. The config |
| 95 is in: |
| 96 |
| 97 /etc/monit/conf.d/webtry |
| 98 |
| 99 The chroot jail is implemented using schroot, its configuration |
| 100 file is found in: |
| 101 |
| 102 /etc/schroot/chroot.d/webtry |
| 103 |
| 104 The seccomp configuration is in main.cpp and only allows the following system |
| 105 calls: |
| 106 |
| 107 exit_group |
| 108 exit |
| 109 fstat |
| 110 read |
| 111 write |
| 112 close |
| 113 mmap |
| 114 munmap |
| 115 brk |
| 116 |
| 117 Installation |
| 118 ------------ |
| 119 See the README file. |
| 120 |
| 121 |
OLD | NEW |