Index: experimental/webtry/DESIGN |
diff --git a/experimental/webtry/DESIGN b/experimental/webtry/DESIGN |
new file mode 100644 |
index 0000000000000000000000000000000000000000..ddc26f538cba6e18cbb71d13642d0d421f1b2f1f |
--- /dev/null |
+++ b/experimental/webtry/DESIGN |
@@ -0,0 +1,121 @@ |
+Design |
+====== |
+ |
+ |
+Overview |
+-------- |
+Allows trying out Skia code in the browser. |
+ |
+ |
+Security |
+-------- |
+We're putting a C++ compiler on the web, and promising to run the results of |
+user submitted code, so security is a large concern. Security is handled in a |
+layered approach, using a combination of seccomp-bpf, chroot jail and rlimits. |
+ |
+*seccomp-bpf* - Used to limit the types of system calls that the user code can |
+make. Any attempts to make a system call that isn't allowed causes the |
+application to terminate immediately. |
+ |
+*chroot jail* - The code is run in a chroot jail, making the rest of the |
+operating system files unreachable from the running code. |
+ |
+*rlimits* - Used to limit the resources the running code can get access to, |
+for example runtime is limited to 5s of CPU. |
+ |
+User submitted code is also restricted in the following ways: |
+ * Limited to 10K of code total. |
+ * No preprocessor use is allowed (no lines can begin with \s*#). |
+ |
+ |
+Architecture |
+------------ |
+ |
+The server runs on GCE, and consists of a Go Web Server that calls out to the |
+c++ compiler and executes code in a chroot jail. See the diagram below: |
+ |
+ |
+ +–––––––––––––+ |
+ | | |
+ | Browser | |
+ | | |
+ +––––––+––––––+ |
+ | |
+ +––––––+––––––+ |
+ | | |
+ | | |
+ | Web Server | |
+ | | |
+ | (Go) | |
+ | | |
+ | | |
+ +–––––––+–––––+ |
+ | |
+ +–––––––+––––––––––+ |
+ | chroot jail | |
+ | +––––––––––––––+| |
+ | | seccomp || |
+ | | +––––––––––+|| |
+ | | |User code ||| |
+ | | | ||| |
+ | | +----------+|| |
+ | +––------------+| |
+ | | |
+ +––––––––––––––––––+ |
+ |
+ |
+The user code is expanded into a simple template and linked against libskia |
+and a couple other .o files that contain main() and the code that sets up the |
+seccomp and rlimit restrictions. This code also sets up the SkCanvas that is |
+handed to the user code. Any code the user submits is restricted to running in |
+a single function that looks like this: |
+ |
+ |
+ void draw(SkCanvas* canvas) { |
+ // User code goes here. |
+ } |
+ |
+The user code is tracked by taking an MD5 hash of the code The template is |
+expanded out into <hash>.cpp, which is compiled into <hash>.o, which is then |
+linked together with all the other libs and object files to create an |
+executable named <hash>. That executable is copied into a directory |
+/home/webtry/inout, that is accessible to both the web server and the schroot |
+jail. The application is then run in the schroot jail, writing its response, |
+<hash>.png, out into the same directory, /home/webtry/inout/, where is it read |
+by the web server and returned to the user. |
+ |
+Startup and config |
+------------------ |
+The server is started and stopped via: |
+ |
+ sudo /etc/init.d/webtry [start|stop|restart] |
+ |
+By sysv init only handles starting and stopping a program once, so we use |
tfarina
2014/09/20 03:55:19
s/By/But ?
|
+Monit to monitor the application and restart it if it crashes. The config |
+is in: |
+ |
+ /etc/monit/conf.d/webtry |
+ |
+The chroot jail is implemented using schroot, its configuration |
+file is found in: |
+ |
+ /etc/schroot/chroot.d/webtry |
+ |
+The seccomp configuration is in main.cpp and only allows the following system |
+calls: |
+ |
+ exit_group |
+ exit |
+ fstat |
+ read |
+ write |
+ close |
+ mmap |
+ munmap |
+ brk |
+ |
+Installation |
+------------ |
+See the README file. |
+ |
+ |