upvote

points

by insanitybit21 hours ago |
comments
upvoteby dijit19 hours ago|
next
[-]
Escape from docker containers is trivially easy, if you are able to run as the root user in the container itself.

Many (maybe most) containers actually default to running programs as root. Kernel exploit not required.

reply
upvoteby insanitybit13 hours ago|
parent|
next
[-]
I don't think this would change anything even if it were true, which it is not. Running as root in a container opens up tons of footguns but it is not a path out of the container on its own.
reply
upvoteby 13 hours ago|
parent|
[-]
deleted
reply
upvoteby maple314216 hours ago|
parent|
prev|
[-]
If you are given a shell with `docker run -it --rm alpine:3 sh`, can you read the /etc/shadow on the host without kernel exploit? Assuming the docker and kernel are sufficiently update-to-date (e.g. latest Docker on Debian Stable).
reply
upvoteby chlorion14 hours ago|
parent|
[-]
No.

The "root" you get in docker is not actually root outside of the namespace the container in running in.

Assuming no bugs in the kernel, it should not be able to do anything more than the UID that it's mapped from.

reply
upvoteby ptx13 hours ago|
parent|
next
[-]
Does Docker use user namespaces by default? Otherwise root in the container is actually root on the host, from what I read. Correct me if I'm wrong.

(Privileges are still limited by seccomp filters blocking some syscalls, and there's SELinux to block some other stuff, but it's still the actual root user without user namespaces, I think?)

reply
upvoteby insanitybit13 hours ago|
parent|
next
[-]
That's right. Docker still runs without user namespaces by default, which means that root is the same user inside and outside of the container. This does open up attack surface and configuration footguns.

Confinement still leverages dropping some root caps, seccomp, various other namespaces, etc.

reply
upvoteby inigyou12 hours ago|
parent|
[-]
I don't think this is true, otherwise you could just load a kernel module into the host kernel from a container.
reply
upvoteby cyphar9 hours ago|
parent|
next
[-]
Root is not just one thing on modern Linux, almost all in-kernel privilege checks are now gated via (slightly) more fine-grained capabilities and the default capability set for Docker containers disallows module loading (CAP_SYS_MODULE) and the relevant syscalls (namely (f)init_module) are also blocked with seccomp.

People still should use user namespaces (and tools like Podman and Incus do by default) but basic stuff like that is not the reason.

reply
upvoteby insanitybit1 hours ago|
parent|
prev|
next
[-]
There are a million ways to load a kernel module from inside of a container into the host kernel (ie: to trigger a load), but seccomp/ linux caps will block the direct ways (as another commenter notes).
reply
upvoteby physicalecon12 hours ago|
parent|
prev|
next
[-]
It is very possible to load a kernel module into the host from a container.

https://stackoverflow.com/questions/33013539/docker-loading-...

reply
upvoteby tjoff10 hours ago|
parent|
[-]
FYI, looks like you are shadowbanned.
reply
upvoteby ptx10 hours ago|
parent|
prev|
[-]
Presumably Docker's seccomp profile [1] blocks the init_module system call which is used by insmod [2]. Although, looking at the default profile, it seems to explicitly allow it - but maybe only if you have CAP_SYS_MODULE, which I think means running Docker with "--cap-add=SYS_MODULE".

[1] https://docs.docker.com/engine/security/seccomp/

[2] https://tldp.org/HOWTO/Module-HOWTO/x627.html

reply
upvoteby chlorion12 hours ago|
parent|
prev|
[-]
At least podman does if running rootless, I assume docker supports rootless operation as well.

Not sure about running rootful though. I don't really use rootful containers personally.

reply
upvoteby dboreham9 hours ago|
parent|
prev|
[-]
Hmm. Either I've lost my mind, or you're running a different Docker than me, or you're thinking of some strange scenario such as a Mac where docker is actually inside a VM, or you're wrong.

While there is a feature to do with UID mapping, it doesn't actually work/isn't usable/nobody uses it in current docker iirc.

Therefore root in the container very much is root on the host.

reply
upvoteby zamalek4 hours ago|
parent|
[-]
UID mapping is how rootless docker works, so tons of people are using it
reply
upvoteby worthless-trash21 hours ago|
prev|
next
[-]
Some people clearly do use containers as deployment mechanism, with security not in mind.
reply
upvoteby zbentley2 hours ago|
parent|
[-]
s/some/most/

That's not meant to be snide, just true, I think.

reply
upvoteby password432117 hours ago|
prev|
[-]
> They are a security boundary

My mistake, leaving out some adjective one could interpret as a misunderstanding of containers as an effective (etc.) security boundary. Fool me 100+ times and all that.

There must be at least a triple-digit number of CVEs by now demonstratimg that in practice containers are a thinner layer of security (perhaps not quite as thin as the classic recommendation of running SSH on a nonstandard port, but that might be leaning toward the safer side of analogies vs. malicious code!) rather than a boundary like virtualization (not perfect but a best practice for isolation).

reply