Which is equivalent to running userspace outside the initial user namespace, and trivially gives you and environment that has been audited to work for an untrusted root.
Just a few more things won't work that way but I would not mind a little help flushing out the things that we can trust less than fully privileged users with doing.
As for msrs. Make no mistake someone will eventually implement rdmsr(HALT_AND_CATCH_FIRE). So I can't believe even reading msrs is safe.
Posted Mar 14, 2013 11:33 UTC (Thu) by spender (subscriber, #23067)
[Link]
Key phrase being "this specific issue". Several vulnerabilities have already been introduced by the addition of unprivileged user namespaces. It speaks to the trustworthiness of the code that these were found through casual inspection of a few lines of code and a very dumb fuzzer (trinity) -- it has not been exposed to serious security auditing. The author of the above exploit said it was the easiest he has ever written.
You should also know that the existing kernel exploit payloads for granting root privilege also break out of user namespaces without modification.
So the end result is opening up more attack surface to the most vulnerable part of the system, and soon on all distros you will have no choice but to be exposed to it. It's just broken security design.
-Brad
The trouble with CAP_SYS_RAWIO
Posted Mar 19, 2013 1:57 UTC (Tue) by wahern (subscriber, #37304)
[Link]
"So the end result is opening up more attack surface to the most vulnerable part of the system, and soon on all distros you will have no choice but to be exposed to it."
Unfortunately, "less code, simpler code" is not one of the competing security paradigms in Linux Land.
