If you mean a true capability-based OS, there is Fuchsia, which doesn't seem to be used yet, and RedoxOS, which is in development.
Edit: Nothing has full disk access either. I even see bash listed as explicitly not having access.
Edit: OK, iTerm2, not sure what's going on there.
Besides disk access, there are all sorts of other ways I don't trust random native apps on my Mac. At least camera access is locked down now (I think).
Weirdly, iTerm did ask for permission when I cd'd to ~/Desktop, and I said no, but it was still able to cd and edit/view/delete anything inside; the only thing I can't do is ls. BUT in ~/Downloads, I can only mess with files created within iTerm, not pre-existing ones. At this point I double-checked iTerm still doesn't have access to either (or full disk access) in my sysprefs, restarted iTerm, and reproduced this.
So yes it still feels like Terminal is willingly complying while iTerm is not totally, or something is just broken. And even if both were actually enforced fully, the permissions carry over to anything you run in there, and they don't protect very many things to begin with. Like, it can delete my entire Music lib without permissions either way.
Ventura 13.5.2, 2019 Intel MBP
I think terminal users aren't really in-scope for macOS security.
iTerm is third-party software like anything else. Wonder if it got an exemption. Also, TextEdit evidently has access to everything without asking, so it's not just a terminal thing. Idk what's happening exactly, but I don't trust this sandboxing.
There are also data vaults, which you cannot get around without turning off SIP.
Let's say you want to buy an ice cream cone, and pay for it.
Think of permission flags as signing a "Power of Attorney" letter, and handing that over to Dairy Queen. Every time you get a cone, they just take the money out of your account. But they could also sell your house. You can't limit the side effects of the permission you give, it's all or nothing.
On the other hand, capability based security is like taking a $5 capability out of your wallet (in the US, a piece of paper with Lincoln on it), and paying directly for that transaction, one time, at the time it is needed. The most you can lose is that $5. You're not risking your home, just to get ice cream.
The OS market is deranged. Capability based security is something that's been required since persistent internet connections became a thing. Clearly blaming everything else, the users, admins, programmers, compilers, language design, hasn't worked.
[1] https://support.apple.com/en-asia/guide/mac-help/mchl211c911...
And it does have more specific capabilities called "security-scoped bookmarks".
The infosec community never read The Boy Who Cried Wolf.
It would look almost exactly the same thing you already see. Instead of "file open" actually just being a suggestion to the application, the OS would actual enforce the permissions so that the application couldn't do anything else.
The usability of such a system wouldn't really ever take a hit. It certainly wouldn't result in excess permission dialogs. You don't see permission dialogs every time you take cash out of your wallet, or when you turn on a light switch.
The infosec community is weird, and I'm not part of it. I strongly disagree with them these days.
One thing that can be done with proxy capabilities is to run programs with any instruction set whether or not it is the instruction set on the computer that it is running on; the programs will just work. This is because an emulator can provide a proxy of the execution capability and can detect the instruction set required and emulate it. (Of course this only works if the program that spawns it is given the proxy capability, although it doesn't know that it is a proxy capability.) (It could also emulate specific instructions, e.g. if you are using x86 without BMI2 extensions and you want to run a program that uses BMI2 extensions.) Another thing that can be done is to run a program on another computer just as though it is local (or vice-versa); a program can, when sending/receiving messages through the network service, make IDs for any capabilities it send/receives and use those to handle passing the messages. So, capabilities can be shared between computers, and a program can use a combination of capabilities from multiple computers. (Multiple locking will be a bit more complicated.) Or, you can use proxy capabilities for testing what a program might do ten years from now (by proxying the date/time capability), or simulated disk errors, etc. Or, if you do not have a camera, you can make a program that expects it to be given the contents of a video file instead. There are many more possible uses, too.
The kernel need not know what proxy capabilities are used for, in order to work.
When a program starts, it receives an initial message, which will contain any capabilities it is allowed to use (and, depending on what capabilities they are, might be able to use those capabilities to request further capabilities). (If the initial message contains no capabilities, then the program is immediately terminated (unless a debugger is attached to it), since it would not be able to do any I/O and is therefore worthless.) (Note that there are no command-line arguments, environment variables, etc; only the initial message.)
Files can contain links to other files in their stream as well as bytes, and links to files can also be made into capabilities which can be sent in messages too. A link can be either to the latest version, or to a fixed version (in which case copy-on-write is used if it is accessed and written through a link that is not to a fixed version).
Another feature is that locks and transactions can involve multiple objects at once, instead of having to lock each one individually. (This is helpful for many kinds of synchronizations. For example, a program might write to (or read from) two files and avoid a race condition of another program reading (or writing) the two files and receiving (or sending) inconsistent data.)
I also have many ideas of the high-level design (of stuff other than the kernel); most of the above is about low-level design.
There will be common conventions for formats of messages, including endianness, etc; this way programs written for different instruction sets can communicate with each other without being confused.
One high-level feature is the "common data format", which is a binary structured format, used for most of the system. This can include plain lists, key/value lists, rich text, diagrams, zoned spreadsheets, time series, typed arrays, extensions, and others.
The command shell has some ideas similar than Nushell, although using the binary structured format instead of text, using Extended TRON Code instead of Unicode, and others. It can also be used as a programming language, can be used to control other programs (if having access to the appropriate capabilities) (a bit similar than ARexx ports), etc. You can also just as easily move and copy data and objects between the command shell and GUI, so they are designed to work well together, rather than independent.
The file system is strange, not having file names and not having directory structures (except for a root directory with 256 numbered entries, mainly used for some low-level startup stuff; not all entries need to link to a file). A file can have several numbered forks (not necessarily consecutively numbered; perhaps 32-bit numbers); some of the low numbers have specific conventional uses while higher numbers can be used for your own use. There is journaling needed, including of transactions of multiple files at once.
A POSIX compatibility library is also possible. This is a user program that a C program can link to, and a set of conventions for messages to use with POSIX (e.g. command-line arguments, environment variables, etc), which can be used to run programs that are designed for POSIX. (However, designing the program for this system instead would make it much better suited for this system in many ways, since it can then take advantage of many of the helpful features of this system.)
My intention is that it is not a single implementation of the operating system, but a specification that multiple implementations would be possible. Some implementations might run by themself while others might be able to run inside of another operating system (similar than Inferno). A program for this operating system could then run on any of the available implementations. The kernel and the higher-level parts of the operating system need not match (other than stuff such as drivers), although usually would be expected that they would match.