Keep in mind that software is moving towards a sandboxed world, especially with containers. Local attack surface is becoming increasingly valuable.
(That said, the same class of attack is in theory possible in the kernel, although the kernel tends to be way more disciplined about stack usage than userspace software.)
Another perfectly valid way of working around the exploits is to just have an installation with no setuid binaries or file capabilities. This is difficult in a general-purpose OS that needs to be backwards compatible with traditional UNIXy things, but usually totally achievable if you're building a machine to run some specific service. (And in particular it should be really easy within a container, such that these attacks would get you neither container root nor host root.)
A contained-process-to-actual-root exploit is basically either going to be an arbitrary code execution vulnerability in the kernel itself, which tends to be referred to as something more dramatic as "local root", or a logic flaw in the container security mechanisms of the kernel itself.
It seems to me that "local root" is quite commonly used for kernel code execution vulnerabilities. There's also the possibility of a flaw in a service running in the init namespace that is exposed to the container.
I don't think these should be written off as "Well, you're screwed anyway" like we tend to do when discussing security against an attacker who has direct physical access to the hardware. Isolated user accounts are widely used as the model for running services because they provide significant (if non-total) benefit.
Isn't that just saying "I don't believe in multiuser systems and/or their security models"...? If so, what specifically do you have against them?
[Core Services] + SSH is generally something you can harden effectively against attacks.
[2903429034902323094230 binaries] is something you generally struggle to maintain security patches/etc on.
The simple fact is, there is just too much attack surface on a vanilla Linux box once you have an account that you can reliably do EVERYTHING you need to do to secure it 24/7/365.
At least imho, given my time constraints/budget.
Does a modern Linux come with that many binaries SETUID?!?
Sorry, I couldn't resist. :P But yea, I see your point. It's a bit sad though; that all these people's hard work (e.g. OP) is all in vain...
Part of the reason people's hard work is in vain is because any time the topic of doing things better comes up, a cluster of developers will insist there's no point in improving e.g. filesystem because "once they're on the box, you're screwed." So it becomes a self-fullfilling prophecy.
In general there seems to be quite diverse opinions out there about "security", and a lot of the space seems occupied by "extreme pragmatics" (or even "anti-intellectuals"). E.g. lots of people feel it's warranted to peddle (simple) falsehoods instead of trying to understand (complex) problems. I can understand it may be the right approach from a day-to-day IT management perspective, but I'm not so sure it's the most viable path towards better security long-term.
Yeah, this is why I had the caveat:
> At least imho, given my time constraints/budget.
The "best" long term path is to have larger security budgets that allow for the objective you and the other folks who dislike my response want. The problem, frankly, is we just aren't there yet.
For instance, our budget for maintaining security is ~5% of the IT budget. A large portion of that goes to perimeter defense appliances (firewalls, barracuda antispam/antivirus filters, etc.) as well as making sure ublock, anti-malware, etc are installed on every machine. The other major chunk ends up in securing WAN-facing services that can be exploited remotely. The last major chunk is user training to get them to stop doing things like pay bills for services we never purchased, clicking on strange links, running strange attachments, etc.
After that, we have no resources to do more than run apt-get update && apt-get upgrade -y for protecting the attack surface once an account is breached. We've got a few things we had to re-compile ourselves manually and break with that process so we moved them out of the package manager for the OS. Our actual applications we build internally also likely have exploitable vulnerabilities if attacked from a local account. Those items never have the budget to be maintained and we certainly wouldn't survive someone taking over a local shell account.
I suspect given this is (roughly) the situation every place I've worked at, its simply too common to be an issue.
The other one I see touted everywhere far too often is "false sense of security." Because improving the security of one thing can't possibly help when there could be a dozen other things that may yet be vulnerable. No, instead of helping, fixing that one thing lulls you into believing you are safe and that alone makes it all less secure. :-)