From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server-vie001.gnuweeb.org X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,URIBL_DBL_BLOCKED_OPENDNS, URIBL_ZEN_BLOCKED_OPENDNS autolearn=ham autolearn_force=no version=3.4.6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gnuweeb.org; s=new2025; t=1756700385; bh=oopwZlPOcT3S6JMNZqiypx9GhAOXPyf7XUrR113gR7U=; h=MIME-Version:From:Date:Message-ID:Subject:To:Cc:Content-Type: Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:References: Resent-Date:Resent-From:Resent-To:Resent-Cc:User-Agent: Content-Type:Content-Transfer-Encoding; b=Fg5qbkz8XrT8OxVpdayvh+v3M02gFkXpg7YuMyAjUSg5mU6qQvY2WDCnMrvZjRTkx n6UIGzeHeJexxPVs5gfztpBjkjpRdz70FQWl4XgOOFc9dI82jJGiCc84iUkZHoXg/C zIUn4N++UQnEoTW5TPK/GsdJbUiw5l22OmN2Uefn/dowgFh9TADFfYKgE1GKLPvVhq Gs0TpV0FTcye4t6o1GmRYA2MxJgvoA3+/qB9rcOKaxUZc6XugGNFQLGYQndMbYcEGr rlhobRrehZZ1SQ5rBX0xu5dHlQNbfezBE1chq8x2gpxJ+IP/YP54X3LleqbqKCMiMb lZYJr5tVbYVnQ== Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by server-vie001.gnuweeb.org (Postfix) with ESMTPSA id DBB9031280F6 for ; Mon, 1 Sep 2025 04:19:45 +0000 (UTC) Received: by mail-lf1-f53.google.com with SMTP id 2adb3069b0e04-55f7ab2a84eso634921e87.1 for ; Sun, 31 Aug 2025 21:19:45 -0700 (PDT) X-Gm-Message-State: AOJu0YxmhtRnq8Fn6rwu/598mqjZrThh1dvr9qV6etvN7mCkbPEAEZv/ 6Px3odrJHPXjK+fce2yDmm/mka3Ya349HjBc9YCxzHLCRGhFqvKPbHvNsZu/OrtKYUqoyAuI6rQ Xegkzm3XMUqsDdt2UeTPMJklwc/F9Ht4= X-Google-Smtp-Source: AGHT+IFtH8Ix+fZ1T+1UDvE9mCAFF3U1eDZ/fPn/tUbuA5FUl+5F+yx0s9QENBJCfttRT13cECqTe1lYmR8nhXnzOMA= X-Received: by 2002:a05:6512:1051:b0:55f:4f46:9f2a with SMTP id 2adb3069b0e04-55f708b5e26mr1352636e87.19.1756700385247; Sun, 31 Aug 2025 21:19:45 -0700 (PDT) MIME-Version: 1.0 From: Ahmad Gani Date: Mon, 1 Sep 2025 11:19:08 +0700 X-Gmail-Original-Message-ID: X-Gm-Features: Ac12FXzQvOGFFm7mKxKd0GoED2pHIP_RpNtp59zJ_pB42Dgal3PcT80exz0v-1U Message-ID: Subject: Request for sandbox isolation testing To: "GNU/Weeb Mailing List" Cc: Ammar Faizi , Alviro Iskandar Setiawan , reyuki@gnuweeb.org, silverwolf@gnuweeb.org Content-Type: text/plain; charset="UTF-8" List-Id: Hi, I've been experimenting with Linux networking and isolation lately [1]. I'm running an experiment that lets people access a Linux system remotely and make use of available resources. It's similar to a VPS, but access is limited to HTTP(S) only. I don't fully trust everyone I give access to; I want to provide a sandboxed/containerized environment that prevents guests from affecting the host. and I ended up using a mix of Docker and Linux network namespaces for isolation. I'd appreciate it if you could try to break out of the container/sandbox. It would be very helpful if you can demonstrate any misconfigurations or escapes that show the sandbox is not isolated enough and allow bad actors to learn about the host environment/system and its local networks. Known risks: No disk/volume quota is currently enforced. The host filesystem is ext4 and --storage-opt isn't supported for this filesystem, see [2]. If a container exceeds available capacity, I plan to delete the container and its volume. Root access in the container mitigated by mapped it via userns-remap in /etc/docker/daemon.json. That means container root does not equal host root. See [3]. I'd like to drop capabilities where possible, but dropping everything prevents pacman inside the container from bootstrapping properly. To summarize, here are defensive actions that have been taken so far: - limiting resources such as file descriptors, pids, cpu and memory usage - no mount point to the host - prevent arbitrary kernel module to be loaded by dropping CAP_SYS_MODULE - root user in container isn't mapped to the root in host (and no --privileged) - the physical network connection is masked with WARP network - since it already use UTS Namespace by default, a user have no idea of the real host name I believe a kernel exploit would be the main realistic way to escape the container; otherwise the configuration should be reasonably isolated, but I want expert confirmation. If you're willing to test, I can send login credentials via encrypted email. It's been a while since I used encrypted email, so I may revisit the ArchWiki for the steps. Thanks, I'll be glad to discuss and provide whatever additional detail you need. [1]: - https://t.me/GNUWeeb/1200828 - https://superuser.com/questions/1922163/how-to-isolate-warp-with-netns-and-connect-it-to-a-docker-container [2]: - https://stackoverflow.com/questions/57248180/docker-per-container-disk-quota-on-bind-mounted-volumes ``` [reyuki@zero ~]$ docker info 2>&1 | grep -i "Storage Driver" -A3 Storage Driver: overlay2 Backing Filesystem: extfs Supports d_type: true Using metacopy: true [reyuki@zero ~]$ ``` [3]: - https://docs.docker.com/engine/security/userns-remap/#enable-userns-remap-on-the-daemon -- Ahmad Gani