Hacker News new | ask | show | jobs
by orthecreedence 3531 days ago
Also, not sure if this is still the case, but Docker's daemon ran as root on the host. Any vulnerability has the potential to give root on the host machine to an attacker. I don't think this has ever happened, but rkt's approach of using a process per container just makes much more sense in a security context (and for containerization in general).
1 comments
fapjacks 3531 days ago
The daemon needs superuser privileges to do its business, but your containers are not running as root. That lives behind the --privileged option and has ample guidance in the documentation against using it.
link
TheDong 3530 days ago
Wrong. Without usernamespacing your containers do run as root. If you type `docker run busybox id` it will print uid=0, and that uid is 0 in the container and out of it.

You are namespaced, so the linux kernel promises that even though you're root, you're not dangerous, and there is syscall filtering and shit going on.... but that historically has not really fared that well!

But your statement is false. You're root with and without privileged. Privileged gives you back CAPABILITIES which are different than USER, so your claim is bullshit.

link
tmzt 3530 days ago
Where in the kernel is 0==uid still privileged? Are there still places where the uid is checked instead of caps?
link
TheDong 3530 days ago
He said "but your containers are not running as root".

That is objectively false.

uid = 0 is "privileged" basically everywhere in the kernel, from filesystem management (reading a file bindmounted in that's owned by root e.g.) to binding to low ports (like 80).

link
fapjacks 3530 days ago
Whatever dude. You keep spreading your FUD. You clearly do not understand what Docker is and what Docker does.
link
TheDong 3529 days ago
Why does anyone care about usernamespacing then? https://docs.docker.com/engine/reference/commandline/dockerd...

As you can see from the docs, it says "the most important security improvement is that, by default, container processes running as the root user will have expected administrative privilege (with some restrictions) inside the container but will effectively be mapped to an unprivileged uid on the host."

This implies the reverse, that if you don't use userns then your process as root in the container will be mapped to a privilege uid on the host.

This is all I'm saying is true. You clearly don't understand what I'm saying.

link