4 ms·

I'm a grumpy old man on the internet.... let's just get that out of the way The root cause is NOT capitalism, nor is it users, Microsoft, or even CrowdStrike.

I'm a grumpy old man on the internet.... let's just get that out of the way The root cause is NOT capitalism, nor is it users, Microsoft, or even CrowdStrike. You can't legislate, regulate, or "be more careful next time" your way out of this. Hell, blaming the users won't even work. Here are 3 stories: --- Imagine yourself as an inspector for the Army. The 17th Fortress has exploded this month, and nobody can figure out why. You've checked all the surviving off-site records, and are reasonably sure that the crates of dynamite that used to make up the foundations and structure of the cart were properly inspected, and even updated on a regular basis. You more closely inspect the records, looking for any possible soldier or supplier who might have caused this loss. It might possibly be communist infiltration, or one of those pacifists! You encounter an old civilian, who remembers a time when forts were built out of wood or bricks, and suggests that. But he's not a professional solder, what could he know. --- Imagine you're a fire inspector. You've been to your 4th case this month of complete electrical network outage. This time, the cause seems to be that Lisa Douglas at Green Acres had Eb Dawson climb the pole, and he plugged in one too many appliances to the electricial. If only there were a way to make sure that an overload anywhere couldn't take down the grid, and ruin so many people's days. You desperately want a day without house fires, and so many linemen being called out to test and repair circuits before connecting them back to the grid. It will take some time before the boilers and generators get back on line from their cold re-start. In the mean while, business in town has ground to a halt. The paperwork and processes to track and certify each appliance doesn't seem efficient. There's this grumpy old guy who talks about fuses and circuit breakers, but he's just a crank. --- The United States found itself embedded in yet another foreign entanglement in VietNam. There was a severe problem planning air strikes, because there were multiple sources required to plan them, and no single computer could be trusted with both of them. The strikes themselves were classified, but the locations of the enemy radar installations couldn't be trusted to the computers, because they were occasionally accessed by enemy sources. Thus the methods and means of locating the enemy radar equipment could become known, and thus rendered ineffective. A study was done[1], and the problems were solved. There were systems based on the results of these studies[5], and they worked well.[2] Unfortunately, people thought that it was un-necessary to incorporate these measures, and they defaulted to the broken ambient authority model we're stuck with today. Here's some more reading, if you're interested.[3] --- If you're bored... I've even got a conspiracy theory that explains how I think we actually got here, it it wasn't simply historical forces (which I think it was, 95% certainty).[4] If true, those forces would still be here today, actively suppressing any such stories. [1] https://csrc.nist.rip/publications/history/ande72.pdf https://csrc.nist.rip/publications/history/ande72.pdf [2] https://srl.cs.jhu.edu/pubs/SRL2003-02.pdf https://srl.cs.jhu.edu/pubs/SRL2003-02.pdf [3] https://github.com/dckc/awesome-ocap https://github.com/dckc/awesome-ocap [4] https://news.ycombinator.com/item?id=40107150 https://news.ycombinator.com/item?id=40107150 [5] https://web.archive.org/web/20120919111301/http://www.albany.edu/acc/courses/ia/classics/belllapadula1.pdf https://web.archive.org/web/20120919111301/http://www.albany...

nrr 2y ago
I don't disagree that the prevailing ambient authority model is less than ideal, but I'm left scratching my head at how capability security would solve the more acute problem we're facing. Of particular note, the kinds of ransomware compromise that lead to organizations asking underwriters to sell them cybersecurity insurance policies wouldn't immediately be thwarted by moving to capabilities. If a principal has valid requisite pointers to the resources they need to do their job, they have valid requisite pointers to the resources that a cryptolocker needs to cause disaster. It's those cybersecurity insurance policies (or regulatory frameworks, where those exist) that ultimately drive the decisions to implement EDRs.
- mikewarot 2y ago
  Who would trust the code that the ransomware sneaks use with all of the resources of their system? You can hand $5 over to someone without risking your life savings, surely you could do the same to hand over a temporary folder to run a random piece of code from the internet, and not your full administrator credentials. Capabilities change things in a profound way. They make it trivial to run any old code, yet not have to ever trust it.
  - nrr 2y ago
    The thing that still puzzles me is how we determine which workload gets which capabilities. On Plan 9, I took a lot of glee in rfork()ing my way into a tightly curated namespace that disallowed subsequent use of mount and bind, but that was a deliberate decision under the philosophy of the principle of least privilege. Is that the other half of what you're after?
    - mikewarot 2y ago
      Unlike money in a wallet, capabilities can be composed. You can take an existing capability, and tack a filter onto it, and use that composed capability. For example, you need to do backups. Take the system administrator's access to everything, but put it through a read-only filter, and pass that to the backup program. Instead of using the "File Open" dialog in the Win32 gui api... and then a "file open" which could go anywhere, replace it with a call to the file-open "powerbox", which hands a file back to the application. The user could even make it read only, append only, etc. As far as users are concerned, it doesn't have to be hard. We just have to learn some new command line tricks.

nrr 2y ago

I don't disagree that the prevailing ambient authority model is less than ideal, but I'm left scratching my head at how capability security would solve the more acute problem we're facing. Of particular note, the kinds of ransomware compromise that lead to organizations asking underwriters to sell them cybersecurity insurance policies wouldn't immediately be thwarted by moving to capabilities. If a principal has valid requisite pointers to the resources they need to do their job, they have valid requisite pointers to the resources that a cryptolocker needs to cause disaster. It's those cybersecurity insurance policies (or regulatory frameworks, where those exist) that ultimately drive the decisions to implement EDRs.

mikewarot 2y ago
Who would trust the code that the ransomware sneaks use with all of the resources of their system? You can hand $5 over to someone without risking your life savings, surely you could do the same to hand over a temporary folder to run a random piece of code from the internet, and not your full administrator credentials. Capabilities change things in a profound way. They make it trivial to run any old code, yet not have to ever trust it.
- nrr 2y ago
  The thing that still puzzles me is how we determine which workload gets which capabilities. On Plan 9, I took a lot of glee in rfork()ing my way into a tightly curated namespace that disallowed subsequent use of mount and bind, but that was a deliberate decision under the philosophy of the principle of least privilege. Is that the other half of what you're after?
  - mikewarot 2y ago
    Unlike money in a wallet, capabilities can be composed. You can take an existing capability, and tack a filter onto it, and use that composed capability. For example, you need to do backups. Take the system administrator's access to everything, but put it through a read-only filter, and pass that to the backup program. Instead of using the "File Open" dialog in the Win32 gui api... and then a "file open" which could go anywhere, replace it with a call to the file-open "powerbox", which hands a file back to the application. The user could even make it read only, append only, etc. As far as users are concerned, it doesn't have to be hard. We just have to learn some new command line tricks.