public inbox for gwml@vger.gnuweeb.org
 help / color / mirror / Atom feed
From: Ahmad Gani <reyuki@gnuweeb.org>
To: "GNU/Weeb Mailing List" <gwml@vger.gnuweeb.org>
Cc: Ammar Faizi <ammarfaizi2@gnuweeb.org>,
	 Alviro Iskandar Setiawan <alviro.iskandar@gnuweeb.org>,
	reyuki@gnuweeb.org, silverwolf@gnuweeb.org
Subject: Request for sandbox isolation testing
Date: Mon, 1 Sep 2025 11:19:08 +0700	[thread overview]
Message-ID: <CAADvAgr20z0Md2YjySms3TQrvSF0hd9L1SN6Bme8JsRKr1waYg@mail.gmail.com> (raw)

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

                 reply	other threads:[~2025-09-01  4:19 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAADvAgr20z0Md2YjySms3TQrvSF0hd9L1SN6Bme8JsRKr1waYg@mail.gmail.com \
    --to=reyuki@gnuweeb.org \
    --cc=alviro.iskandar@gnuweeb.org \
    --cc=ammarfaizi2@gnuweeb.org \
    --cc=gwml@vger.gnuweeb.org \
    --cc=silverwolf@gnuweeb.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox