#lazyweb I'm clueless... capabilities are based on "if you can name the resource, you can access it". So uhhh, what prevents someone from trying a bunch of random names and getting lucky? Or is that theoretically what could actually happen, but doesn't b/c identifiers are too big to brute force?
@cr1901 Unix file descriptors are capabilities. If you have an open file descriptor to a file, you can read and/or write to that file, regardless of what the filesystem permissions say. The operating system maintains an array of the inodes you have open on your behalf. To specify which file descriptor to operate on, you specify a numerical index into that list, such as "2". Guessing "2" won't give you access to anything you don't already have, and guessing inode numbers won't give you access to anything, because you can't open a file by inode number.
This is the same mechanism used in ocap systems like seL4, except that it calls your thread's associated array of generalized file descriptors a "CSpace".
@cr1901 #CHERI uses a different approach from #seL4: it lets you store the capability bits in normal memory, but it maintains a bitmap where you can't reach it which tells the CPU hardware which memory words contain capabilities. Only a small amount of code (as I understand it, the virtual memory code in the kernel) has the authority to set those bits on existing data. But I don't understand CHERI as well as seL4.
@cr1901 And, of course, without any centrally trusted kernel, you can implement some kinds of capability systems with public-key cryptography, where it's not actually impossible to guess someone's private key, just conjectured to be too hard to have a significant probability of success within the next few billion years.