* 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