From a8e2653beb81a8ceac4ce133ac988a0e807061a0 Mon Sep 17 00:00:00 2001
From: Lars Wirzenius <liw@liw.fi>
Date: Sat, 8 Feb 2020 11:09:50 +0200
Subject: Change: more secure installation of Debian packages; build spec

---
 worker.md | 81 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------
 1 file changed, 72 insertions(+), 9 deletions(-)

diff --git a/worker.md b/worker.md
index 2c61105..36c0efe 100644
--- a/worker.md
+++ b/worker.md
@@ -88,7 +88,7 @@ Each build step is one the following:
 * An action implemented directly in the contractor.
 
 * An action implemented by executing a well-known, vetted external
-  program.
+  program, invoked in a secure way.
 
 * An action implemented by executing a program installed into a
   container.
@@ -110,10 +110,34 @@ This is necessary so that the build can have exactly the build
 environment it wants, with all build tools and build dependencies it
 needs.
 
-The controller executes also the trusted, external programs using
+The contractor executes also the trusted, external programs using
 bwrap, but with network access, and read-only access to the host's
 operating system.
 
+The contractor implmements a local artifact store, probably as a plain
+directory, and provides build steps for controlled access to it.
+
+
+Simple threat modelling
+-----------------------------------------------------------------------------
+
+* The main threat comes from executing unvetted code that may have
+  been written by an attacker: the shell code involved in executing
+  build steps, and the code being built.
+
+* Bubblewrap isolates any such code so that it can't attack the build
+  host (information leak, privilege elevation), except by a denial of
+  service by using too much resources (CPU, RAM, disk) on the build
+  host. Such code will not have network access.
+
+* The build step actions must be constrained in ways that prevent
+  executing untrusted code outside a security container.
+
+* The contractor is to provide controlled, secure build step
+  primitives for setting up a security container and workspace for
+  building a project. This will include installing any build
+  dependencies.
+
 
 Build step actions
 -----------------------------------------------------------------------------
@@ -145,11 +169,7 @@ create-systree
 debootstrap
 
 :   Run the [debootstrap][] program to install Debian into the
-    workspace.
-
-apt
-
-:   Install packages using the apt tool into the container's system
+    workspace. Also install any other packages into the debootstrap'd
     tree.
 
 shell
@@ -165,7 +185,6 @@ create-artifact     contractor          no
 unpack-artifact     contractor          no
 create-systree      contractor          no
 debootstrap         bwrap on host       yes
-apt                 bwrap on systree    yes
 shell               bwrap on systree    no
 
 It is intended that any actions implemented by the contractor itself,
@@ -175,7 +194,38 @@ secure, and cannot cause a information leaks or privilege escalation.
 Build specifications {#buildspec}
 =============================================================================
 
-FIXME.
+This is different from what Ick currently does. That's intentional:
+we're keeping things simple, and are also exploring the solution
+space.
+
+A build specification is a YAML file, defining one or more projects to
+build. Each project has a name (unique to the build spec), and a
+sequence of build steps. Each build step defines an action, and
+possibly step parameters.
+
+~~~yaml
+projects:
+- project: build-unstable-systree
+  build-steps:
+  - action: empty-workspace
+  - action: debootstrap
+    suite: unstable
+    packages:
+    - build-essential
+  - action: create-artifact
+    artifact-name: unstable-systree
+
+- project: hello
+  actions:
+  - action: create-systree
+    artifact-name: unstable-systree
+    container-name: default
+  - action: empty-workspace
+  - action: shell
+    container-name: default
+    shell: |
+      echo hello, world, from security container
+~~~
 
 
 
@@ -237,3 +287,16 @@ Acceptance criteria for Ick contractor {#acceptance}
 =============================================================================
 
 FIXME.
+
+
+Known problems
+=============================================================================
+
+* If debootstrap is the only way to construct a system tree, how can a
+  build install packages from non-Debian package repositories? For
+  example, from a repository of the user's own packages?
+
+* Projects need to be able to depend on each other, so that when one
+  builds successfully, that can trigger another project to build. For
+  example, when a systree artifact changes, anything that uses it
+  should probably be rebuilt.
-- 
cgit v1.2.1