This sandboxing for services provides similar isolation as various container runtimes. Plus due to integration with systemd things like live update without dropping a single connection is possible to implement with straightforward application code.
Whereas this feature is explicitly a sandboxing feature, and the needed permissions are enumerated by the service file.
Podman does not run as root, and thus neither do the containers.
I tested it out on my development backup laptop; I usually use Docker-CE on my main MBP. Podman and Buildah were able to deal with all my individual containers, but their replacement for Docker-Compose failed on all my compose environments, and the errors were not helpful. I ended up installing an unsupported version of Docker-CE, and everything worked fine.
* Podman https://podman.io/
* Buildah: https://github.com/containers/buildah
* Podman-Compose: https://github.com/containers/podman-compose
It doesn't matter that the daemon runs as root, it starts processes in an a way that prevents them from interacting with other daemons, filesystems, etc. resources.
You don't quite understand docker correctly :)
cgroups are used mostly for resource limits, not for sandboxing (aka namespacing).
docker by default does have a slightly more lax security posture than systemd or lxc (i.e. a default set of capabilities that isn't explicitly enumerated and a focus on UX over tweaking them, no usernamespaces by default, etc), though you're right that it is largely meant to be a secure sandbox for untrusted containers, as long as you know hat you're doing.
cgroups can be used without namespaces, and the reverse is also true. Both of them are part of linux container implementations (like lxc and docker), but for an easy example, systemd uses cgroups for every service, and only uses namespaces for ones you very explicitly turn them on for.
Don't quote me on this, but I also think cgroups landed in the kernel many years before namespaces did.
[0]: https://blog.jessfraz.com/post/containers-zones-jails-vms/
It's not enough that a system has the capability to do something; Ideally it needs to be well documented, easy to use correctly, difficult to use incorrectly, repeatable, and have it's correct usage verifiable. With logging and monitoring available.
When you have a piece of software you want to sandbox.. how exactly are you going to do it? What are the steps? Are they going to be easy for other people to follow and understand what is going on? How do you know it's working correctly?
These sorts of things matter. Not just in terms of usability, but also security. Having the same limitations and kernel hooks underneath doesn't make sandboxing implementations identical. it's still very much possible to have one that is objectively better then another.
I don't know if this is the best implementation, but it's certainly nice that if you are using Linux you probably have it available already. Out of the box.
An interesting question would be integration with other features like SELinux or seccomp, since those are commonly punted on but make a huge difference in security.