From 42489752b4c78f6bbc80bb56a4347b692a067c29 Mon Sep 17 00:00:00 2001 From: Sean Whitton Date: Sun, 25 Jul 2021 13:03:57 -0700 Subject: add Linux namespace-entering connections Signed-off-by: Sean Whitton --- doc/connections.rst | 30 ++++++++++++++++++++++++++++++ doc/pitfalls.rst | 7 ++++--- 2 files changed, 34 insertions(+), 3 deletions(-) (limited to 'doc') 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 -- cgit v1.2.3