MR: Pending <!-- The first line of the MR must be one of the following: 1. `MR: Pending` 2. `MR: <MR link with trailing +>`, and the first description line of the MR should be `Issue: <Issue link with trailing +>` 3. `MR: No MR` For more context, see: https://about.gitlab.com/handbook/engineering/development/dev/create/ide/index.html#1-to-1-relationship-of-issues-to-mrs --> <!-- The following sections should be filled out as part of the refinement process before the issue is prioritized. For more context, see: https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#2-pre-iteration-planning-meeting --> ## Description [Sysbox](https://github.com/nestybox/sysbox) is a container runtime (a specialized "runc") that enhances containers in two key ways: - Improves container isolation: - Linux user-namespace on all containers (i.e., root user in the container has zero privileges on the host). - Virtualizes portions of procfs & sysfs inside the container. - Hides host info inside the container. - Locks the container's initial mounts, and more. - Enables containers to run same workloads as VMs: - With Sysbox, containers can run system-level software such as systemd, Docker, Kubernetes, K3s, buildx, legacy apps, and more seamlessly & securely. - This software can run inside Sysbox containers without modification and without using special versions of the software (e.g., rootless variants). - No privileged containers, no complex images, no tricky entrypoints, no special volume mounts, etc. Explore how we can use Sysbox to be able to run `sudo` inside the workspace and how howe we can then use it for building and running containers inside the workspace. ## Acceptance Criteria - [x] User can run `sudo` commands inside the workspace - e.g. `apt update`/`sudo apt update`. - [x] User can build containers from Dockerfile inside the workspace. - [x] User can run a container inside the workspace. - [x] The solution should not result in privilege escalation. ## Technical Requirements TODO: Fill out or delete [If applicable, please list out any technical requirements for this feature/enhancement.] ## Design Requirements TODO: Fill out or delete [If applicable, please provide a link to the design specifications for this feature/enhancement.] ## Impact Assessment TODO: Fill out or delete [Please describe the impact this feature/enhancement will have on the user experience and/or the product as a whole.] ## User Story TODO: Fill out or delete [Provide a user story to illustrate the use case for this feature/enhancement. Include examples to help communicate the intended functionality.] <!-- Replace with other type, e.g. bug or maintenance, if appropriate --> <!-- Replace with other subtype if appropriate --> <!-- By default, all issues start in the unprioritized status. See https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#-remote-development-planning-process --> <!-- For simplicity and to avoid triage bot warnings about missing workflow labels, we will default to issues starting at the refinement phase -->