I understand why in 1979 and perhaps until mid 1990s capability OS architecture might have been irrelevant and excessive. But after that, it sounds like the only architecture suitable for the internet age, where you can download and run anything from anywhere. Instead, we're stuck with legacy systems, which now contain layers of layers of abstractions and security measures. User rights, anti-virus software, vetting (signatures, hashes, app-store verification) - all become obsolete or near-obsolete in a capability-based system where a program simply doesn't have access to anything by default. Part of the appeal of virtualization is also due to the fact that it isolates programs (for instance, I only run npm inside Docker container these days, because chances are some package will contain malware at some point).
Part of it is inertia, but part of it is ignorance. Enthusiasts spend tons of money and effort building another GPU enabled terminal or safe programming languages - and maybe that's fine, but I wonder what we could've accomplished if people were simply aware what a well-designed capability OS could be like, because this is literally the only OS paradigm in existence (that I know of) that's even worth any serious effort.
If you go through old CS OS texts on the matter, they really didn't have the same understanding of capabilities then as the later object-capabilities (ocap) model would introduce. Typically they would show an access control matrix, note that acls were rows and capabilities columns and note that they are duals of one another. They're the same, acls are easier to manage, done.
I’m not going to argue against much of the content of this paper, but it should be pointed out that their argument in the middle section against the “confinement myth” seems pretty bogus. They say that you can isolate the capability read/write resource from the data read/write resource, but… this makes absolutely no sense. Bits are bits. If you assume some out-of-band isolation of capability distribution then you’ve changed the game, but even that isn’t enough for me to believe that isolation is possible.
Consider two processes on a *nix system, and for the sake of argument let's say they're sufficiently isolated from each other as to have only one communications channel between them. If that communications channel is a unix domain socket, one process can send a file descriptor (effectively a capability) to the other over the socket. Each process has a file descriptor table in the kernel whose integer keys are only meaningful to that process in particular, and the kernel provides a mechanism to transmit file descriptors across a socket. The kernel mediates in this case.
If the communications channel is not a unix domain socket and is instead something like a TCP connection, you don't have this option available to you.
You aren't always just sending bits from one process to another!
That argument assumes that the delegation of a capability to another process must happen through a path of interprocess communication that can be established only by the operating system, if the processes that want to communicate have the capabilites for this.
I have not studied to see how the existing capability-based operating systems solve this problem, because it seems that this is not a simple solution. If the capabilities are very fine-grained, to make certain that IPC really cannot happen, that might be cumbersome to use, while coarse-grained capabilities could be circumvented. To really prevent IPC without appropriate capabilities, a lot of the convenient features of a UNIX-like system must be forbidden, like the existence of files that can be read by any user, or directories like /tmp , where anyone can write a file.
> If the capabilities are very fine-grained, to make certain that IPC really cannot happen, that might be cumbersome to use, while coarse-grained capabilities could be circumvented.
In SeL4 it’s kinda like this: A capability is an opaque handle you can invoke to RPC into some other process or into the kernel. There’s no worry about how fine grained capabilities are because there’s no global table of permission bits or anything like that. Processes can invent capabilities whenever they want. Because caps just let other processes call your code, you can programmatically make them do anything.
Suppose I want to give a process read only access to a file I have RW access to. The OS doesn’t need a special “read only capability” type. It doesn’t need to. Instead, my process just makes capabilites for whatever I actually want on the fly. In this case, I just make a new capability. When it’s invoked I see the associated request, if the caller is making a read request, I proxy that request to the file handle I have. (Also another cap). And if it’s a write request, I can reject it. Voila!
This is how you can write the filesystem and drivers in userland. One process can be in charge of the block devices. That process creates some caps for reading and writing raw bytes to disk. It passes the “client side” of that cap to a filesystem process, which can produce its own file handle caps for interacting with directories and files, which can be passed to userland processes in turn. Its capabilities all the way down.
IIUC one problem with such layering of capability processing is that each passed layer results in a context switch (i.e. switch of memory mappings, thrashing of caches, etc.) and its on top of the cost of passing through the kernel. In other words, you may need to pay cost of N syscalls for one multi-layered capability-based operation.
That works perfectly fine for an embedded computer, which is where systems like SeL4 are used.
On the other hand, I cannot see how this approach can be scaled to something like a personal computer.
For some programs that I run, e.g. for an Internet browser, I may want to not authorize them to access anything on SSDs/HDDs, except for a handful of configuration files and for any files they may create in some cache directories.
For other programs that I run, I may want to let them access most or all files in certain file systems. Any file system that I use contains typically many millions of files.
Therefore it is obvious that using one capability per file is not acceptable. Moreover, such programs may need to access immediately many thousands of files that have been just created by some other program that has run before them, for instance a linker running after a compiler.
Assuming that a pure capability-based system is used, not some hybrid between ACLs and capabilities, there must be some more general kinds of capabilities, that would grant access simultaneously to a great number of resources, based on some rules, e.g. all files in some directory can be read, all files with a certain extension or some other kind of name pattern from some directory may be written or deleted or renamed, and so on.
Then make a userspace server to do that. If you want to see how this works in practice, macOS and iOS are great “pragmatic” implementations of this pattern. They use a Mach/BSD hybrid
Covert channels are a thing. Shared access to resources always opens the possibility of covert information passing through e.g. modulation of resource usage. This isn’t even out-of-band, it’s just a hard fact that a shared resource always creates a potential covert channel (source: Lampson 1972, A Note on the Confinement Problem).
The problem with any secure system is that they're not usable systems. Real applications and users expect to access anything from anywhere. That's the opposite of security.
None of those things become obsolete with capabilities.
You still need code signing because users need to be able to grant privileges in a way that sticks across upgrades. The object they want to privilege isn't a set of files on disk but a logical app as defined by (more or less) a brand name+app name even as it changes over time.
You still need antivirus software because users can be tricked into giving capabilities to programs that appear legit but are actually malicious.
Modern operating systems (iOS, Android) are capability oriented operating systems to the extent that makes sense. For some reason there's a meme that says capabilities are a magic wand that solves all security problems, but it's not the case.
Yeah not least of which because statically defined capabilities struggle when you have dynamic needs. Imagine you have S3 buckets. If your buckets are partitioned by application, that’s easy to protect with capabilities. Now what if you have an application that’s dynamically assigning buckets by tenant. You can’t statically assign that and you can’t even restrict yourself to buckets you created in the first place because you need a meta system to keep track of which buckets were created by which application but it’s doable (eg store data within the bucket indicating which app). But now you’ve got delegation challenges if you have two applications that need access to overlapping resources. There’s no consistent design solution. Everything is a special case to figure out.
In addition to capabilities, which implemented the principle of least privilege (and keep untrusted code sandboxed by default) there is a need for binary verification.
A check that a whatever is downloaded cannot exceed it's capabilities.
Part of the challenge is that hardware tried and has failed to be trustworthy in implementing security boundaries. The failure appears to be because a misalignment of incentives.
I think the premise of a capability based operating system can help a lot, but for something to work in the long term the incentives need to aligned.
Your point of view has an insidious lie at its core; that the user perfectly knows what she wants. That if we only give the user the ability to set capabilities, we will not need any other protection for her.
The reality is that we're water meatballs, we're so easy to fool, and we need the cold calculating power of code to protect us from ourselves.
> it sounds like the only architecture suitable for the internet age, where you can download and run anything from anywhere
Wasn’t that the reason why Microsoft went allout against Java? Write once, run anywhere. JVM was a “trojan horse”
and theoretically
could have dominated the world.
I didn't mean it in the Java way. I meant that whatever operating system you're on, you can download random programs from the internet (compiled specifically for your OS or portable) and run it on your machine. It doesn't matter what they're written in or how they're run, it's possible on any OS connected to the internet and an OS with capabilities as first class citizens would isolate any program by default, denying it access to anything by default and severely limiting program's ability to cause harm, intentionally or unintentionally.
In case of updating the binary, yes, you generally want to make sure it comes from the same source and therefore cannot do damage to things it already has access to. But when you install a new program, it shouldn't have access to any resources other than the ones it creates itself, so there's no need to sign it. Further more, when installing a new program, you still have to download/import the pubkey to verify the signature from somewhere, so it's almost meaningless on the first installation. Signatures wouldn't be obsolete, but they also wouldn't be the only line of defense. Furthermore, updating can now be performed by the program itself and the program might already contain the pubkey needed to check the validity of updates.
OS design basically stagnated in the 90s. Sure, we had NT, but that was putting a dos flavoured suit on VMS. BeOS was promising, but fizzled out quickly. Everything else has either been research or for the embedded market.
Android and iOS increased security, but at the cost of much flexibility and user agency. It's some kind of progress, but I certainly wouldn't want them for Real Computers.
It looks like you you may be interested in Qubes OS, security oriented operating system relying on strong, hardware-assisted virtualization: https://qubes-os.org. My daily driver, can't recommend it enough.
I know about it, but I'm not interested in QubeOS approach. It's VMs all the way down, while what I'm talking about is no VMs and capabilities as first class citizens and no vurtualization.
I am also surprised that capabilities weren't more widely implemented after mobile OSes demonstrated they are practical. I know Windows made a move in that direction with UAC but had to soften it due to user alert fatigue. So I guess having no legacy apps and a centralized repository helps.
I've recently been looking into Guix SD as a solution. Its package management is designed to keep programs independent of each other, so containers are cheap and lightweight. Trying out untrusted software is as easy as `guix shell --container --pure --no-cwd [program]`, which blocks access to the network, file system, and environment variables. Right now I'm adding more advanced capability management: limits on CPU, memory, storage space, network use, etc.
What is wrong about virtualization? It allows to run all existing software, it doesn't restrict the owner of the device, it is extremely flexible and reliable. And it can be fast, too.
see other comment, the author describes some issues with current hardware virtualization. kvm is also pretty good, but not perfect... and completely irrelevant with GPU pass-through enabled. =3
Sorry, can't recall the exact lecture... It was only interesting as I was looking at a toy project to see if metastability issues were solvable. Practically speaking, it only proved the folks at Sun were very smart people choosing an encrypted mmu. =3
The Market has spoken, and people use standard consumer CPU/GPU-bodge architecture in cloud data centers. Sure there are a few quality of life features different from budget retail products, but we abandoned what Sun solved with a simple encrypted mmu decades ago.
The paper adds little to TCSEC/"Orange Book"/FOLDOC publications. Yet the poster doesn't deserve all the negative karma.
On a consumer CPU/GPU/NPU, software just isn't going to be enough to fix legacy design defects. Have a great day. =3
in larger systems the utility of sharing a single cpu/gpu complex between independent authorization domains kind of goes away. if you have 10,000 units of allocation, it never makes sense to try to share one of those until you have more than 10,000 jobs, and even then.
so it seems a lot more feasible to control access and sharing between those units and write of off the intranode case as a lost cause
In such arrangements, one has essentially enforced high-latency similar context isolation using encrypted/VLAN network fabric, and pushed coordination/permissions into back-plane supervisory subsystems. Still creating a monolithic permission domain vulnerability within the entire n<10000 node cluster partition.
Likely doesn't help OS users either way. Best regards =3
Might be people just flagging so mods can make an "Is this an LLM not?" determination. I see a lot of new accounts get flagged like this (and scanning the previous comments, ehhhhh yea maybe?).
The most frustrating takeaway from the original SRI PSOS architecture is that we had the blueprint for true hardware-level Zero-Trust in 1979, and we abandoned it for deployment convenience. By anchoring security in unalterable, hardware-tagged capabilities rather than software-defined access control lists, PSOS eliminated privilege escalation at the physical layer. The SRI Hierarchical Development Methodology (HDM) didn't just 'test' for security; it mathematically proved structural isolation across distinct abstraction levels. Modern monoliths have spent the last thirty years trying to bolt software firewalls onto fundamentally porous kernels, when we should have been building on the hardware-enforced capability model PSOS handed us
I understand why in 1979 and perhaps until mid 1990s capability OS architecture might have been irrelevant and excessive. But after that, it sounds like the only architecture suitable for the internet age, where you can download and run anything from anywhere. Instead, we're stuck with legacy systems, which now contain layers of layers of abstractions and security measures. User rights, anti-virus software, vetting (signatures, hashes, app-store verification) - all become obsolete or near-obsolete in a capability-based system where a program simply doesn't have access to anything by default. Part of the appeal of virtualization is also due to the fact that it isolates programs (for instance, I only run npm inside Docker container these days, because chances are some package will contain malware at some point).
Part of it is inertia, but part of it is ignorance. Enthusiasts spend tons of money and effort building another GPU enabled terminal or safe programming languages - and maybe that's fine, but I wonder what we could've accomplished if people were simply aware what a well-designed capability OS could be like, because this is literally the only OS paradigm in existence (that I know of) that's even worth any serious effort.
If you go through old CS OS texts on the matter, they really didn't have the same understanding of capabilities then as the later object-capabilities (ocap) model would introduce. Typically they would show an access control matrix, note that acls were rows and capabilities columns and note that they are duals of one another. They're the same, acls are easier to manage, done.
OP is arguably the first paper that introduces ocaps. Some of the issues are discussed in "Capability Myths Demolished" https://papers.agoric.com/assets/pdf/papers/capability-myths...
I’m not going to argue against much of the content of this paper, but it should be pointed out that their argument in the middle section against the “confinement myth” seems pretty bogus. They say that you can isolate the capability read/write resource from the data read/write resource, but… this makes absolutely no sense. Bits are bits. If you assume some out-of-band isolation of capability distribution then you’ve changed the game, but even that isn’t enough for me to believe that isolation is possible.
Consider two processes on a *nix system, and for the sake of argument let's say they're sufficiently isolated from each other as to have only one communications channel between them. If that communications channel is a unix domain socket, one process can send a file descriptor (effectively a capability) to the other over the socket. Each process has a file descriptor table in the kernel whose integer keys are only meaningful to that process in particular, and the kernel provides a mechanism to transmit file descriptors across a socket. The kernel mediates in this case.
If the communications channel is not a unix domain socket and is instead something like a TCP connection, you don't have this option available to you.
You aren't always just sending bits from one process to another!
That argument assumes that the delegation of a capability to another process must happen through a path of interprocess communication that can be established only by the operating system, if the processes that want to communicate have the capabilites for this.
I have not studied to see how the existing capability-based operating systems solve this problem, because it seems that this is not a simple solution. If the capabilities are very fine-grained, to make certain that IPC really cannot happen, that might be cumbersome to use, while coarse-grained capabilities could be circumvented. To really prevent IPC without appropriate capabilities, a lot of the convenient features of a UNIX-like system must be forbidden, like the existence of files that can be read by any user, or directories like /tmp , where anyone can write a file.
> If the capabilities are very fine-grained, to make certain that IPC really cannot happen, that might be cumbersome to use, while coarse-grained capabilities could be circumvented.
In SeL4 it’s kinda like this: A capability is an opaque handle you can invoke to RPC into some other process or into the kernel. There’s no worry about how fine grained capabilities are because there’s no global table of permission bits or anything like that. Processes can invent capabilities whenever they want. Because caps just let other processes call your code, you can programmatically make them do anything.
Suppose I want to give a process read only access to a file I have RW access to. The OS doesn’t need a special “read only capability” type. It doesn’t need to. Instead, my process just makes capabilites for whatever I actually want on the fly. In this case, I just make a new capability. When it’s invoked I see the associated request, if the caller is making a read request, I proxy that request to the file handle I have. (Also another cap). And if it’s a write request, I can reject it. Voila!
This is how you can write the filesystem and drivers in userland. One process can be in charge of the block devices. That process creates some caps for reading and writing raw bytes to disk. It passes the “client side” of that cap to a filesystem process, which can produce its own file handle caps for interacting with directories and files, which can be passed to userland processes in turn. Its capabilities all the way down.
>Its capabilities all the way down.
IIUC one problem with such layering of capability processing is that each passed layer results in a context switch (i.e. switch of memory mappings, thrashing of caches, etc.) and its on top of the cost of passing through the kernel. In other words, you may need to pay cost of N syscalls for one multi-layered capability-based operation.
That works perfectly fine for an embedded computer, which is where systems like SeL4 are used.
On the other hand, I cannot see how this approach can be scaled to something like a personal computer.
For some programs that I run, e.g. for an Internet browser, I may want to not authorize them to access anything on SSDs/HDDs, except for a handful of configuration files and for any files they may create in some cache directories.
For other programs that I run, I may want to let them access most or all files in certain file systems. Any file system that I use contains typically many millions of files.
Therefore it is obvious that using one capability per file is not acceptable. Moreover, such programs may need to access immediately many thousands of files that have been just created by some other program that has run before them, for instance a linker running after a compiler.
Assuming that a pure capability-based system is used, not some hybrid between ACLs and capabilities, there must be some more general kinds of capabilities, that would grant access simultaneously to a great number of resources, based on some rules, e.g. all files in some directory can be read, all files with a certain extension or some other kind of name pattern from some directory may be written or deleted or renamed, and so on.
Then make a userspace server to do that. If you want to see how this works in practice, macOS and iOS are great “pragmatic” implementations of this pattern. They use a Mach/BSD hybrid
Doesn't that mean that your process is then responsible for ensuring that an app with a read-only capability cannot do a write ?
You're moving the burden of enforcement from the kernel to the user level ?
Covert channels are a thing. Shared access to resources always opens the possibility of covert information passing through e.g. modulation of resource usage. This isn’t even out-of-band, it’s just a hard fact that a shared resource always creates a potential covert channel (source: Lampson 1972, A Note on the Confinement Problem).
The problem with any secure system is that they're not usable systems. Real applications and users expect to access anything from anywhere. That's the opposite of security.
None of those things become obsolete with capabilities.
You still need code signing because users need to be able to grant privileges in a way that sticks across upgrades. The object they want to privilege isn't a set of files on disk but a logical app as defined by (more or less) a brand name+app name even as it changes over time.
You still need antivirus software because users can be tricked into giving capabilities to programs that appear legit but are actually malicious.
Modern operating systems (iOS, Android) are capability oriented operating systems to the extent that makes sense. For some reason there's a meme that says capabilities are a magic wand that solves all security problems, but it's not the case.
Yeah not least of which because statically defined capabilities struggle when you have dynamic needs. Imagine you have S3 buckets. If your buckets are partitioned by application, that’s easy to protect with capabilities. Now what if you have an application that’s dynamically assigning buckets by tenant. You can’t statically assign that and you can’t even restrict yourself to buckets you created in the first place because you need a meta system to keep track of which buckets were created by which application but it’s doable (eg store data within the bucket indicating which app). But now you’ve got delegation challenges if you have two applications that need access to overlapping resources. There’s no consistent design solution. Everything is a special case to figure out.
In addition to capabilities, which implemented the principle of least privilege (and keep untrusted code sandboxed by default) there is a need for binary verification.
A check that a whatever is downloaded cannot exceed it's capabilities.
Part of the challenge is that hardware tried and has failed to be trustworthy in implementing security boundaries. The failure appears to be because a misalignment of incentives.
I think the premise of a capability based operating system can help a lot, but for something to work in the long term the incentives need to aligned.
I'll insert my standard plug for Genode/Sculpt OS here... Capability based, and used/maintained commercially:
https://genode.org/
Your point of view has an insidious lie at its core; that the user perfectly knows what she wants. That if we only give the user the ability to set capabilities, we will not need any other protection for her.
The reality is that we're water meatballs, we're so easy to fool, and we need the cold calculating power of code to protect us from ourselves.
> it sounds like the only architecture suitable for the internet age, where you can download and run anything from anywhere
Wasn’t that the reason why Microsoft went allout against Java? Write once, run anywhere. JVM was a “trojan horse” and theoretically could have dominated the world.
I didn't mean it in the Java way. I meant that whatever operating system you're on, you can download random programs from the internet (compiled specifically for your OS or portable) and run it on your machine. It doesn't matter what they're written in or how they're run, it's possible on any OS connected to the internet and an OS with capabilities as first class citizens would isolate any program by default, denying it access to anything by default and severely limiting program's ability to cause harm, intentionally or unintentionally.
Why do signatures/hashes/app-store verification become obsolete with a capability-based system?
If a binary has the capability to withdraw money from my account, I don't want that capability given to just any binary.
In case of updating the binary, yes, you generally want to make sure it comes from the same source and therefore cannot do damage to things it already has access to. But when you install a new program, it shouldn't have access to any resources other than the ones it creates itself, so there's no need to sign it. Further more, when installing a new program, you still have to download/import the pubkey to verify the signature from somewhere, so it's almost meaningless on the first installation. Signatures wouldn't be obsolete, but they also wouldn't be the only line of defense. Furthermore, updating can now be performed by the program itself and the program might already contain the pubkey needed to check the validity of updates.
OS design basically stagnated in the 90s. Sure, we had NT, but that was putting a dos flavoured suit on VMS. BeOS was promising, but fizzled out quickly. Everything else has either been research or for the embedded market.
Android and iOS increased security, but at the cost of much flexibility and user agency. It's some kind of progress, but I certainly wouldn't want them for Real Computers.
It looks like you you may be interested in Qubes OS, security oriented operating system relying on strong, hardware-assisted virtualization: https://qubes-os.org. My daily driver, can't recommend it enough.
I know about it, but I'm not interested in QubeOS approach. It's VMs all the way down, while what I'm talking about is no VMs and capabilities as first class citizens and no vurtualization.
I am also surprised that capabilities weren't more widely implemented after mobile OSes demonstrated they are practical. I know Windows made a move in that direction with UAC but had to soften it due to user alert fatigue. So I guess having no legacy apps and a centralized repository helps.
I've recently been looking into Guix SD as a solution. Its package management is designed to keep programs independent of each other, so containers are cheap and lightweight. Trying out untrusted software is as easy as `guix shell --container --pure --no-cwd [program]`, which blocks access to the network, file system, and environment variables. Right now I'm adding more advanced capability management: limits on CPU, memory, storage space, network use, etc.
What is wrong about virtualization? It allows to run all existing software, it doesn't restrict the owner of the device, it is extremely flexible and reliable. And it can be fast, too.
see other comment, the author describes some issues with current hardware virtualization. kvm is also pretty good, but not perfect... and completely irrelevant with GPU pass-through enabled. =3
Which other approach to security do you consider reliable? Through correctness? Through obscurity?
https://blog.invisiblethings.org/2008/09/02/three-approaches...
Publicly documented encrypted mmu, as it is the only practical way to isolate contexts on parallel cores.
Or some exotic processor no one would ever sell successfully. =3
What would an encrypted MMU do differently?
Mitigates undetectable bleeding/contamination of information between parallel processes, cores, and or rowhammer etc.
Thus, writing a robust and secure OS may actually be possible by competent programmers in most compiled languages. Best of luck =3
Qubes OS was also shown to have inherent hardware virtualization sandbox vulnerabilities described by Joanna Rutkowska in an interesting lecture.
There is likely a PoC around someplace if people dig a bit. =3
Are talking about this? https://en.wikipedia.org/wiki/Blue_Pill_(software)
It happened in 2006 and never happened after that. I would consider it as secure as it gets.
Sorry, can't recall the exact lecture... It was only interesting as I was looking at a toy project to see if metastability issues were solvable. Practically speaking, it only proved the folks at Sun were very smart people choosing an encrypted mmu. =3
The Market has spoken, and people use standard consumer CPU/GPU-bodge architecture in cloud data centers. Sure there are a few quality of life features different from budget retail products, but we abandoned what Sun solved with a simple encrypted mmu decades ago.
The paper adds little to TCSEC/"Orange Book"/FOLDOC publications. Yet the poster doesn't deserve all the negative karma.
On a consumer CPU/GPU/NPU, software just isn't going to be enough to fix legacy design defects. Have a great day. =3
in larger systems the utility of sharing a single cpu/gpu complex between independent authorization domains kind of goes away. if you have 10,000 units of allocation, it never makes sense to try to share one of those until you have more than 10,000 jobs, and even then.
so it seems a lot more feasible to control access and sharing between those units and write of off the intranode case as a lost cause
In such arrangements, one has essentially enforced high-latency similar context isolation using encrypted/VLAN network fabric, and pushed coordination/permissions into back-plane supervisory subsystems. Still creating a monolithic permission domain vulnerability within the entire n<10000 node cluster partition.
Likely doesn't help OS users either way. Best regards =3
I would honestly like to understand why Miagg's comment has been flagged.
Might be people just flagging so mods can make an "Is this an LLM not?" determination. I see a lot of new accounts get flagged like this (and scanning the previous comments, ehhhhh yea maybe?).
Idk, just guessing
At a guess, looking at his history, it's AI slop. Basic facts appear correct though.
Which history? it's their only comment.
It's probably a bot nonetheless, which poses the question: why do people do that? What do they gain by posting resume comments on HN with LLM bots?
I'm seeing about 9 comments, all flagged dead. Do you have showdead on?
Sorry sorry, my bad, I read "Karma: 1" in their profile and my brain thought "Number of comments: 1".
The most frustrating takeaway from the original SRI PSOS architecture is that we had the blueprint for true hardware-level Zero-Trust in 1979, and we abandoned it for deployment convenience. By anchoring security in unalterable, hardware-tagged capabilities rather than software-defined access control lists, PSOS eliminated privilege escalation at the physical layer. The SRI Hierarchical Development Methodology (HDM) didn't just 'test' for security; it mathematically proved structural isolation across distinct abstraction levels. Modern monoliths have spent the last thirty years trying to bolt software firewalls onto fundamentally porous kernels, when we should have been building on the hardware-enforced capability model PSOS handed us
My modern take on (un)secure operating system for the future : https://news.ycombinator.com/item?id=48167846
Rebuild everything from scratch, with AI agents. Then make them prove what they wrote.