Comment by zdragnar

>You describe things like "access the file system" but what even is that? In Linux, if you write to a "file" in /proc or /sys, you can trigger all sorts of side effects, including cause a kernel panic.

well, you can could of course go ahead and read some of the literature on capabilities based security, but you don't seem interested in that, so I guess I will give a go.

Here I will give a not necessarily great description of capability based security where the capabilities are handled on the OS level, this is my poorly remembered version of a document read about 20 years ago.

In Windows if you, as an attacker, are somehow able to do a complicated attack on any program that a user runs and it succeeds you can make that program do anything that the user has access to do. For example make it write to the local filesystem. For a large number of programs writing to the local filesystem does not make any sense and they were not written to do that, but now that the program has been corrupted by your attack it will write to the filesystem.

But let us suppose our program, Solitaire, was written with a capabilities based language then in the manifest for the program when we installed it it would not give access to the file system. The capabilities system can in fact be very explicit, and you could easily have a program be explicitly limited to only those abilities that are needed to run your solitaire game, but instead of going on at length on this and the abilities it confers to do interesting things with programs because you have actually enhanced security I will just focus on the filesystem.

When the attacker attacks Solitaire that the user is running and corrupts it, it no longer has just the security model of old Windows to worry about (this program can do anything the user can, like write to the user's contacts list, send emails as the user, format the hard drive, whatever) but also the security model, enforced at the OS level, of what kind of thing the program can do. Since Solitaire was written with the limited number of capabilities needed for doing a solitaire type game it can't do any of those things the user can unless, as well as attacking the solitaire game and gaining control of that, you are also able to attack the OS level capabilities administrator and get it to give your pwned executable - Solitaire - the capabilities you explicitly want it to have.

This is one example of how capabilities based security differs from Access based capabilities where if your solitaire game is allowed to if you write to a "file" in /proc or /sys, you can trigger all sorts of side effects, including cause a kernel panic. (here I have switched from solitaire in Windows to a similar game in Linux but I assume you can see the same princiles hold true)

I earlier mentioned this document Satan Comes to Dinner by Douglas Crockford https://www.crockford.com/ec/dining.html, it shows some other examples of how a capability based security model can be used to defend against trust based attacks in shared resource systems etc.

This is a more computer science based description than the one I gave and more abstract than my example of someone attacking Solitaire in order to write to a file somewhere, but in being more abstract also clearly applicable to many other forms of threats than my very specific (and thus unlikely) example is. Also it is by Douglas Crockford and quite a bit more entertaining than what I wrote.