7 ms·

If our operating systems didn't blindly trust programs, we wouldn't need web browsers as a special category of interface. You could just put your binaries up f

If our operating systems didn't blindly trust programs, we wouldn't need web browsers as a special category of interface. You could just put your binaries up for the major OSs to access your data, and people could use them in a native context. Alas, we're in the timeline without capability based security. where users can't just give a file to a program at runtime using a (powerbox) dialog.

spankalee 4y ago
Fuchsia is be incredibly interesting for this reason.
- wolverine876 4y ago
  How so?
  - spankalee 4y ago
    Because Fuchsia is exactly a capabilities-based OS as the OP describes.
    - mikewarot 4y ago
      If Fuchsia ever appears as an end user operating system, this might be true.
drewcoo 4y ago
I don't understand. What is the security model you propose? With at least two examples, please. To help me understand.
- still_grokking 4y ago
  Maybe as a starter: https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security For examples have a look at the "Implementations" section.
- nine_k 4y ago
  When you download a program from the internets, it does not have access to any of your stuff. Can't read files. Can't make network requests. Can't access cameras or microphones. You explicitly give it permissions to access something: give it a document you want to edit, allow it to save a result at some location (without giving it an idea what else exists at that location), allow it to connect to certain hosts on the internet, but not others, politely decline a request to use your camera, etc. Very much like you do with a web app running in your browser.
  - ModernMech 4y ago
    Another example: you have a printer, a printer server, and N clients connected to the server. You send a capability to the clients that grants them usage of the printer. That capability allows them to print at certain time in black and white only, but the marketing department gets a capability that allows them to print in color. Your customer comes to the office comes and wants to use the printer while he’s there, so you use your capability to send them a capability that will give them access to the printer (b/w only still, they can’t get color because you can’t get color) for an hour. However their capability is restricted such that they will not be able to grant anyone else access to the printer
- mikewarot 4y ago
  Example 1 Take $5 from your wallet to pay for a sandwich. That bill is a capability. You can't accidentally give away your car when you do it. You can easily delegate the giving of the $5 to someone else safely. Example 2 Take a file on a floppy disk for an IBM XT and make a backup of it. You can hand that backup disk to anyone and your original is safe. You can use that file with any random shareware disk from your user group meeting and in no way could it cause you any more loss than the disk in it is on. A disk is a capability. Example 3 You are asked your location. You reply correctly. The answer does not allow you to be tracked forever. Example 4 You have a 15 amp outlet. You can't take down the power grid by accident, nor burn down the house. The outlet is a 15 amp capability.
charcircuit 4y ago
>Alas, we're in the timeline without capability based security Mobile operating systems (aka modern personal computing) say hello.
- still_grokking 4y ago
  No, that's not the same. There is no capability security on the OS level. Otherwise Android wouldn't have a malware issue and iPhones wouldn't need to be locked up against third party apps.
  - ljm 4y ago
    Have you considered that an approval process is one aspect of a capability solution? You know, the same way that you ask for code review before merging to prod.
    - still_grokking 4y ago
      No, I didn't as this makes no sense, that's not what this technical term describes. I've liked Wikipedia on that topic already in this thread. Please take a look.
      - loup-vaillant 4y ago
        Not in the direct ancestors of this comments you haven't. When referring to cousin comments like this one https://news.ycombinator.com/item?id=34306946 https://news.ycombinator.com/item?id=34306946 it's generally a good idea to put a link to them instead of having us dig through the whole discussion (I literally had to [Ctrl-F] your handle). And for bystanders, here's the Wikipedia link: https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security
        still_grokking 4y ago
        Thanks for the pointer! My reasoning was that it would be rude to link to myself, to a comment that showed up at this time just on the same screen as this one. But I guess you're right. A link would not hurt, but make it more easy to discover the mentioned content.
sp332 4y ago
It's moving that way. Even WASM is expanding out of browsers with WASI.
- still_grokking 4y ago
  Only to bring us back to Unix legacy APIs. Don't get me wrong, WASM is a nice idea with some nice properties. But WASI isn't a real improvement to the status quo in general.
  - sunfish 4y ago
    Not yet, at least. But we're working on that :-).
    - still_grokking 4y ago
      Honest question: How can this work out if the legacy APIs are still at the bottom?
      - sunfish 4y ago
        It depends on what you mean by "at the bottom". If you mean at the bottom of the wasm, the the answer is, those won't be legacy APIs. The direction we're heading is to provide POSIX compatibility as an emulation layer on top of a cleaner foundation, rather than just doing POSIX at the base layer. If you mean that all Wasm engines today are implemented on top of traditional operating system APIs, then yes, that is how things will often work, but that's ok. What really matters is how the virtual platform works. We don't have to expose things like "the filesystem namespace" directly to wasm, even if it's present in the host. And if we don't expose "the filesystem namespace", then we don't have the associated problems, even if the underlying host has them.
        still_grokking 4y ago
        > The direction we're heading is to provide POSIX compatibility as an emulation layer on top of a cleaner foundation, rather than just doing POSIX at the base layer. What's that "cleaner foundation"? Next thing is: POSIX is the legacy stuff. If it's there nothing will change. And not even to mention that the stack is going to look something like: Hardware >> Hardware emulating some ISA (e.g. x86) >> C abstract machine >> POSIX >> VM emulating some ISA >> "container" emulating POSIX >> WASM VM >> emulation of POSIX APIs >> legacy applications written for some ISA & POSIX I call this construct "layers of madness"… ;-)
ako 4y ago
Wouldn’t capability based security just bring you the current situation on mobile phones where most users simply approve access as they have no clue what is being asked, nor do they have real alternatives?
- Kinrany 4y ago
  There is no alternative. Mobile devices and browsers are equivalent to a locked down mode where the user is only allowed to approve a restricted set of capabilities.
- loup-vaillant 4y ago
  Cluelessness have been catered to to insane degrees in the name of sales, and users are now used to just clicking through whatever pops up until they see the thing they want to see. But if (1) they'd been properly taught, (2) apps asked only for the permissions they need instead of acting like all your data are belong to them, and (3) people actually read those damn pop ups (which they might have if there weren't so many)… capability based security is actually fairly easy to understand.
- tonyg 4y ago
  No: one possible alternative interaction would be the user handing the program a representation of an instance of the class of object requested. For instance, if the program wants a camera, it says "drag and drop a camera here". The user picks up a camera object - maybe the real camera, maybe a proxy for the real camera that will only work once to take a single photo, maybe a dummy camera, the app can't tell - and drops it on the region.
  - coldtea 4y ago
    So? Nothing really changes with this scheme, compared to "Allow camera access" banner.
    - ModernMech 4y ago
      It’s different in that with capabilities the choice is no longer allow/deny, but allow/deny/circumvent. The allow/deny choice makes it so that the user is incentivized to allow things they don’t want just to get access to the app. If I can’t use the app without giving it access to my location, then I’m incentivized to just give it access in order to get what I want. Capabilities let you programmatically customize how to manage resources, so you’re not forced to click through just to get to the app. Furthermore, capabilities are more fine-grained. Today an app will ask for your location and you get to choose yes/no. If you say yes, it has full access to the GPS forever until revoked, sometimes in the background. Give it network access and it has that forever as well, and it can send anything to anyone (including the GPS data you just gave it access to.) Capability based security would allow you to give it access to the GPS for a limited time, or to give it access to a sensor spoofing service if it really needs that data. If you give it network access it would be for certain times, or it could only send data to a whitelist of servers. Moreover you can restrict the app from sharing granted capabilities to other apps. Or vice versa, you can delegate apps to work on your behalf and share capabilities with other apps, which you can later centrally revoke or restrict. It’s really a better security regime than what the major operating systems have ossified around.
mike_hearn 4y ago
Actually all operating systems support PowerBoxes these days. It's an automatic part of the macOS Sandbox, it's a part of the FlatPak sandbox and there's an equivalent for Windows too. You can also implement this yourself the way browsers do because every OS supports the sending of file descriptors and handles to other processes, and they all support kernel level sandboxing now.
- telotortium 4y ago
  For people who (like me) have never heard the term "powerbox", it's this: http://wiki.c2.com/?PowerBox http://wiki.c2.com/?PowerBox

spankalee 4y ago

Fuchsia is be incredibly interesting for this reason.

wolverine876 4y ago
How so?
- spankalee 4y ago
  Because Fuchsia is exactly a capabilities-based OS as the OP describes.
  - mikewarot 4y ago
    If Fuchsia ever appears as an end user operating system, this might be true.

drewcoo 4y ago

I don't understand. What is the security model you propose? With at least two examples, please. To help me understand.

still_grokking 4y ago
Maybe as a starter: https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security For examples have a look at the "Implementations" section.
nine_k 4y ago
When you download a program from the internets, it does not have access to any of your stuff. Can't read files. Can't make network requests. Can't access cameras or microphones. You explicitly give it permissions to access something: give it a document you want to edit, allow it to save a result at some location (without giving it an idea what else exists at that location), allow it to connect to certain hosts on the internet, but not others, politely decline a request to use your camera, etc. Very much like you do with a web app running in your browser.
- ModernMech 4y ago
  Another example: you have a printer, a printer server, and N clients connected to the server. You send a capability to the clients that grants them usage of the printer. That capability allows them to print at certain time in black and white only, but the marketing department gets a capability that allows them to print in color. Your customer comes to the office comes and wants to use the printer while he’s there, so you use your capability to send them a capability that will give them access to the printer (b/w only still, they can’t get color because you can’t get color) for an hour. However their capability is restricted such that they will not be able to grant anyone else access to the printer
mikewarot 4y ago
Example 1 Take $5 from your wallet to pay for a sandwich. That bill is a capability. You can't accidentally give away your car when you do it. You can easily delegate the giving of the $5 to someone else safely. Example 2 Take a file on a floppy disk for an IBM XT and make a backup of it. You can hand that backup disk to anyone and your original is safe. You can use that file with any random shareware disk from your user group meeting and in no way could it cause you any more loss than the disk in it is on. A disk is a capability. Example 3 You are asked your location. You reply correctly. The answer does not allow you to be tracked forever. Example 4 You have a 15 amp outlet. You can't take down the power grid by accident, nor burn down the house. The outlet is a 15 amp capability.

charcircuit 4y ago

>Alas, we're in the timeline without capability based security Mobile operating systems (aka modern personal computing) say hello.

still_grokking 4y ago
No, that's not the same. There is no capability security on the OS level. Otherwise Android wouldn't have a malware issue and iPhones wouldn't need to be locked up against third party apps.
- ljm 4y ago
  Have you considered that an approval process is one aspect of a capability solution? You know, the same way that you ask for code review before merging to prod.
  - still_grokking 4y ago
    No, I didn't as this makes no sense, that's not what this technical term describes. I've liked Wikipedia on that topic already in this thread. Please take a look.
    - loup-vaillant 4y ago
      Not in the direct ancestors of this comments you haven't. When referring to cousin comments like this one https://news.ycombinator.com/item?id=34306946 https://news.ycombinator.com/item?id=34306946 it's generally a good idea to put a link to them instead of having us dig through the whole discussion (I literally had to [Ctrl-F] your handle). And for bystanders, here's the Wikipedia link: https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security
      - still_grokking 4y ago
        Thanks for the pointer! My reasoning was that it would be rude to link to myself, to a comment that showed up at this time just on the same screen as this one. But I guess you're right. A link would not hurt, but make it more easy to discover the mentioned content.

sp332 4y ago

It's moving that way. Even WASM is expanding out of browsers with WASI.

still_grokking 4y ago
Only to bring us back to Unix legacy APIs. Don't get me wrong, WASM is a nice idea with some nice properties. But WASI isn't a real improvement to the status quo in general.
- sunfish 4y ago
  Not yet, at least. But we're working on that :-).
  - still_grokking 4y ago
    Honest question: How can this work out if the legacy APIs are still at the bottom?
    - sunfish 4y ago
      It depends on what you mean by "at the bottom". If you mean at the bottom of the wasm, the the answer is, those won't be legacy APIs. The direction we're heading is to provide POSIX compatibility as an emulation layer on top of a cleaner foundation, rather than just doing POSIX at the base layer. If you mean that all Wasm engines today are implemented on top of traditional operating system APIs, then yes, that is how things will often work, but that's ok. What really matters is how the virtual platform works. We don't have to expose things like "the filesystem namespace" directly to wasm, even if it's present in the host. And if we don't expose "the filesystem namespace", then we don't have the associated problems, even if the underlying host has them.
      - still_grokking 4y ago
        > The direction we're heading is to provide POSIX compatibility as an emulation layer on top of a cleaner foundation, rather than just doing POSIX at the base layer. What's that "cleaner foundation"? Next thing is: POSIX is the legacy stuff. If it's there nothing will change. And not even to mention that the stack is going to look something like: Hardware >> Hardware emulating some ISA (e.g. x86) >> C abstract machine >> POSIX >> VM emulating some ISA >> "container" emulating POSIX >> WASM VM >> emulation of POSIX APIs >> legacy applications written for some ISA & POSIX I call this construct "layers of madness"… ;-)

ako 4y ago

Wouldn’t capability based security just bring you the current situation on mobile phones where most users simply approve access as they have no clue what is being asked, nor do they have real alternatives?

Kinrany 4y ago
There is no alternative. Mobile devices and browsers are equivalent to a locked down mode where the user is only allowed to approve a restricted set of capabilities.
loup-vaillant 4y ago
Cluelessness have been catered to to insane degrees in the name of sales, and users are now used to just clicking through whatever pops up until they see the thing they want to see. But if (1) they'd been properly taught, (2) apps asked only for the permissions they need instead of acting like all your data are belong to them, and (3) people actually read those damn pop ups (which they might have if there weren't so many)… capability based security is actually fairly easy to understand.
tonyg 4y ago
No: one possible alternative interaction would be the user handing the program a representation of an instance of the class of object requested. For instance, if the program wants a camera, it says "drag and drop a camera here". The user picks up a camera object - maybe the real camera, maybe a proxy for the real camera that will only work once to take a single photo, maybe a dummy camera, the app can't tell - and drops it on the region.
- coldtea 4y ago
  So? Nothing really changes with this scheme, compared to "Allow camera access" banner.
  - ModernMech 4y ago
    It’s different in that with capabilities the choice is no longer allow/deny, but allow/deny/circumvent. The allow/deny choice makes it so that the user is incentivized to allow things they don’t want just to get access to the app. If I can’t use the app without giving it access to my location, then I’m incentivized to just give it access in order to get what I want. Capabilities let you programmatically customize how to manage resources, so you’re not forced to click through just to get to the app. Furthermore, capabilities are more fine-grained. Today an app will ask for your location and you get to choose yes/no. If you say yes, it has full access to the GPS forever until revoked, sometimes in the background. Give it network access and it has that forever as well, and it can send anything to anyone (including the GPS data you just gave it access to.) Capability based security would allow you to give it access to the GPS for a limited time, or to give it access to a sensor spoofing service if it really needs that data. If you give it network access it would be for certain times, or it could only send data to a whitelist of servers. Moreover you can restrict the app from sharing granted capabilities to other apps. Or vice versa, you can delegate apps to work on your behalf and share capabilities with other apps, which you can later centrally revoke or restrict. It’s really a better security regime than what the major operating systems have ossified around.

mike_hearn 4y ago

Actually all operating systems support PowerBoxes these days. It's an automatic part of the macOS Sandbox, it's a part of the FlatPak sandbox and there's an equivalent for Windows too. You can also implement this yourself the way browsers do because every OS supports the sending of file descriptors and handles to other processes, and they all support kernel level sandboxing now.

telotortium 4y ago
For people who (like me) have never heard the term "powerbox", it's this: http://wiki.c2.com/?PowerBox http://wiki.c2.com/?PowerBox