Classic Confinement request for "Raind"

store-requests classic-confinement
1

To make the review of your request easier, please use the following template to provide all the required details and also include any other information that may be relevant.

  • name: raind

  • description: Raind is an open-source local container runtime and lightweight workload orchestrator for Linux. It provides Docker-like container commands and Kubernetes-inspired resources. Raind is intended for local development, testing, and experimentation with container workloads, including image management, OCI-style container execution, networking, traffic observation, and policy-based communication control.

  • snapcraft: Raind/snap/snapcraft.yaml at main · shizuku198411/Raind · GitHub

  • upstream: GitHub - shizuku198411/Raind: Workload-Centric Container Runtime · GitHub

  • upstream-relation: I am the upstream author and maintainer of the Raind project, and I am also the publisher of this snap.

  • supported-category: tools for local, non-root user driven configuration of/switching to development workspaces/environments

  • reasoning: Raind requires classic confinement because it is not a regular desktop or server application that only needs access to a fixed set of files, sockets, or devices. Raind is a local container runtime and lightweight workload orchestrator. Its core purpose is to create and manage Linux container execution environments on the host.

    Raind needs to perform container-runtime operations such as:

    • creating and joining Linux namespaces for workloads

    • setting up container root filesystems, bind mounts, overlay-backed layers, and root switching for container processes

    • managing cgroup v2 subtrees for container processes under /sys/fs/cgroup/raind

    • creating bridges and veth pairs, moving interfaces into container network namespaces, assigning container IP addresses and routes, and configuring DNS behavior

    • configuring NAT, FORWARD, DNAT, and policy rules for published ports and container traffic

    • executing user-specified container commands inside the target namespaces and root filesystem

    • supporting user-requested bind mounts and hostPath-style volumes, where the host paths are selected at runtime by the user rather than known statically at snap build time

    I evaluated a devmode build to identify the accesses that would be blocked by strict confinement. In devmode, Raind was able to start the daemon, pull images, create a network, start a rootful nginx container, run container exec, and create a container with a published port. However, the audit logs showed many AppArmor/seccomp policy events for operations that are core to Raind’s runtime behavior and are only allowed because the snap was installed in devmode.

    The collected evidence includes AppArmor/seccomp events for:

    • cgroup v2 access under /sys/fs/cgroup/raind

    • execution of networking tools such as ip and iptables/nftables helpers

    • netlink/network operations used for bridge, veth, routing, and namespace setup

    • mount-related operations used by the container runtime

    • nsenter/runtime process execution paths used for container exec

    • snap namespace visibility issues for user-specified bind mount paths such as /tmp/..., where the daemon could not see a host path that exists from the user’s shell

    These are not optional convenience features. They are the basic mechanisms by which Raind creates and manages local container workloads.

    Existing strict confinement interfaces are not sufficient for this snap. Interfaces such as network, network-bind, network-control, system-files, personal-files, and home can cover specific categories of access, but Raind needs to combine dynamic namespace creation, mount/rootfs management, cgroup management, dynamic hostPath/bind mounts, low-level network namespace setup, firewall/NAT rule management, and arbitrary workload execution inside containers. The required paths and resources are not all known statically in advance, because they depend on the images, container definitions, bind mounts, ports, networks, and workload resources requested by the user at runtime.

    The requirement is not simply to access arbitrary host files or to execute host-provided helper binaries. The requirement is to operate as a local container runtime that creates and manages kernel isolation primitives and workload execution contexts on behalf of the user. Under strict confinement, snapd’s AppArmor/seccomp policy would prevent these core runtime operations or make the runtime unable to correctly interact with the host namespaces, cgroups, networking stack, and user-selected bind mount paths.

    For this reason, Raind cannot provide its intended container runtime functionality under strict confinement, and classic confinement is required.

    The upstream repository is public. The current Snap Store revision may temporarily lag behind the latest upstream main branch while the classic confinement review is in progress. The snap is built from the same upstream project and the snap packaging files are maintained in that repository.

I understand that strict confinement is generally preferred over classic.

I’ve tried the existing interfaces to make the snap to work under strict confinement.

Note that snappy-debug can be used to identify possible required interfaces. See https ://snapcraft.io/docs/debug-snaps for more information.

2

This request has been added to the queue for review by the @reviewers team.

3

Hey @seiji_matsuoka

It is plausible that there are technical reasons why raind needs classic to work properly in all scenarios, but please note that classic confinement is a sensitive matter and it is reserved for mature, well-known applications published by mature, well-known entities. As of today, I believe that raind doesn’t meet this criteria because of the following reasons:

  • The project seems to be very fresh, according to the upstream repository

  • The projects seems to have little/none community around according to upstream repository (contributors, issues, PRs, etc.)

  • I could not find evidences that the project has a strong user base currently

Thus, considering these factors, I think raind should not get classic confinement as of now.

4

Hi @jslarraz, Thank you for the review and for the detailed explanation.

I understand your concerns. As you pointed out, Raind is still in an early stage as a project, and it currently does not yet have strong community adoption, contributors, issues, PRs, or other public signals that would demonstrate a mature user base.

I also understand that classic confinement is a sensitive matter and that technical justification alone may not be sufficient without enough project maturity and trust signals.

For now, I will continue improving the project itself, including documentation, releases, testing, and overall project maturity, and I will also work on building a community and user base around Raind. Once the project has matured further and has stronger public adoption signals, I may request classic confinement again.

Thank you again for taking the time to review the request.