Docker-Security
Docker-Security copied to clipboard
OWASP
Addition to the threat mindmap might be needed
Breaking out of a container might not only be achieved by root processes or (ab)use cases of SETUID/SETGID, but through risky bind mounts of the host file system, too. UID 0 might help with additional permissions in such a scenario, but i'd argue it would still be considered a separate point.
The docker docs even acknowledge it here (search page for "security implications").
Side note: Most english sources call it container breakout instead of container outbreak. Using your favourite search engine with both terms will demonstrate the difference in search result quality.
Hi Lukas,
thanks! @wurstbrot: would you mind making the sources available?
Cheers, Dirk
Hi @gramsimamsi , thank you, changed it to "container outbreak". What do you think about adding "Privilege Escalation in Deamon" or "Exploits" as a leaf of "Container Outbreak" (e.g. dirty cow)?
I will create a separate PR to add source slides so everyone will be able to "copy"/"fork" and change it.
Hi @wurstbrot , sorry for the misunderstanding - "container breakout" is the correct one :)
PrivEsc through daemon is definitely another valid problem. Only problem would be the structure of leafs IMO, since kernel exploits may also be used for container breakouts in a similar way.
...on the other hand, other kernel or daemon exploits might be used for DOS, too.
@gramsimamsi my fault.
"...on the other hand, other kernel or daemon exploits might be used for DOS, too" or network... Therefore, I added a note next to DoS
Please check page 68 again, I improved PrivEsc The structure is also changed due to PrivEsc
In addation, I changed "kernel exploit" to "kernel vulnerability".
Comments?
Looks good so far! I'd add another leaf to Container Breakout though - "privileged containers".
Since we have user namespace remapping in docker + kubernetes, processes can run as root inside a container, but not be root outside the container context (helps in cases where i.e. other vulns allow the container to poke around outside his context).
Privileged containers pose a threat as processes are still considered root outside the container context. Even privileged containers not running as root might pose a threat, as the UID given through a "USER X" line in a dockerfile might map to an existing user on the host with access to more files/resources/...
Hello out there,
thanks for your thoughts.
The idea of the threat modeling chapter was to have classes of threats. Those classes represent vectors, not particular threats. A particular threat is for sure a privileged container. The corresponding class is ~ 'threat through a neighbor container.
Actually I thought to move Timo's mindmap more into my direction rather than adding each particular threat --which comes later in each chapter btw. .
If Timo's mindmap should be extended to include each particular threat the place where it is being displayed seems wrong to me. Or the chapter needs to be extended so that it fits better. Don't know yet whether I would like the latter though. There would be needed at least a explanatory paragraph why all of a sudden the particular threats are being shown.
Excuse my lack of response. I am currently in the middle of nowhere with limited time and internet access. I'll spend more time on this from August on.
Cheers, Dirk
So risky bind mounts are considered covered by "processes as root" in https://raw.githubusercontent.com/OWASP/Docker-Security/master/assets/threats.png as of today — is that correct?
@hartwork: @drwetter announced to create an other one and will not maintain the current one. Therefore, I have not placed my updates here. Everyone can copy and adjust the mind map, just for your information.
Please find the current mind map on https://docs.google.com/presentation/d/1SWCyscCQ0YGW3_Y6vCwI4ZY_Q5-TOQ-eoVZaT6qwofc/edit?usp=sharing slide 89.
Does that solves your question?
Does that solves your question?
Yes! (So this ticket may not be as done as it appeared to me earlier.)
For a direct link to page 89 if anyone needs it: https://docs.google.com/presentation/d/1SWCyscCQ0YGW3_Y6vCwI4ZY_Q5-TOQ-eoVZaT6qwofc/edit#slide=id.g5d977fc8c0_6_3103
@hartwork : If a ticket is done it'll be closed ;-)
I have a started a threat model map I created for my talk in Amsterdam (https://www.owasp.org/images/d/df/Dirk_Wetter_-_Docker_Top10-AMS.pdf). It is in SVG format (that's what I meant by sources) but still is not as good as it wanted to be. So Timo's is for now the working revision now, despite the wording which @gramsimamsi correctly pointed out.