6 ms·

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 onl

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.

haunter 5mo ago
> 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.
- usrbinenv 5mo ago
  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.
jdougan 5mo ago
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-demolished.pdf https://papers.agoric.com/assets/pdf/papers/capability-myths...
- jkhdigital 5mo ago
  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.
  - adrian_b 5mo ago
    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.
    - jkhdigital 5mo ago
Joel_Mckay 5mo ago
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
- convolvatron 5mo ago
  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
  - Joel_Mckay 5mo ago
    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
    - convolvatron 5mo ago
      you kinda missed my point. already in the cluster the important filesystem is the distributed one. the important job management system is the distributed one. the local OS just effectively supports the single process that we really care about. so the distributed context is where we add capabilities and actually manage access and resources. that is the real OS.
myaccountonhn 5mo ago
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.
- usrbinenv 5mo ago
  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.
fsflover 5mo ago
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 https://qubes-os.org. My daily driver, can't recommend it enough.
- usrbinenv 5mo ago
  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.
  - fsflover 5mo ago
    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.
    - Joel_Mckay 5mo ago
      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
      - fsflover 5mo ago
        Which other approach to security do you consider reliable? Through correctness? Through obscurity? https://blog.invisiblethings.org/2008/09/02/three-approaches-to-computer-security.html https://blog.invisiblethings.org/2008/09/02/three-approaches...
        Joel_Mckay 5mo ago
        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
mike_hearn 5mo ago
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.
- vlovich123 5mo ago
  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.
- deleted 5mo ago
  [deleted]
mghackerlady 5mo ago
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.
- ahartmetz 5mo ago
  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.
  - mghackerlady 5mo ago
    Android is just Linux running a Java VM and a funky userland. iOS is just MacOS apple decided you can't do real work on. Both are still unix clones (as contrast to a unix-like like plan9 or haiku)
    - ahartmetz 5mo ago
      The kernel is obviously close to vanilla Linux, but one could also define the OS as "which lower-level services and interfaces the applications see and are programmed to use" - so the stuff on top of Linux matters. There are more interesting, general, and lower level innovations out there - sure. But the mobile OSes do have improved security from some kind of permission system, VM (only partially because native components are common), one user account per app (IIRC) and such.
      - mghackerlady 5mo ago
        Right but what I'm trying to say is that the core architecture hasn't really changed since the 90s. All the improvements you mentioned are non-applicable to my statements. One user account per app is just a hacky way to use unixes timesharing origins for increased security, VMs and containers slap a bandaid on the problems, and permission systems like android and iOS have are just a hack that works nicely since they use sandboxed software. Plus, these are all security based, which while the topic of the discussion overall, wasn't what I meant when it came to OS innovation in general (an important part, though)
philistine 5mo ago
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.
ebiederm 5mo ago
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.
- wmf 5mo ago
  binary verification. A check that a whatever is downloaded cannot exceed it's capabilities. That's already handled by the sandbox.
pocksuppet 5mo ago
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.
- amavect 5mo ago
  One of my friends had his credentials stolen from a trojan infostealer masquerading as a video game, sent from a rando who he mistakenly trusted. If only it had to request user permission to access files outside of its folder. There's a spectrum between full access and full lockdown.
  - pocksuppet 5mo ago
    If every app requests that permission, no app requests that permission. Also your passwords would be in your user folder so the app that needs the passwords could read them.
    - amavect 5mo ago
      That condition usually doesn't hold in practice. Very few programs have a reason for reading browser history or cookies. Excel has no purpose accessing the Notepad++ appdata folder. Not all-or-nothing.
      - pocksuppet 5mo ago
        How would your browser read browser history and cookies? It gets its own app data folder? What if I want to export my browser history to another browser - which is currently impossible on Chrome for Android, precisely because no other app is allowed to access Chrome's history file?
        amavect 5mo ago
        I imagine an OS where the system remembers to keep permanent permission for a program to manage its own files. An app data folder would work. The system should pass the capability on program start. I also imagine a system where graphical programs must call a trusted system file picker to receive a fd. Receiving the capability grants permission. Ideally, Chrome could export browser history to a file, but we live in a fallen world. In any case, an alternative browser must request access through the system file picker, selecting an exported file or selecting the Chrome app data folder. It trades automatic import with user selection. The user has ultimate power, and programs make noise when doing such requests. Please forgive me that I don't know Android system architecture. Searching tells me something about the Storage Access Framework, but I don't know if that truly meets what I describe.
mech422 5mo ago
I'll insert my standard plug for Genode/Sculpt OS here... Capability based, and used/maintained commercially: https://genode.org/ https://genode.org/
- rurban 5mo ago
  I also like HarmonyOS, the most advanced secure OS nowadays. If they just would have fixed deadlocks also.
  - mech422 5mo ago
    Never heard of HarmonyOS before - looking at the website, it doesn't seem to mention being capability based, but it is 'distributed' ??
killerstorm 5mo ago
We kind of have the taste of what capability-based OS would look like in form of a web browser: you can open a web page with a potentially-malicious code and it doesn't have access to any of your files or sensitive data unless you explicitly allow it to. We also have it on mobile operating systems, although some things are a rather coarse-grained. On desktop there's just a lot of inertia. Everyone switching to a new thing is kind of impossible, and some simple add-on to existing systems would look like containers/docker. I think capability-oriented programming languages might actually be an easier way to switch to that model, as it's much easier to adopt a new application than a new OS. E.g. with language-level capabilities (ocaps) you can implement a safe plugin system. That's pretty much non-existent now and is quite relevant - e.g. getting pwned via an IDE plugin is the reality. So maybe a "new Emacs" can be a way to get people to adopt capabilities beyond what we already have in the browser/cloud/etc. - IDE written in a new programming stack which is inherently secure to the point of running potentially-unsafe plugins.
pixel_popping 5mo ago
One word: Qubes.
- rurban 5mo ago
  Qubes for sure not. Xen seperation on top of Linux sounds nice, but there's still this huge, insecure monolith below. Genode, Harmony or Fuchsia sound much better. And now with a secure language for the surface and drivers it would be even better. But even better no OS, and no attack surface. Only what you need, and properly isolated.
zzo38computer 5mo ago
I think many people have had similar ideas, including I also had ideas about how to design computer and operating system, which can use proxy capabilities. (There are different kind of capability systems, and I think that proxy capabilities has more benefits than only security.) There are still considerations when designing parts of the system to be secure, while also making them have the functions that are desired (although a proxy capability system can be used to add arbitrary further restrictions if needed), but the core system can use proxy capabilities as the core security system. Hashes would still be useful, but that is if you want to check that the package is the one that you intended; it does not prevent you from installing or writing whatever program you want to do, nor to make the program secure, which would be done by separate mechanisms; however, knowing that the package is the one that you intended can be one of the steps of the security, but not the main one. However, security is not the only issue in a computer and operating system design, although it is a significant issue.

haunter 5mo ago

> 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.

usrbinenv 5mo ago
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.

jdougan 5mo ago

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-demolished.pdf https://papers.agoric.com/assets/pdf/papers/capability-myths...

jkhdigital 5mo ago
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.
- adrian_b 5mo ago
  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.
  - jkhdigital 5mo ago

Joel_Mckay 5mo ago

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

convolvatron 5mo ago
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
- Joel_Mckay 5mo ago
  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
  - convolvatron 5mo ago
    you kinda missed my point. already in the cluster the important filesystem is the distributed one. the important job management system is the distributed one. the local OS just effectively supports the single process that we really care about. so the distributed context is where we add capabilities and actually manage access and resources. that is the real OS.

myaccountonhn 5mo ago

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.

usrbinenv 5mo ago
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.

fsflover 5mo ago

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 https://qubes-os.org. My daily driver, can't recommend it enough.

usrbinenv 5mo ago
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.
- fsflover 5mo ago
  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.
  - Joel_Mckay 5mo ago
    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
    - fsflover 5mo ago
      Which other approach to security do you consider reliable? Through correctness? Through obscurity? https://blog.invisiblethings.org/2008/09/02/three-approaches-to-computer-security.html https://blog.invisiblethings.org/2008/09/02/three-approaches...
      - Joel_Mckay 5mo ago
        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

mike_hearn 5mo ago

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.

vlovich123 5mo ago
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.
deleted 5mo ago
[deleted]

mghackerlady 5mo ago

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.

ahartmetz 5mo ago
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.
- mghackerlady 5mo ago
  Android is just Linux running a Java VM and a funky userland. iOS is just MacOS apple decided you can't do real work on. Both are still unix clones (as contrast to a unix-like like plan9 or haiku)
  - ahartmetz 5mo ago
    The kernel is obviously close to vanilla Linux, but one could also define the OS as "which lower-level services and interfaces the applications see and are programmed to use" - so the stuff on top of Linux matters. There are more interesting, general, and lower level innovations out there - sure. But the mobile OSes do have improved security from some kind of permission system, VM (only partially because native components are common), one user account per app (IIRC) and such.
    - mghackerlady 5mo ago
      Right but what I'm trying to say is that the core architecture hasn't really changed since the 90s. All the improvements you mentioned are non-applicable to my statements. One user account per app is just a hacky way to use unixes timesharing origins for increased security, VMs and containers slap a bandaid on the problems, and permission systems like android and iOS have are just a hack that works nicely since they use sandboxed software. Plus, these are all security based, which while the topic of the discussion overall, wasn't what I meant when it came to OS innovation in general (an important part, though)

philistine 5mo ago

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.

ebiederm 5mo ago

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.

wmf 5mo ago
binary verification. A check that a whatever is downloaded cannot exceed it's capabilities. That's already handled by the sandbox.

pocksuppet 5mo ago

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.

amavect 5mo ago
One of my friends had his credentials stolen from a trojan infostealer masquerading as a video game, sent from a rando who he mistakenly trusted. If only it had to request user permission to access files outside of its folder. There's a spectrum between full access and full lockdown.
- pocksuppet 5mo ago
  If every app requests that permission, no app requests that permission. Also your passwords would be in your user folder so the app that needs the passwords could read them.
  - amavect 5mo ago
    That condition usually doesn't hold in practice. Very few programs have a reason for reading browser history or cookies. Excel has no purpose accessing the Notepad++ appdata folder. Not all-or-nothing.
    - pocksuppet 5mo ago
      How would your browser read browser history and cookies? It gets its own app data folder? What if I want to export my browser history to another browser - which is currently impossible on Chrome for Android, precisely because no other app is allowed to access Chrome's history file?
      - amavect 5mo ago
        I imagine an OS where the system remembers to keep permanent permission for a program to manage its own files. An app data folder would work. The system should pass the capability on program start. I also imagine a system where graphical programs must call a trusted system file picker to receive a fd. Receiving the capability grants permission. Ideally, Chrome could export browser history to a file, but we live in a fallen world. In any case, an alternative browser must request access through the system file picker, selecting an exported file or selecting the Chrome app data folder. It trades automatic import with user selection. The user has ultimate power, and programs make noise when doing such requests. Please forgive me that I don't know Android system architecture. Searching tells me something about the Storage Access Framework, but I don't know if that truly meets what I describe.

mech422 5mo ago

I'll insert my standard plug for Genode/Sculpt OS here... Capability based, and used/maintained commercially: https://genode.org/ https://genode.org/

rurban 5mo ago
I also like HarmonyOS, the most advanced secure OS nowadays. If they just would have fixed deadlocks also.
- mech422 5mo ago
  Never heard of HarmonyOS before - looking at the website, it doesn't seem to mention being capability based, but it is 'distributed' ??

killerstorm 5mo ago

We kind of have the taste of what capability-based OS would look like in form of a web browser: you can open a web page with a potentially-malicious code and it doesn't have access to any of your files or sensitive data unless you explicitly allow it to. We also have it on mobile operating systems, although some things are a rather coarse-grained. On desktop there's just a lot of inertia. Everyone switching to a new thing is kind of impossible, and some simple add-on to existing systems would look like containers/docker. I think capability-oriented programming languages might actually be an easier way to switch to that model, as it's much easier to adopt a new application than a new OS. E.g. with language-level capabilities (ocaps) you can implement a safe plugin system. That's pretty much non-existent now and is quite relevant - e.g. getting pwned via an IDE plugin is the reality. So maybe a "new Emacs" can be a way to get people to adopt capabilities beyond what we already have in the browser/cloud/etc. - IDE written in a new programming stack which is inherently secure to the point of running potentially-unsafe plugins.

pixel_popping 5mo ago

One word: Qubes.

rurban 5mo ago
Qubes for sure not. Xen seperation on top of Linux sounds nice, but there's still this huge, insecure monolith below. Genode, Harmony or Fuchsia sound much better. And now with a secure language for the surface and drivers it would be even better. But even better no OS, and no attack surface. Only what you need, and properly isolated.

zzo38computer 5mo ago

I think many people have had similar ideas, including I also had ideas about how to design computer and operating system, which can use proxy capabilities. (There are different kind of capability systems, and I think that proxy capabilities has more benefits than only security.) There are still considerations when designing parts of the system to be secure, while also making them have the functions that are desired (although a proxy capability system can be used to add arbitrary further restrictions if needed), but the core system can use proxy capabilities as the core security system. Hashes would still be useful, but that is if you want to check that the package is the one that you intended; it does not prevent you from installing or writing whatever program you want to do, nor to make the program secure, which would be done by separate mechanisms; however, knowing that the package is the one that you intended can be one of the steps of the security, but not the main one. However, security is not the only issue in a computer and operating system design, although it is a significant issue.