Af an attack can escape a container a lot of companies worldwide are going to need to patch a 0-day. I do not expect that to be part of my threat model for self-hosted services.
this post was submitted on 15 Jul 2025
29 points (93.9% liked)
Selfhosted
50062 readers
354 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 2 years ago
MODERATORS
Woah, no. Sure escaping via a kernel bug or some issue in the container runtime is unexpected, but I "escape" containers all the time in my job because of configuration issues, poorly considered bind mounts, or the "contained" service itself ends up being designed to manage some things outside of the container.
Might be valid to not consider it with the services you run, but that reasoning is very wrong.
I guess I should define my threat model first. Your answer pulls me towards a single user though
Companies don't typically host multiple containers on the same host. So having a different user for them is less important than securing the connection between machines, since a given biat isn't particularly interesting. Attackers will still try to break out, so they have a backup.
As a self-hoster, you typically do the opposite. You run multiple services on the same host, and the internal network isn't particularly secure. So you should be focusing more on mitigating issues, and having each service run as an unprivileged user is one fairly easy way to do that.
The generally don't containerize things because I'm too old and crusty, but segregating over several users is basically how it's been done for ages, and while it may not be particularly useful in your case, I consider it a reasonable best practice that costs you nothing.
It's always effort vs risk.
Since it's a do once and forget kind of thing I'd rate effort rather low.
As for risk in the worst case scenario a single service being compromised means all of them are with the attacker getting access to everything those services can access, including all the credentials. Will you make an effort to be on top of all the updates for all services?
As far as I'm concerned: At home all containers for each service get a separate user. At work every container does.
One if my clients got hacked via an insecure application, that was used to get a shell, to then escalate to root via docker. Luckily it was a white hat team we hired.
Is it worth it to go rootless? Depends on your threat model.
For my home setup I don't bother.
I am already running rootless podman. My question is more about dedicated service users vs single user to run everything, still in rootless podman. I like podman and its integration with systemd to manage the life cycle of the container compared to docker.
It's not going to make a meaningful difference in your threat model and it will cause a lot of hassle for extra configuration and broken docker images, so I wouldn't bother.
There is some nice tooling for transparent user name spaces coming down the pipeline in Kubernetes which will be a nice 0-effort security upgrade, but if you don't have the tooling, I would say it's not worth it.
https://kubernetes.io/docs/concepts/workloads/pods/user-namespaces/
Unfortunately it's right that containers break. Mastodon for instance will not run under a non priviledged user
I guess I will try with a k3s on my workstation, but for a single NAS, I am not sure any kubernetes distribution is useful for now :)
Kubernetes is great for single nodes! It definitely is more advanced than docker compose, but it's actually not hard at all if you read through the documentation. It definitely makes running containers easier in the long run.
Here is my git repo for my big Kubernetes cluster at home: https://codeberg.org/jlh/h5b/src/branch/main/argo/custom_applications
It started out as just a NFS server and a Kubernetes server running on Proxmox in 2021.