5 ms·

we need to run programs with less authority than the user running them, and we still lack a good conceptual model for doing that Isn't this now the standard re

we need to run programs with less authority than the user running them, and we still lack a good conceptual model for doing that Isn't this now the standard reality for most desktop and mobile OSs? "Allow write to SD card" is far, far too powerful a privilege to grant. Granting a permission based upon user approval is never secure anyway since if they want to see the porn / flashing lights they are going to click the button regardless. Having spent some time with both carriers and mobile device manufacturers, there are also areas of undeclared commercial utility in keeping control with the OS (device manufacturer) and out of the hands of the user: DRM, app sales, increased chargeable mobile data use, reduced chance of non-cellular data paths (mesh networking), etc.

mikewarot 6y ago
People manage permissions just fine in the real world... if you have money in your pocket, you can pick and choose what portion of it to hand to the cashier when you're purchasing something. When you had someone $3.50... you're giving them $3.50 of capability, and no matter how clever the Loch Ness Monster is, they'll never get more than that $3.50. If on the other hand, you have to give them the entire wallet... like you do in Windows, Linux, etc... the game is over. Capability Based Security is NOT the same as "Global Permission to do X" PayPal exists because it is an instantiation of capabilities for finance on the internet.
- contingencies 6y ago
  you can pick and choose what portion... That was the old way. The new way is you give them your credit card or WeChat 'bill me' code. You get billed whatever the merchant wants to bill. Any post-facto complaint will be at the cost of your own time. Your further analogy is factually inaccurate. Under Windows, AFAIK most programs have a partially restricted permission set, hence Run as administrator. In Linux, under modern distributions, most programs run in both a user and a cgroup context, and some under further restrictions such as chroot and caps.
  - ryukafalz 6y ago
    >The new way is you give them your credit card or WeChat 'bill me' code. You get billed whatever the merchant wants to bill. Any post-facto complaint will be at the cost of your own time. Sure, that may be the "new" way, but that doesn't mean it's better! Much of the payment fraud online couldn't exist if customers were in control of how much money to send and when rather than the merchant. >Under Windows, AFAIK most programs have a partially restricted permission set, hence Run as administrator. In Linux, under modern distributions, most programs run in both a user and a cgroup context, and some under further restrictions such as chroot and caps. Under normal circumstances, they're restricted only to the extent that your user is restricted. That's far from the level of granularity that GP is talking about.
benlivengood 6y ago
> Isn't this now the standard reality for most desktop and mobile OSs? Not really, no. Because there isn't a comprehensive intent layer in the UI that is fully trusted and in which the user can grant capabilities. Just a couple examples; if you download a PDF file with a mobile browser and want to open it in an app, the only option is to grant eternal (unless you manually revoke it) access to the local file system to the entire viewer app. A capability-aware UI would, at the "what do you want to do with this file?" system dialog grant a one time capability to read the particular file to the app the user picks. The capability persists as long as the app retains it. The app can't fork off a sub-process or send it to another app and clone the capability to the file; it would have to ask the user to do that. The mechanism for that trusted user request and response is where all UIs (and most CLIs) fail. Designing a safe and useful capability desktop/mobile environment is hard. Modern UIs and CLIs are just papering over the details of actual objects in the privilege system. Icons and filenames are only a human-readable representation of objects accessible with capabilities and so there's a disconnect between UI representation, user intent, and user interactions. Solving that means replacing arbitrary custom UIs with trusted, object-aware system UIs that reveal the actual state of capabilities and objects instead of a simplified representation. > Granting a permission based upon user approval is never secure anyway since if they want to see the porn / flashing lights they are going to click the button regardless. The UI model would have to be significantly different with a lot of trusted components. Basically any UI element that can grant a capability to another app/process has to be part of the trusted system. That means a user-level app can't even ask for permissions to objects because it can't see them, know they exist, or refer to them in a way the system UI could grant a capability. Interaction between applications would be more like a smart clipboard; a user would open their camera app, take a picture, and grant a read capability to an app that's waiting for it. There's a lot of 'convenience' lost in a pure capability system because there's no default trust in the good intentions of app developers. There is a potential further development that allows convenience; formal proofs for application software that adheres to a particular data management policy. Say instagram wants to formally verify that photos taken automatically by the app (selfie button or whatever) can never be uploaded without user permission. Prove that the component for taking photos within the app drops all capabilities to the network and the main app itself before taking any photos; all it can do is fill up a particular folder/directory with new photos that are visible to the user, who can then trigger an upload (grant capability to a particular photo to the main app from a secure view of the directory) with another trusted interface. That trusted component could be granted a capability to the camera itself once the proof is verified.

mikewarot 6y ago

People manage permissions just fine in the real world... if you have money in your pocket, you can pick and choose what portion of it to hand to the cashier when you're purchasing something. When you had someone $3.50... you're giving them $3.50 of capability, and no matter how clever the Loch Ness Monster is, they'll never get more than that $3.50. If on the other hand, you have to give them the entire wallet... like you do in Windows, Linux, etc... the game is over. Capability Based Security is NOT the same as "Global Permission to do X" PayPal exists because it is an instantiation of capabilities for finance on the internet.

contingencies 6y ago
you can pick and choose what portion... That was the old way. The new way is you give them your credit card or WeChat 'bill me' code. You get billed whatever the merchant wants to bill. Any post-facto complaint will be at the cost of your own time. Your further analogy is factually inaccurate. Under Windows, AFAIK most programs have a partially restricted permission set, hence Run as administrator. In Linux, under modern distributions, most programs run in both a user and a cgroup context, and some under further restrictions such as chroot and caps.
- ryukafalz 6y ago
  >The new way is you give them your credit card or WeChat 'bill me' code. You get billed whatever the merchant wants to bill. Any post-facto complaint will be at the cost of your own time. Sure, that may be the "new" way, but that doesn't mean it's better! Much of the payment fraud online couldn't exist if customers were in control of how much money to send and when rather than the merchant. >Under Windows, AFAIK most programs have a partially restricted permission set, hence Run as administrator. In Linux, under modern distributions, most programs run in both a user and a cgroup context, and some under further restrictions such as chroot and caps. Under normal circumstances, they're restricted only to the extent that your user is restricted. That's far from the level of granularity that GP is talking about.

benlivengood 6y ago

> Isn't this now the standard reality for most desktop and mobile OSs? Not really, no. Because there isn't a comprehensive intent layer in the UI that is fully trusted and in which the user can grant capabilities. Just a couple examples; if you download a PDF file with a mobile browser and want to open it in an app, the only option is to grant eternal (unless you manually revoke it) access to the local file system to the entire viewer app. A capability-aware UI would, at the "what do you want to do with this file?" system dialog grant a one time capability to read the particular file to the app the user picks. The capability persists as long as the app retains it. The app can't fork off a sub-process or send it to another app and clone the capability to the file; it would have to ask the user to do that. The mechanism for that trusted user request and response is where all UIs (and most CLIs) fail. Designing a safe and useful capability desktop/mobile environment is hard. Modern UIs and CLIs are just papering over the details of actual objects in the privilege system. Icons and filenames are only a human-readable representation of objects accessible with capabilities and so there's a disconnect between UI representation, user intent, and user interactions. Solving that means replacing arbitrary custom UIs with trusted, object-aware system UIs that reveal the actual state of capabilities and objects instead of a simplified representation. > Granting a permission based upon user approval is never secure anyway since if they want to see the porn / flashing lights they are going to click the button regardless. The UI model would have to be significantly different with a lot of trusted components. Basically any UI element that can grant a capability to another app/process has to be part of the trusted system. That means a user-level app can't even ask for permissions to objects because it can't see them, know they exist, or refer to them in a way the system UI could grant a capability. Interaction between applications would be more like a smart clipboard; a user would open their camera app, take a picture, and grant a read capability to an app that's waiting for it. There's a lot of 'convenience' lost in a pure capability system because there's no default trust in the good intentions of app developers. There is a potential further development that allows convenience; formal proofs for application software that adheres to a particular data management policy. Say instagram wants to formally verify that photos taken automatically by the app (selfie button or whatever) can never be uploaded without user permission. Prove that the component for taking photos within the app drops all capabilities to the network and the main app itself before taking any photos; all it can do is fill up a particular folder/directory with new photos that are visible to the user, who can then trigger an upload (grant capability to a particular photo to the main app from a secure view of the directory) with another trusted interface. That trusted component could be granted a capability to the camera itself once the proof is verified.