public inbox for gwml@vger.gnuweeb.org
 help / color / mirror / Atom feed
* Request for sandbox isolation testing
@ 2025-09-01  4:19 Ahmad Gani
  0 siblings, 0 replies; only message in thread
From: Ahmad Gani @ 2025-09-01  4:19 UTC (permalink / raw)
  To: GNU/Weeb Mailing List
  Cc: Ammar Faizi, Alviro Iskandar Setiawan, reyuki, silverwolf

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

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2025-09-01  4:19 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-09-01  4:19 Request for sandbox isolation testing Ahmad Gani

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox