Remove nosocket, update security principles in docs

api/src/nosocket/Makefile

@@ -1,19 +0,0 @@
-CC = gcc 
-CFLAGS = -O2 -Wall -lseccomp 
-TARGET = nosocket 
-BUILD_PATH = ./
-INSTALL_PATH = /usr/local/bin/
-SOURCE = nosocket.c
-
-all: $(TARGET)
-
-$(TARGET): $(SOURCE)
-	$(CC) $(BUILD_PATH)$(SOURCE) $(CFLAGS) -o $(TARGET)
-
-install:
-	mv $(TARGET) $(INSTALL_PATH)
-
-clean:
-	$(RM) $(TARGET)
-	$(RM) $(INSTALL_PATH)$(TARGET) 
-

api/src/nosocket/nosocket.c

@@ -1,62 +0,0 @@
-/*
-nosocket.c
-
-Disables access to the `socket` syscall and runs a program provided as the first
-commandline argument.
-*/
-#include <stdio.h>
-#include <errno.h>
-#include <unistd.h>
-#include <sys/prctl.h>
-#include <seccomp.h>
-
-int main(int argc, char *argv[])
-{
-    // Disallow any new capabilities from being added
-    prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);
-
-    // SCMP_ACT_ALLOW lets the filter have no effect on syscalls not matching a
-    // configured filter rule (allow all by default)
-    scmp_filter_ctx ctx = seccomp_init(SCMP_ACT_ALLOW);
-    if (!ctx)
-    {
-        fprintf(stderr, "Unable to initialize seccomp filter context\n");
-        return 1;
-    }
-
-    // Add 32 bit and 64 bit architectures to seccomp filter
-    int rc;
-    uint32_t arch[] = {SCMP_ARCH_X86_64, SCMP_ARCH_X86, SCMP_ARCH_X32};
-    // We first remove the existing arch, otherwise our subsequent call to add
-    // it will fail
-    seccomp_arch_remove(ctx, seccomp_arch_native());
-    for (int i = 0; i < sizeof(arch) / sizeof(arch[0]); i++)
-    {
-        rc = seccomp_arch_add(ctx, arch[i]);
-        if (rc != 0)
-        {
-            fprintf(stderr, "Unable to add arch: %d\n", arch[i]);
-            return 1;
-        }
-    }
-
-    // Add a seccomp rule to the syscall blacklist - blacklist the socket syscall
-    if (seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EACCES), SCMP_SYS(socket), 0) < 0)
-    {
-        fprintf(stderr, "Unable to add seccomp rule to context\n");
-        return 1;
-    }
-
-#ifdef DEBUG
-    seccomp_export_pfc(ctx, 0);
-#endif
-
-    if (argc < 2)
-    {
-        fprintf(stderr, "Usage %s: %s <program name> <arguments>\n", argv[0], argv[0]);
-        return 1;
-    }
-    seccomp_load(ctx);
-    execvp(argv[1], argv + 1);
-    return 1;
-}

readme.md

@@ -411,26 +411,26 @@ Content-Type: application/json
 
 # Principle of Operation
 
-Piston uses Docker as the primary mechanism for sandboxing. There is an API within the container written in Node
+Piston uses [Isolate](https://www.ucw.cz/moe/isolate.1.html) inside Docker as the primary mechanism for sandboxing. There is an API within the container written in Node
-which takes in execution requests and executees them within the container safely.
+which takes in execution requests and executes them within the container safely.
-High level, the API writes any source code to a temporary directory in `/piston/jobs`.
+High level, the API writes any source code and executes it inside an Isolate sandbox.
 The source file is either ran or compiled and ran (in the case of languages like c, c++, c#, go, etc.).
 
 <br>
 
 # Security
 
-Docker provides a great deal of security out of the box in that it's separate from the system.
+Piston uses Isolate which makes use of Linux namespaces, chroot, multiple unprivileged users, and cgroup for sandboxing and resource limiting. Code execution submissions on Piston shall not be aware of each other, shall not affect each other and shall not affect the underlying host system. This is ensured through multiple steps including:
-Piston takes additional steps to make it resistant to
-various privilege escalation, denial-of-service, and resource saturation threats. These steps include:
 
--   Disabling outgoing network interaction
+-   Disabling outgoing network interaction by default
 -   Capping max processes at 256 by default (resists `:(){ :|: &}:;`, `while True: os.fork()`, etc.)
 -   Capping max files at 2048 (resists various file based attacks)
 -   Cleaning up all temp space after each execution (resists out of drive space attacks)
--   Running as a variety of unprivileged users
+-   Running each submission as a different unprivileged user
--   Capping runtime execution at 3 seconds
+-   Running each submission with its own isolated Linux namespaces
--   Capping stdout to 65536 characters (resists yes/no bombs and runaway output)
+-   Capping runtime execution at 3 seconds by default (CPU-time and wall-time)
+-   Capping the peak memory that all the submission's processes can use
+-   Capping stdout to 1024 characters by default (resists yes/no bombs and runaway output)
 -   SIGKILLing misbehaving code
 
 <br>