Traditional advice was you analyze potentially malicious binaries in a VM. I guess its more prudent now to do it on air-gapped systems?
Escaping privileged containers for fun
11–20 of 42 posts
Re: Escaping privileged containers for fun
#12Containers are not a security mechanism. Containers are not a security mechanism. Containers are not a security mechanism. ... Every engineer making a foray into Docker or any similar tech for the first time should be made to write this line x1000 before proceeding.
Containers are a security mechanism. We can say that now. For a long time they weren't, and then it wasn't really clear, but at this point they are. How good are they? Questionable - there are footguns (running privileged) and they rely on the Linux kernel (garbage), but they are a barrier . If you put a process into a container, even a fairly default config'd container, it will require an additional vulnerability fo…
Containers increase the effort for the attacker to put into escaping that container — provided the developers actually run code that doesn't make that easy right of the bat. I have seen to much code where you can really feel the thought of "let's just use docker, then we don't have to think about complicated linux things like priviledges and permissions".
Using containers as an extra layer of security is perfectly fine. Using it as an excuse to not do any other security measures is not.
Re: Escaping privileged containers for fun
#13Containers are not a security mechanism. Containers are not a security mechanism. Containers are not a security mechanism. ... Every engineer making a foray into Docker or any similar tech for the first time should be made to write this line x1000 before proceeding.
I wonder how hard is it to escape a unprivileged container as a non-root user in a container. It seems that many CTF organizers already host their RCE challenge this way.
Re: Escaping privileged containers for fun
#14Earlier quoted context omitted.
If LXD also uses cgroups and Linux namespaces it seems like the differences would be pretty small? Docker also allows custom syscall filtering, unprivileged containers, etc. I think the reality is just that containers will always be imperfect, and you should understand that risk when building systems.
I was under the understanding that docker didn't use user namespaces by default -- so "root" in the container is the same user as "root" outside the container -- but that LXD does. Has that changed?
It doesn't but TBH user namespaces have a mixed record when it comes to security. For example CVE-2022-0185 wasn't exploitable from a standard container unless user namespaces were available allowing additional capabilities to be gained, inside that user namespace (https://blog.aquasec.com/cve-2022-0185-linux-kernel-containe... has more details.
Re: Escaping privileged containers for fun
#15Containers are not a security mechanism. Containers are not a security mechanism. Containers are not a security mechanism. ... Every engineer making a foray into Docker or any similar tech for the first time should be made to write this line x1000 before proceeding.
Containers provide a level of isolation relative to standard Linux processes. Docker style containers were not designed specifically as a security sandbox (IMO) but instead re-use a set of Linux primitives to provide a level of isolation.
One of the good parts about this is that as they use Linux primitives, the level of isolation can be increased relatively easily. Things like --cap-drop=ALL and --no-new-privileges, combined with ensuring the contained process(es) don't run as root can make things better.
It's also important to ensure that the isolation put in place isn't removed. The major case where this happens is that Kubernetes disables Docker's seccomp filter which has left containers running in k8s clusters vulnerable to issues that stock Docker containers were not (CVE-2022-0185 for a recent example).
If I was running truly untrusted processes from unknown people, I probably would not use Docker containers, instead I'd use gVisor or Firecracker.
Re: Escaping privileged containers for fun
#16Earlier quoted context omitted.
Containers are a security mechanism. We can say that now. For a long time they weren't, and then it wasn't really clear, but at this point they are. How good are they? Questionable - there are footguns (running privileged) and they rely on the Linux kernel (garbage), but they are a barrier . If you put a process into a container, even a fairly default config'd container, it will require an additional vulnerability fo…
Containers increase the effort for the attacker to put into escaping that container — provided the developers actually run code that doesn't make that easy right of the bat. I have seen to much code where you can really feel the thought of "let's just use docker, then we don't have to think about complicated linux things like priviledges and permissions". Using containers as an extra layer of security is perfectly fi…
> "let's just use docker, then we don't have to think about complicated linux things like priviledges and permissions"
Honestly, that's fine. What more do you want? For developers to roll their own SELinux and Apparmor profiles? For them to manually implement seccomp filtering? No one does that.
The reality is that no one is choosing between "containers or some other approach", they're choosing between "containers or nothing".
Re: Escaping privileged containers for fun
#17Earlier quoted context omitted.
Containers increase the effort for the attacker to put into escaping that container — provided the developers actually run code that doesn't make that easy right of the bat. I have seen to much code where you can really feel the thought of "let's just use docker, then we don't have to think about complicated linux things like priviledges and permissions". Using containers as an extra layer of security is perfectly fi…
> "let's just use docker, then we don't have to think about complicated linux things like priviledges and permissions" Honestly, that's fine. What more do you want? For developers to roll their own SELinux and Apparmor profiles? For them to manually implement seccomp filtering? No one does that. The reality is that no one is choosing between "containers or some other approach", they're choosing between "containers or…
Hopefully they aren't choosing containers between "containers + insecure app" or "no containers + secure app", thinking containers will secure the app.
Re: Escaping privileged containers for fun
#18I use AppArmour and use Podman rootless for everything that needs to be containerized so it's all good for me anyway :) Fun read! Maybe put an RSS button somewhere so it's easier to subscribe to?
> Podman rootless
This is the way. Docker rootless and podman rootless. A lot less attack surface than running containers as root.
I haven't tried a dedicated user for this though. I'm sure that mounting volumes would get messed up.
Re: Escaping privileged containers for fun
#19Earlier quoted context omitted.
> "let's just use docker, then we don't have to think about complicated linux things like priviledges and permissions" Honestly, that's fine. What more do you want? For developers to roll their own SELinux and Apparmor profiles? For them to manually implement seccomp filtering? No one does that. The reality is that no one is choosing between "containers or some other approach", they're choosing between "containers or…
Hopefully they aren't choosing containers between "containers + insecure app" or "no containers + secure app", thinking containers will secure the app.
Who does that? I have specific apps to run, the choice is to deploy them bare or in containers.
Re: Escaping privileged containers for fun
#20Containers are not a security mechanism. Containers are not a security mechanism. Containers are not a security mechanism. ... Every engineer making a foray into Docker or any similar tech for the first time should be made to write this line x1000 before proceeding.
FWIW, most of the untrusted code execution "platforms" these days use Docker with some hardening (dropped capabilities, syscall filtering, readonly fs etc).
Eg. Repl.it and Rust Playground.