starred/Docker-OSX-sickcodes
1
0
Fork 0
mirror of https://github.com/sickcodes/Docker-OSX.git synced 2026-07-22 12:58:38 +02:00
Code Issues 411 Packages Projects Releases Wiki Activity

Hardening of X11 root exposure #73

New Issue
Open
opened 2025-12-29 05:21:30 +01:00 by adam · 8 comments
adam commented 2025-12-29 05:21:30 +01:00
Owner
Copy Link
Copy Source

Originally created by @dylanschmittle on GitHub (Oct 6, 2020).

I have not tested yet, but i was going to try to work this into the setup somehow https://www.elstel.org/xchroot/

Originally created by @dylanschmittle on GitHub (Oct 6, 2020). I have not tested yet, but i was going to try to work this into the setup somehow https://www.elstel.org/xchroot/
adam commented 2025-12-29 05:21:31 +01:00
Author
Owner
Copy Link
Copy Source

@dylanschmittle commented on GitHub (Oct 6, 2020):

may be worth providing some of these flags as well, i am currently using podman and have zero issues with anything https://www.redhat.com/sysadmin/privileged-flag-container-engines

sudo podman run --device /dev/kvm --device /dev/snd -v /tmp/.X11-unix:/tmp/.X11-unix sickcodes/docker-osx:latest

@dylanschmittle commented on GitHub (Oct 6, 2020): may be worth providing some of these flags as well, i am currently using podman and have zero issues with anything https://www.redhat.com/sysadmin/privileged-flag-container-engines **sudo podman run --device /dev/kvm --device /dev/snd -v /tmp/.X11-unix:/tmp/.X11-unix sickcodes/docker-osx:latest**
adam commented 2025-12-29 05:21:32 +01:00
Author
Owner
Copy Link
Copy Source

@sickcodes commented on GitHub (Oct 6, 2020):

I agree we should have more security info.

Especially for VNC net connected guests.

What's different from Docker-OSX is that we're trying to run a full OS inside the OSX guest-guest, as opposed to say, a CMS or web app.

Most users will be using this, in synergy with the host. Drag and drop level relationship.

What needs to be addressed though is multitenants and hosting critical web apps with the Docker-OSX on the same server.

I welcome anyone with security related info to share, submit PRs, open issues, etc. so we can harden the project.

@sickcodes commented on GitHub (Oct 6, 2020): I agree we should have more security info. Especially for VNC net connected guests. What's different from Docker-OSX is that we're trying to run a full OS inside the OSX guest-guest, as opposed to say, a CMS or web app. Most users will be using this, in synergy with the host. Drag and drop level relationship. What needs to be addressed though is multitenants and hosting critical web apps with the Docker-OSX on the same server. I welcome anyone with security related info to share, submit PRs, open issues, etc. so we can harden the project.
adam commented 2025-12-29 05:21:32 +01:00
Author
Owner
Copy Link
Copy Source

@dylanschmittle commented on GitHub (Oct 9, 2020):

ill see what i can whip up this weekend

@dylanschmittle commented on GitHub (Oct 9, 2020): ill see what i can whip up this weekend
adam commented 2025-12-29 05:21:32 +01:00
Author
Owner
Copy Link
Copy Source

@dylanschmittle commented on GitHub (Oct 11, 2020):

Gunna drop this from my notes incase anyone wants to weigh in on this, im thinking brwap-oci or xchroot that way you can set the security maximums and users can set them stiff wither runtime settings without rebuilding.

Containers are simple right?

Policy, Privledges, and Sandboxing

Container Privledge Escalation RH

Seccomp and Sandboxing Google

SE Linux for Containers

cgroupsv1/v2

namespaces

chroot

xchroot

proot

firejail

bubblewrap/bwrap-oci

Qemu/libvirt/lxc Sandbox

fakeroot

breakout

Do-nots

  • Use random public repos

  • Display Forwarding especially X11 and dbus

  • Expose or mount the docker socket (or use runc at all)

  • Running as Root / Net Raw

  • Running with access to exec capable FS

  • Running with access to suid binaries

  • Running with runc

  • Windows Containers

  • Build tools in final image

  • Writing data to the temp overlay

@dylanschmittle commented on GitHub (Oct 11, 2020): Gunna drop this from my notes incase anyone wants to weigh in on this, im thinking brwap-oci or xchroot that way you can set the security maximums and users can set them stiff wither runtime settings without rebuilding. # Containers are simple right? ## Policy, Privledges, and Sandboxing [Container Privledge Escalation RH](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/building_running_and_managing_containers/running-special-container-images_building-running-and-managing-containers) [Seccomp and Sandboxing Google](https://chromium.googlesource.com/chromiumos/docs/+/refs/heads/release-R68-10718.B/sandboxing.md#Sandboxing-Chrome-OS-system-services) [SE Linux for Containers](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/using_selinux/creating-selinux-policies-for-containers_using-selinux#introduction-to-udica_creating-selinux-policies-for-containers) [cgroupsv1/v2](https://man7.org/linux/man-pages/man7/cgroups.7.html) [namespaces](https://man7.org/linux/man-pages/man7/namespaces.7.html) [chroot](https://man7.org/linux/man-pages/man2/chroot.2.html) [xchroot](https://www.elstel.org/xchroot/) [proot](https://proot-me.github.io/) [firejail](https://firejail.wordpress.com/) [bubblewrap/bwrap-oci](https://www.google.com/search?client=firefox-b-1-d&q=bwrap+oci) [Qemu/libvirt/lxc Sandbox](https://sandbox.libvirt.org/quickstart/) [fakeroot](https://wiki.debian.org/FakeRoot) [breakout](https://lwn.net/Articles/781013/) ## Do-nots - Use random public repos - Display Forwarding especially X11 and dbus - Expose or mount the docker socket (or use runc at all) - Running as Root / Net Raw - Running with access to exec capable FS - Running with access to suid binaries - Running with runc - Windows Containers - Build tools in final image - Writing data to the temp overlay
adam commented 2025-12-29 05:21:32 +01:00
Author
Owner
Copy Link
Copy Source

@sickcodes commented on GitHub (Oct 11, 2020):

I'll use some of that to elaborate on security, I have some notes so far. I'll add you as a creditor to the security tab if you don't mind :)

Use random public repos
Partially

Display Forwarding especially X11 and dbus
No dbus anymore, using X11 deliberately

Expose or mount the docker socket (or use runc at all)
Using runc, exposing SSH and screenshare ports

Running as Root / Net Raw
Most using docker with root priv
Running as arch user inside container who is root NOPASSWD

Running with access to exec capable FS
Will check what we are exposing

Running with access to suid binaries
Running with access to /dev/kvm

Running with runc
True

Windows Containers
False

Build tools in final image
Kinda

Writing data to the temp overlay
Passwords? Deliberately forcing users to make their own VNC edition as VNC needs unique password (8 chars max)

@sickcodes commented on GitHub (Oct 11, 2020): I'll use some of that to elaborate on security, I have some notes so far. I'll add you as a creditor to the security tab if you don't mind :) Use random public repos Partially Display Forwarding especially X11 and dbus No dbus anymore, using X11 deliberately Expose or mount the docker socket (or use runc at all) Using runc, exposing SSH and screenshare ports Running as Root / Net Raw Most using docker with root priv Running as arch user inside container who is root NOPASSWD Running with access to exec capable FS Will check what we are exposing Running with access to suid binaries Running with access to /dev/kvm Running with runc True Windows Containers False Build tools in final image Kinda Writing data to the temp overlay Passwords? Deliberately forcing users to make their own VNC edition as VNC needs unique password (8 chars max)
adam commented 2025-12-29 05:21:33 +01:00
Author
Owner
Copy Link
Copy Source

@sickcodes commented on GitHub (Oct 11, 2020):

Most users are using this locally, but there are users who are using it for CI/CD with VNC I will add some VPN instructions or SSH tunneling to make it more secure for them. Or instructions to run behind a VPC

@sickcodes commented on GitHub (Oct 11, 2020): Most users are using this locally, but there are users who are using it for CI/CD with VNC I will add some VPN instructions or SSH tunneling to make it more secure for them. Or instructions to run behind a VPC
adam commented 2025-12-29 05:21:33 +01:00
Author
Owner
Copy Link
Copy Source

@sickcodes commented on GitHub (Mar 18, 2021):

Linked issue: https://github.com/sickcodes/Docker-OSX/issues/209

@sickcodes commented on GitHub (Mar 18, 2021): Linked issue: https://github.com/sickcodes/Docker-OSX/issues/209
adam commented 2025-12-29 05:21:33 +01:00
Author
Owner
Copy Link
Copy Source

@bphd commented on GitHub (Mar 17, 2023):

may be worth providing some of these flags as well, i am currently using podman and have zero issues with anything https://www.redhat.com/sysadmin/privileged-flag-container-engines

sudo podman run --device /dev/kvm --device /dev/snd -v /tmp/.X11-unix:/tmp/.X11-unix sickcodes/docker-osx:latest

It's a good first step to just replace docker with podman, this should be in all the repo. But after that, to really make use of podman, it should stop use "sudo" or "--privilegied" and rather fine tune permissions to create something more secure. 3 years and this repo still use docker. I imagine because it's industry standard, despite just being more problematic

@bphd commented on GitHub (Mar 17, 2023): > may be worth providing some of these flags as well, i am currently using podman and have zero issues with anything https://www.redhat.com/sysadmin/privileged-flag-container-engines > > **sudo podman run --device /dev/kvm --device /dev/snd -v /tmp/.X11-unix:/tmp/.X11-unix sickcodes/docker-osx:latest** It's a good first step to just replace docker with podman, this should be in all the repo. But after that, to really make use of podman, it should stop use "sudo" or "--privilegied" and rather fine tune permissions to create something more secure. 3 years and this repo still use docker. I imagine because it's industry standard, despite just being more problematic
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
documentation
enhancement
following upstream developments
good first issue
help wanted
invalid
pull-request
Mirrored from GitHub Pull Request
 question
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/Docker-OSX-sickcodes#73