[fictioncircle]

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

[bjornsing]

> [2903429034902323094230 binaries] is something you generally struggle to maintain security patches/etc on.

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

[rodgerd]

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

[bjornsing]

Yea, I get a similar feeling...

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.

[fictioncircle]

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

[clarry]

> "once they're on the box, you're screwed."

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. :-)