Index: experimental/webtry/DESIGN |
diff --git a/experimental/webtry/DESIGN b/experimental/webtry/DESIGN |
deleted file mode 100644 |
index ddc26f538cba6e18cbb71d13642d0d421f1b2f1f..0000000000000000000000000000000000000000 |
--- a/experimental/webtry/DESIGN |
+++ /dev/null |
@@ -1,121 +0,0 @@ |
-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 |
-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. |
- |
- |