61–70 of 102 posts
Is this something that non-privileged containers mitigates? Curious what the big barriers are to this. I know they exist, but aren't used widely...I assume because some functionality doesn't work.
User namespaces which is setup such that uid's in the container are not mapped to any in-use uids on the host is needed.
Earlier quoted context omitted.
Vulnerabilities don't get weeded out by time like radioisotopes decaying. Vulnerabilities get weeded out by attention, and attention happens when people use a system in production to protect a high-value target. Jails haven't been used to protect as many high-value targets as Linux containers have. This is not a comment on the technical quality of jails. It may well be a comment on the world's anti-FreeBSD prejudice.…
> Jails haven't been used to protect as many high-value targets as Linux containers have This is not true in my experience at all. It may be true that it hasn't been in use at startups until Docker came out, but a few large, established companies I've worked at absolutely used Jails or Zones to protect their most valuable IP. And have been for a long time.
The distinction here is that people are running containers in the cloud and also often running untrusted code (e.g. vendor software, random exciting open-source things) inside containers, and collocating those with high-value targets in other containers. And large, established companies are doing that now just as much as startups are.
If I am understanding the CVE correctly, you need to be able to launch privileged containers with an attacker-controlled image where the container user is root and not namespaced (i.e., the same root as the outside root user). How is this not "on the wrong side of an airtight hatch[1]"?
Am I missing something here? If you can start privileged containers, why not just execute evil.exe directly?
[1]: https://blogs.msdn.microsoft.com/oldnewthing/20060508-22/?p=...
> However, it is blocked through correct use of user namespaces (where the host root is not mapped into the container's user namespace). In other words, this won't affect anyone who understands the implications of running a process as root. Unfortunately, the sad truth is that most people I've come across who have "lots of experience" with implementing Docker containers, do not even understand the basics of how they…
We looked at this at $work and got into a serious rabbit hole about how exactly Linux capabilities work. I think if I started asking interviewees to explain permitted vs. effective capability sets and how file and process capabilities differ, I'd never hire anyone. (And I think to figure out yourself how to "correctly configure" a container, you need to have at least some understanding of that.)
Hey all - Seth from Google here. Please let us know if you have any questions regarding GKE or questions about the upgrade process. I'm also happy to escalate any feedback to our internal product and engineering teams. Here's link to our security posting with more information and upgrade procedures: https://cloud.google.com/kubernetes-engine/docs/security-bul...
I'm interested in why COS is unaffected - is it due to the read-only root filesystem?
Not that this shouldn't be patched and all, but this seems like it is being treated with more urgency that is required. If I am understanding the CVE correctly, you need to be able to launch privileged containers with an attacker-controlled image where the container user is root and not namespaced (i.e., the same root as the outside root user). How is this not "on the wrong side of an airtight hatch[1]"? Am I missing…
[1] https://docs.docker.com/engine/reference/commandline/run/#fu... [2] https://docs.docker.com/engine/security/non-events/
Not that this shouldn't be patched and all, but this seems like it is being treated with more urgency that is required. If I am understanding the CVE correctly, you need to be able to launch privileged containers with an attacker-controlled image where the container user is root and not namespaced (i.e., the same root as the outside root user). How is this not "on the wrong side of an airtight hatch[1]"? Am I missing…
I think my OS is on a read only filesystem though, and maybe I've got it namespaced correctly as well, but still it's pretty dangerous.
Not that this shouldn't be patched and all, but this seems like it is being treated with more urgency that is required. If I am understanding the CVE correctly, you need to be able to launch privileged containers with an attacker-controlled image where the container user is root and not namespaced (i.e., the same root as the outside root user). How is this not "on the wrong side of an airtight hatch[1]"? Am I missing…
> However, it is blocked through correct use of user namespaces (where the host root is not mapped into the container's user namespace). In other words, this won't affect anyone who understands the implications of running a process as root. Unfortunately, the sad truth is that most people I've come across who have "lots of experience" with implementing Docker containers, do not even understand the basics of how they…
I think it's subtler than that. It is mostly safe to run a contained process as "root" because in theory the ways that root access can be exercised is highly sandbox by the use of various namespaces, as well as things like capability restrictions (you generally don't have CAP_SYS_ADMIN or a few others), limited syscall attack surface (you generally have a syscall allowlist via seccomp-bpf), etc. Yes, it's wrong to no…
> We looked at this at $work and got into a serious rabbit hole about how exactly Linux capabilities work. I think if I started asking interviewees to explain permitted vs. effective capability sets and how file and process capabilities differ, I'd never hire anyone. (And I think to figure out yourself how to "correctly configure" a container, you need to have at least some understanding of that.)
I think you've hit the nail on the head. I only ask those interview questions because I believe it's important to find out just how much a candidate understands. I have to admit I've let some of these things go, otherwise I'd never hire anyone either. I think in the end what it comes down to is that Docker is an ambitious project that is somewhat flawed from a security perspective. There have been numerous namespace vulnerabilities to date and I expect there will be plenty more found in the future.
Earlier quoted context omitted.
Yes. The lxc commit[1] states that this issue only affects privileged containers. No CVE has been issued for lxc because they consider privileged containers to be insecure. In my experience unprivileged containers work for most tasks, but there is breakage in some areas. Usually the issues are simple to resolve, like disabling OOM adjustments in systemd or changing the idmap range in winbind to be within the namespac…
I've also written a smallish blogpost about this CVE. I'm a LX{C,D} maintainer and I've worked with Aleksa the runC maintainer together on a fix for this CVE: https://brauner.github.io/2019/02/12/privileged-containers.h...
IIUC, using Docker's userns-remap would protect against this CVE by making the containers run unprivileged (container's id 0 != host's id 0) and should generally be the industry's best practice.