add Linux namespace-entering connections

Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>

2 files changed, 34 insertions, 3 deletions

diff --git a/doc/connections.rst b/doc/connections.rst
index 9205bbd..1f88f71 100644
--- a/doc/connections.rst
+++ b/doc/connections.rst
@@ -139,3 +139,33 @@ like chroot(2) and setuid(2) anyway.  Thus, typical usage on localhost would
 be something like::
 
   (deploy (:sudo :sbcl (:chroot.fork :into "...")) ...)
+
+Connections which use setns(2) to enter containers
+--------------------------------------------------
+
+When the current connection is a Lisp-type connection, connection types which
+enter Linux containers, such as ``:SYSTEMD-MACHINED``, invoke the setns(2)
+system call directly.  The implementation of this is the connection type
+``CONSFIGURATOR.CONNECTION.LINUX-NAMESPACE::SETNS``.  The implementation of
+the ``POST-FORK`` generic for that connection type is structured similarly to
+the nsenter(1) command from util-linux.  This has the advantage that
+``CONSFIGURATOR.CONNECTION.LINUX-NAMESPACE::SETNS`` should be reusable for
+implementing connection types which enter other kinds of Linux container; the
+container runtime-specific code is limited to determining the PID of the
+container's leading process.  However, there are some security implications to
+this approach.
+
+Firstly, the current implementation does not join the control group of the
+container's leading process, and thus the Consfigurator process running inside
+the container is not subject to resource limits applied to the container.  It
+might be possible for a process in the container to exploit this to escape its
+resource limits.
+
+Secondly, we do not attempt to enter the LSM security context of the
+container, such as the container's SELinux execution context or AppArmor
+profile.  This is because LSM usage is container runtime-specific.  In the
+case of unprivileged containers which make use of user namespaces, however,
+failing to enter the LSM security context typically does not breach container
+security.  For such containers, employment of an LSM serves as an extra layer
+of protection against kernel exploits, not as part of the enforcement of the
+container's basic security model.
diff --git a/doc/pitfalls.rst b/doc/pitfalls.rst
index 7c3b7d3..73782b8 100644
--- a/doc/pitfalls.rst
+++ b/doc/pitfalls.rst
@@ -84,9 +84,10 @@ Dumping and reinvoking Lisp
 ---------------------------
 
 Remote Lisp images can dump executable images of themselves using the
-IMAGE-DUMPED property.  However, there are some limitations to how this
-feature can be used that are connected with changing execution context in the
-way that connection types like :CHROOT.FORK and :SETUID do.
+IMAGE-DUMPED property, and some connection types work by dumping and then
+immediately reinvoking Lisp.  However, there are some limitations to how these
+features can be used that are connected with changing execution context, in the
+way that :CHROOT.FORK, :SETUID, and the Linux namespace-entering connections do.
 
 Firstly, for at least some Lisp implementations, the build of Lisp that's
 running must be accessible via the filesystem in order for it to be possible