OWASP / Docker-Security

Getting a handle on container security
https://owasp.org/www-project-docker-top-10/
Other
625 stars 130 forks source link

Addition to the threat mindmap might be needed #9

Open gramsimamsi opened 5 years ago

gramsimamsi commented 5 years ago

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.

drwetter commented 5 years ago

Hi Lukas,

thanks! @wurstbrot: would you mind making the sources available?

Cheers, Dirk

wurstbrot commented 5 years ago

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.

gramsimamsi commented 5 years ago

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.

wurstbrot commented 5 years ago

@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?

gramsimamsi commented 5 years ago

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/...

wurstbrot commented 5 years ago

@gramsimamsi thank you! Please check the mind map on slide 74 again.

gramsimamsi commented 5 years ago

You're welcome - looks great now, I've got nothing more to add :)

drwetter commented 5 years ago

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

hartwork commented 4 years ago

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?

wurstbrot commented 4 years ago

@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?

hartwork commented 4 years ago

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

drwetter commented 4 years ago

@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.