Rewrite rootless page 'Why' section

[NthPortal]

Simplify the 'Why' section of the rootless page.

Explain the rationale for using rootless mode better, and at the same
time be clear that the added security has trade-offs.

Remove the condescension that was present in the prior explanation.

---

I don't think condescension is ever okay, even if the below was not the case.

The previous threat model did not take into account compromise of either your infrastructure or of upstream infrastructure. In the latter case, the compromised application (let's say homeassistant) still may still need to utilise a priv-esc vuln, although given their total control of application binaries, it's by no means out of the question that such a vuln was lined up with infrastructure compromise. in the former case, the malicious container already has root and essentially arbitrary vulns to exploit. in both cases (particularly the former), rootless deployment provides significant security improvement.

[thespad]

The fact that you have immediately conflated rootless and non-root containers is the reason we had the extensive explanation in the first place. Nothing in that document covers running rootless, only running rootful containers as a non-root user.

[NthPortal]

I would like to congratulate you on running out my patience so quickly.

The underlying problems are, in order of importance:

• The text of that section of the page is condescending. This is harmful and wrong, and also arguably against the code of conduct.
• The thread model it describes is bad.

For posterity and context, I did not in fact conflate rootless mode with setting the user to a non-root user when running a container; I mistakenly thought the page concerned rootless mode.

In spite of me being confused about the subject of the page, both of the things I pointed out are still true. The threat model still failed to consider compromise of your infrastructure. Running a container as a non-root user increases the likelihood that an attacker (who has complete control of the image) will need both a priv-esc vuln and a container escape vuln, though it is worth noting that not all container escape vulns need a separate priv-esc vuln.