3 ms·

Maybe this will finally get people over the hump and adopt OSs based on capability based security. Being required to give a program a whitelist at runtime is al

Maybe this will finally get people over the hump and adopt OSs based on capability based security. Being required to give a program a whitelist at runtime is almost foolproof, for current classes of fools.

tempodox 1y ago
I wish I could share your optimism.
yorwba 1y ago
People will use the equivalent of audit2allow https://linux.die.net/man/1/audit2allow https://linux.die.net/man/1/audit2allow and not go the extra mile of defining fine-grained capabilities to reduce the attack surface to a minimum.
- sitkack 1y ago
  { "permissions": { "allow": [ "Bash(bash:*)", ], "deny": [] } }
zahlman 1y ago
Can I confidently (i.e. with reason to trust the source) install one today from boot media, expect my applications to just work, and have a proper GUI experience out of box?
- nemomarx 1y ago
  Qubes?
  - 3eb7988a1663 1y ago
    Way heavier weight, but it seems like the only realistic security layer on the horizon. VMs have it in their bones to be an isolation layer. Everything else has been trying to bolt security onto some fragile bones.
    - simonw 1y ago
      You can write completely secure code and run it in a locked down VM and it won't protect you from lethal trifecta attacks - these attacks work against systems with no bugs, that's the nature of the attack.
      - 3eb7988a1663 1y ago
        Sure, but if you set yourself up so a locked down VM has access to all three legs - that is going against the intention of Qubes. Qubes ideal is to have isolated VMs per "purpose" (defined by whatever granularity you require): one for nothing but banking, one just for email client, another for general web browsing, one for a password vault, etc. The more exposure to untrusted content (eg web browsing) the more locked down and limited data access it should have. Most Qubes/applications should not have any access to your private files so they have nothing to leak. Then again, all theoretical on my part. I keep messing around with Qubes, but not enough to make it my daily driver.
        saagarjha 1y ago
        If you give an agent access to any of those components without thinking about it you are going to get hacked.
      - switknee 1y ago
        If the VM has: -Access to your private data -Exposure to untrusted content -The ability to externally communicate Then it's not "locked down" Depending on your security requirements you should have only one or two of those capabilities per VM
- mikewarot 1y ago
  No, and I'm surprised it hasn't happened by now. Genode was my hope for this, but they seem to be going away from a self hosting OS/development system. Any application you've got assumes authority to access everything, and thus just won't work. I suppose it's possible that an OS could shim the dialog boxes for file selection, open, save, etc... and then transparently provide access to only those files, but that hasn't happened in the 5 years[1] I've been waiting. (Well, far more than that... here's 14 years ago[2]) This problem was solved back in the 1970s and early 80s... and we're now 40+ years out, still stuck trusting all the code we write. [1] https://news.ycombinator.com/item?id=25428345 https://news.ycombinator.com/item?id=25428345 [2] https://www.quora.com/What-is-the-most-important-question-or-challenge-that-no-one-cares-about-but-you/answer/Mike-Warot https://www.quora.com/What-is-the-most-important-question-or...
  - ElectricalUnion 1y ago
    > I suppose it's possible that an OS could shim the dialog boxes for file selection, open, save, etc... and then transparently provide access to only those files Isn't this the idea behind Flatpak portals? Make your average app sandbox-compatible, except that your average bubblewrap/Flatpak sandbox sucks because it turns out the average app is shit and you often need `filesystem=host` or `filesystem=home` to barely work. It reminds me of that XKCD: https://xkcd.com/1200/ https://xkcd.com/1200/
    - josh-sematic 1y ago
      Or perhaps more relevantly to the overall thread: https://xkcd.com/2044/ https://xkcd.com/2044/
    - ryukafalz 1y ago
      Yes, Flatpak portals are an implementation of the powerbox pattern. They're still underutilized, though there are more portals specified than I realized at least: https://docs.flatpak.org/en/latest/portal-api-reference.html https://docs.flatpak.org/en/latest/portal-api-reference.html That kind of thing (with careful UX design) is how you escape the sandbox cycle though; if you can grant access to resources implicitly as a result of a user action, you can avoid granting applications excessive permissions from the start. (Now, you might also want your "app store" interface to prevent/discourage installation of apps with broad permissions by default as well. There's currently little incentive for a developer not to give themselves the keys to the kingdom.)
whartung 1y ago
Have you, or anyone, ever lived with such a system? For human beings, they sound like a nightmare. We're already getting a taste of it right now with modern systems. Becoming numb to "enter admin password to continue" prompts, getting generic "$program needs $right/privilege on your system -- OK?". "Uh, what does this mean? What if I say no? What if I say YES!?" "Sorry, $program will utterly refuse to run without $right. So, you're SOL." Allow location tracking, all phone tracking, allow cookies. "YES! YES! YES! MAKE IT STOP!" My browser routinely asks me to enable location awareness. For arbitrary web sites, and won't seem to take "No, Heck no, not ever" as a response. Meanwhile, I did that "show your sky" cool little web site, and it seemed to know exactly where I am (likely from my IP). Why does my IDE need admin to install on my Mac? Capability based systems are swell on paper. But, not so sure how they will work in practice.
- fallpeak 1y ago
  This is only a problem when implemented by entities who have no interest in actually solving the problem. In the case of apps, it has been obvious for years that you shouldn't outright tell the app whether a permission was granted (because even aside from outright malice, developers will take the lazy option to error out instead of making their app handle permission denials robustly), every capability needs to have at least one "sandbox" implementation: lie about GPS location, throw away the data they stored after 10 minutes, give them a valid but empty (or fictitious) contacts list, etc.
- zzo38computer 1y ago
  That is because they are badly designed. A system that is better designed will not have these problems. Myself and other people have mentioned some ways to make it better; I think that redesigning the entire computer would fix this and many other problems. One thing that could be done is to specify the interface and intention instead of the implementation, and then any implementation would be connected to it; e.g. if it requests video input then it does not necessarily need to be a camera, and may be a video file, still picture, a filter that will modify the data received by the camera, video output from another program, etc.
- mikewarot 1y ago
skywhopper 1y ago
This type of security is an improvement but doesn’t actually address all the possible risks. Say, if the capabilities you need to complete a useful, intended action match with those that could be used to perform a harmful, fraudulent action.
mcapodici 1y ago
Problem is if people are vibecoding with these tools then the capability "can write to local folder" is safe but once that code is deployed it may have wider consequences. Anything. Any piece of data can be a confused deputy these days.

tempodox 1y ago

I wish I could share your optimism.

yorwba 1y ago

People will use the equivalent of audit2allow https://linux.die.net/man/1/audit2allow https://linux.die.net/man/1/audit2allow and not go the extra mile of defining fine-grained capabilities to reduce the attack surface to a minimum.

sitkack 1y ago
{ "permissions": { "allow": [ "Bash(bash:*)", ], "deny": [] } }

zahlman 1y ago

Can I confidently (i.e. with reason to trust the source) install one today from boot media, expect my applications to just work, and have a proper GUI experience out of box?

nemomarx 1y ago
Qubes?
- 3eb7988a1663 1y ago
  Way heavier weight, but it seems like the only realistic security layer on the horizon. VMs have it in their bones to be an isolation layer. Everything else has been trying to bolt security onto some fragile bones.
  - simonw 1y ago
    You can write completely secure code and run it in a locked down VM and it won't protect you from lethal trifecta attacks - these attacks work against systems with no bugs, that's the nature of the attack.
    - 3eb7988a1663 1y ago
      Sure, but if you set yourself up so a locked down VM has access to all three legs - that is going against the intention of Qubes. Qubes ideal is to have isolated VMs per "purpose" (defined by whatever granularity you require): one for nothing but banking, one just for email client, another for general web browsing, one for a password vault, etc. The more exposure to untrusted content (eg web browsing) the more locked down and limited data access it should have. Most Qubes/applications should not have any access to your private files so they have nothing to leak. Then again, all theoretical on my part. I keep messing around with Qubes, but not enough to make it my daily driver.
      - saagarjha 1y ago
        If you give an agent access to any of those components without thinking about it you are going to get hacked.
    - switknee 1y ago
      If the VM has: -Access to your private data -Exposure to untrusted content -The ability to externally communicate Then it's not "locked down" Depending on your security requirements you should have only one or two of those capabilities per VM
mikewarot 1y ago
No, and I'm surprised it hasn't happened by now. Genode was my hope for this, but they seem to be going away from a self hosting OS/development system. Any application you've got assumes authority to access everything, and thus just won't work. I suppose it's possible that an OS could shim the dialog boxes for file selection, open, save, etc... and then transparently provide access to only those files, but that hasn't happened in the 5 years[1] I've been waiting. (Well, far more than that... here's 14 years ago[2]) This problem was solved back in the 1970s and early 80s... and we're now 40+ years out, still stuck trusting all the code we write. [1] https://news.ycombinator.com/item?id=25428345 https://news.ycombinator.com/item?id=25428345 [2] https://www.quora.com/What-is-the-most-important-question-or-challenge-that-no-one-cares-about-but-you/answer/Mike-Warot https://www.quora.com/What-is-the-most-important-question-or...
- ElectricalUnion 1y ago
  > I suppose it's possible that an OS could shim the dialog boxes for file selection, open, save, etc... and then transparently provide access to only those files Isn't this the idea behind Flatpak portals? Make your average app sandbox-compatible, except that your average bubblewrap/Flatpak sandbox sucks because it turns out the average app is shit and you often need `filesystem=host` or `filesystem=home` to barely work. It reminds me of that XKCD: https://xkcd.com/1200/ https://xkcd.com/1200/
  - josh-sematic 1y ago
    Or perhaps more relevantly to the overall thread: https://xkcd.com/2044/ https://xkcd.com/2044/
  - ryukafalz 1y ago
    Yes, Flatpak portals are an implementation of the powerbox pattern. They're still underutilized, though there are more portals specified than I realized at least: https://docs.flatpak.org/en/latest/portal-api-reference.html https://docs.flatpak.org/en/latest/portal-api-reference.html That kind of thing (with careful UX design) is how you escape the sandbox cycle though; if you can grant access to resources implicitly as a result of a user action, you can avoid granting applications excessive permissions from the start. (Now, you might also want your "app store" interface to prevent/discourage installation of apps with broad permissions by default as well. There's currently little incentive for a developer not to give themselves the keys to the kingdom.)

whartung 1y ago

Have you, or anyone, ever lived with such a system? For human beings, they sound like a nightmare. We're already getting a taste of it right now with modern systems. Becoming numb to "enter admin password to continue" prompts, getting generic "$program needs $right/privilege on your system -- OK?". "Uh, what does this mean? What if I say no? What if I say YES!?" "Sorry, $program will utterly refuse to run without $right. So, you're SOL." Allow location tracking, all phone tracking, allow cookies. "YES! YES! YES! MAKE IT STOP!" My browser routinely asks me to enable location awareness. For arbitrary web sites, and won't seem to take "No, Heck no, not ever" as a response. Meanwhile, I did that "show your sky" cool little web site, and it seemed to know exactly where I am (likely from my IP). Why does my IDE need admin to install on my Mac? Capability based systems are swell on paper. But, not so sure how they will work in practice.

fallpeak 1y ago
This is only a problem when implemented by entities who have no interest in actually solving the problem. In the case of apps, it has been obvious for years that you shouldn't outright tell the app whether a permission was granted (because even aside from outright malice, developers will take the lazy option to error out instead of making their app handle permission denials robustly), every capability needs to have at least one "sandbox" implementation: lie about GPS location, throw away the data they stored after 10 minutes, give them a valid but empty (or fictitious) contacts list, etc.
zzo38computer 1y ago
That is because they are badly designed. A system that is better designed will not have these problems. Myself and other people have mentioned some ways to make it better; I think that redesigning the entire computer would fix this and many other problems. One thing that could be done is to specify the interface and intention instead of the implementation, and then any implementation would be connected to it; e.g. if it requests video input then it does not necessarily need to be a camera, and may be a video file, still picture, a filter that will modify the data received by the camera, video output from another program, etc.
mikewarot 1y ago

skywhopper 1y ago

This type of security is an improvement but doesn’t actually address all the possible risks. Say, if the capabilities you need to complete a useful, intended action match with those that could be used to perform a harmful, fraudulent action.

mcapodici 1y ago

Problem is if people are vibecoding with these tools then the capability "can write to local folder" is safe but once that code is deployed it may have wider consequences. Anything. Any piece of data can be a confused deputy these days.