Rootless containers have privilege escalation risks of their own. The problem is the unprivileged_userns_clone sysctl, which rootless containers rely on, has historically been a big source of local privilege escalations. The most recent attack I'm aware of is CIFSwitch.
Securing Services with Rootless Containers
21–30 of 40 posts
Re: Securing Services with Rootless Containers
#22Earlier quoted context omitted.
This whole privileged port thing is an outdated convention from the time when Linux ran on mainframes. Depending on your use case, it can be perfectly fine to lower it. I have set to `net.ipvX.ip_unprivileged_port_start = 80` on my server so that I can run rootless containers without extra privileges and have them bind to ports 80 and up.
Nits: It's a Unix convention (not just Linux), and Unix traditionally ran on minicomputers (not mainframes). Mainframes had their own specialized OSes, although some could run Unix in a partition or virtual machine.
I think that "Linux ran on mainframes" was said in jest. Even though Linux runs on mainframes pretty well even now.
Re: Securing Services with Rootless Containers
#23I'd still rather use docker. I don't mind that the daemon runs as root because there are some things that you need root for anyways! Like binding to privileged ports or setting up networks (use `internal: true` and the daemon will automatically set up iptables rules that limit traffic). I deploy docker compose files with ansible so everything comes with built in security defaults like rootless, dropped caps, no new p…
Give your binary CAP_NET_BIND_SERVICE capability, and run it as a regular user. Almost no daemons need to run as root.
Re: Securing Services with Rootless Containers
#24I'd still rather use docker. I don't mind that the daemon runs as root because there are some things that you need root for anyways! Like binding to privileged ports or setting up networks (use `internal: true` and the daemon will automatically set up iptables rules that limit traffic). I deploy docker compose files with ansible so everything comes with built in security defaults like rootless, dropped caps, no new p…
I get the savings of Distroless, but when you have an issue it's a pain to debug.
copy the single busybox statically linked binary into a container, and you can create a bunch of symlinks for its tools that you want to use (this is how busybox container itself works)
makes it trivial to do the dhi/rootless thing but do ad-hoc debugging and then remove the debugging tools entirely, leaving no trace/bloat behind (just one file)
Re: Securing Services with Rootless Containers
#25Personally I still think this is not enough, and we really need full generalized (not AI-only) microvm support built into docker/podman, like yesterday. Currently it's difficult to even get a hold of a properly configured minimal kernel (or time-consuming to try to build one) and all the right command-line incantations to even start a one-off microvm using say, qemu, with all the proper storage/networking/etc. bits o…
I'm all ears, would love to improve smolvm into the right solution for this.
Re: Securing Services with Rootless Containers
#26Personally I still think this is not enough, and we really need full generalized (not AI-only) microvm support built into docker/podman, like yesterday. Currently it's difficult to even get a hold of a properly configured minimal kernel (or time-consuming to try to build one) and all the right command-line incantations to even start a one-off microvm using say, qemu, with all the proper storage/networking/etc. bits o…
Maybe this here helps (I have not tried yet): https://github.com/virtkit-dev/virtkit
I wanted to try it but it seems it requires krun which does not have a readily-available package on ubuntu that I could find, and I didn't feel like compiling it.
Re: Securing Services with Rootless Containers
#27[dead]
Re: Securing Services with Rootless Containers
#28Personally I still think this is not enough, and we really need full generalized (not AI-only) microvm support built into docker/podman, like yesterday. Currently it's difficult to even get a hold of a properly configured minimal kernel (or time-consuming to try to build one) and all the right command-line incantations to even start a one-off microvm using say, qemu, with all the proper storage/networking/etc. bits o…
I'm all ears, would love to improve smolvm into the right solution for this.
Well for starters, all the single binaries I made of various distros a month ago, simply don't work anymore for no obvious reason. Trying to execute the process silently exits after about 10 seconds with a 0 exit code and no output, shell or anything at all, and no errors. I have absolutely no idea what to do now.
Re: Securing Services with Rootless Containers
#29Earlier quoted context omitted.
just curious why you'd bind to a priv port inside of a container.
This whole privileged port thing is an outdated convention from the time when Linux ran on mainframes. Depending on your use case, it can be perfectly fine to lower it. I have set to `net.ipvX.ip_unprivileged_port_start = 80` on my server so that I can run rootless containers without extra privileges and have them bind to ports 80 and up.
I've read that privileged ports was created as a trust model, so users connecting to a service using a privileged port would know that service was started by root on that server and therefore could be trusted. I always felt this was a bit wierd though, maybe I was missinformed, or maybe priviliged ports was already a thing and was just leveraged this way?
Re: Securing Services with Rootless Containers
#30Personally I still think this is not enough, and we really need full generalized (not AI-only) microvm support built into docker/podman, like yesterday. Currently it's difficult to even get a hold of a properly configured minimal kernel (or time-consuming to try to build one) and all the right command-line incantations to even start a one-off microvm using say, qemu, with all the proper storage/networking/etc. bits o…
Have you tried podman with the crun OCI runtime and `--annotation=run.oci.handler=krun`?