3 ms·
No. Isolation has always been a security feature, not a reliability feature. Consider that local privilege escalations are generally (and I'd say correctly) tr
by msbarnett 5y ago
No. Isolation has always been a security feature, not a reliability feature.
Consider that local privilege escalations are generally (and I'd say correctly) treated as critical severity issues. Any general purpose process memory read-isolation leak is a quick route to a local privilege escalation, so how could isolation be anything other than a security feature? In its absence, you might as well run everything as root and there would be no point whatsoever to caring about privilege escalations.
- jcelerier 5y ago> Consider that local privilege escalations are generally (and I'd say correctly) treated as critical severity issues. Any general purpose process memory read-isolation leak is a quick route to a local privilege escalation, so how could isolation be anything other than a security feature? https://xkcd.com/1200/ https://xkcd.com/1200/ > In its absence, you might as well run everything as root this is what 99% of people with a home computer did until windows XP (and even then most people today run under an admin account of some sorts on their computers) isolation between users is only relevant for clusters, it's a super minority usecase versus what is the main thing that matters, home computers which only have one human user anyways. But I guess you'd disagree with Stallman's paragraph at the end here: https://ftp.gnu.org/old-gnu/Manuals/coreutils-4.5.4/html_node/coreutils_149.html https://ftp.gnu.org/old-gnu/Manuals/coreutils-4.5.4/html_nod...
- msbarnett 5y agoYes, I 100% disagree with Stallman's goofy conflation of OS permissions segmentation with aristocracies, and think the idea that the permissions model of the early 1980s is at all workable in the internet era is profoundly, stunningly naive. The XKCD argument misses the point entirely; if someone p0wns your browser, they p0wn your browser, but what we're talking about is allowing every VSCode extension and Docker image someone installs to read your GMail. It's an absolute dipshit idea that would make every current security problem with computing orders of magnitude worse.
- jcelerier 5y ago> but what we're talking about is allowing every VSCode extension and Docker image someone installs to read your GMail. I don't understand, this is already the status quo today. Any vscode extension can access your filesystem and connect to a socket, so it can just pipe your ~/.cache/mozilla to some server in russia, and even read the memory of any of your processes through /proc/$PID/maps. Ditto for any shell script you run, any build script for any software you clone from github before building it, unless you are running Qubes OS.
- msbarnett 5y agoC’mon. Ability to read the cache is obviously a much much lower threat than the ability to read the browser processes’ memory – the browser doesn’t cache your GMail password. Also let’s stop here and admire just how far you’ve shifted the goal posts: we’ve gone from “memory isolation isn’t a security measure it’s actually just for reliability” to “ok sure it’s obviously a security critical measure, but check out this boneheaded RMS rant and also what about the lower threat value data that gets cached, what about that. And do we even need security or can we just go back to the 1980s with our Amigas when everything was cool and advanced persistent threats didn’t exist, man”. Pick a coherent point you’re trying to argue and some kind of intelligible threat model, at least. If we’re concerned about leaking filesystem data, there’s more aggressive sandboxing measures which several OSes employ, but they even more strongly rely on memory isolation, not less. The point, which you seem to have conceded several posts ago, remains: Memory isolation is a security measure, not just or even primarily a reliability issue. Also you don’t seem to understand what you’re trying to talk about, because: > and even read the memory of any of your processes through /proc/$PID/maps This requires root permissions (or for you to have explicitly changed /proc/sys/kernel/yama/ptrace_scope to a non-default value to allow processes to PTRACE_ATTACH to arbitrary non-child processes, which you shouldn’t do on a general purpose internet-facing machine unless you are a clinically insane person) for the obvious reason that this would be incredibly dangerous otherwise. Proving once again my entire point: Memory isolation is a security measure.