confd: make container privileged mode configurable

Signed-off-by: Joachim Wiberg <troglobit@gmail.com>

board/common/rootfs/usr/sbin/container

@@ -91,7 +91,7 @@ create()
     # name, or return docker:// URL for download.
     image=$(unpack_archive "$image")
 
-    args="$args --restart=no --systemd=false --tz=local --privileged --replace --quiet"
+    args="$args --restart=no --systemd=false --tz=local $privileged --replace --quiet"
 #    args="$args --log-opt tag=$name"
     pidfn=/run/container:${name}.pid
 
@@ -160,6 +160,7 @@ options:
       --hostname NAME     Set hostname when creating container
       --net NETWORK       Set network(s) when creating container
   -m, --mount HOST:DEST   Bind mount a read-only file inside a container
+      --privileged        Give container extended privileges
   -p, --publish PORT      Publish ports when creating container
                           Syntax: [[ip:][hostPort]:]containerPort[/protocol]
       --read-only         Do not create a writable layer
@@ -232,6 +233,9 @@ while [ "$1" != "" ]; do
 	    shift
 	    network="$network --net $1"
 	    ;;
+	--privileged)
+	    privileged="--privileged=true"
+	    ;;
 	-p | --publish)
 	    shift
 	    port="$port -p $1"

doc/container.md

@@ -35,11 +35,13 @@ the Container Network Interface ([CNI][]) that podman supports.
 Caution
 -------
 
-A word of warning.  Containers run on your system in privileged mode, as
-`root`.  Even though they are fenced with Linux namespaces, and resource
-limited using Linux cgroups, which scope container applications from
-seeing and accessing the complete system.  There is no guarantee that an
-application cannot ever break out of this confinement.
+A word of warning, containers can run on your system in privileged mode,
+as `root`.  This gives them full access to devices on your system.  But
+even when though unprivileged containers are fenced from the host with
+Linux namespaces, and resource limited using Linux cgroups, which scope
+container applications from seeing and accessing the complete system,
+there is no guarantee that an application cannot ever break out of this
+confinement.
 
  - If the system is compromised, containers can be used to easily
    install malicious software in your system and over the network
@@ -48,7 +50,7 @@ application cannot ever break out of this confinement.
  - Running 3rd party container images on your system could open a
    security hole/attack vector/attack surface
  - An expert with knowledge how to build exploits will be able to
-   jailbreak/elevate to root
+   jailbreak/elevate to root even if best practices are followed
 
 This being said, a system suspected of being compromised can always be
 restored to a safe state with a factory reset.  Provided, of course,

src/confd/src/infix-containers.c

@@ -59,6 +59,9 @@ static int add(const char *name, struct lyd_node *cif)
 	if (lydx_is_enabled(cif, "read-only"))
 		fprintf(fp, " --read-only");
 
+	if (lydx_is_enabled(cif, "privileged"))
+		fprintf(fp, " --privileged");
+
 	LYX_LIST_FOR_EACH(lyd_child(cif), node, "volume")
 		fprintf(fp, " -v %s-%s:%s", name, lydx_get_cattr(node, "name"), lydx_get_cattr(node, "path"));
 

src/confd/yang/infix-containers@2024-02-01.yang

@@ -123,6 +123,11 @@ module infix-containers {
 	type inet:domain-name;
       }
 
+      leaf privileged {
+        description "Give container extended privileges, e.g., access to devices.";
+        type boolean;
+      }
+
       leaf restart-policy {
 	description "Restart policy to when containers exit/crash.";
 	type restart-policy;