7 ms·

The fact that the standard model of computing is that applications are opaque machine code blobs that can access everything in your user permission space is the

The fact that the standard model of computing is that applications are opaque machine code blobs that can access everything in your user permission space is the core problem in privacy and malware. Applications should see nothing but their executable jail, and whatever was intentionally allowed to them by the user (eg, Open file dialog giving the application an opaque file handle, etc, not carte blanche access to the entire filesystem). Ideally, the notion of machine code blobs should be done away with as well. Mobile OSes got to rethink everything in an era of constant adversarial connectivity and started off on a better foot in this regard.

saagarjha 6y ago
macOS ships with a quite strong and granular capability-based security model with its sandboxing mechanism (at least, when it works and is applied correctly). The feature is there, advanced applications already make use of it, but it is difficult to get arbitrary applications to adopt it (its inner workings are declared SPI after all) and it is not really exposed to the user at all except via App Sandbox, which is fairly limiting.
- andrekandre 6y ago
  > but it is difficult to get arbitrary applications to adopt it just curious, but what makes it specifically hard?
  - saagarjha 6y ago
    > its inner workings are declared SPI after all SPI is system private interface, also known as private API–Apple doesn't document it, can change it at any time, and usually discourages its use.
    - andrekandre 6y ago
      ah, i see the term threw me off
- hyperdimension 6y ago
  What does SPI stand for?
  - saagarjha 6y ago
    https://news.ycombinator.com/item?id=24217553 https://news.ycombinator.com/item?id=24217553
shakna 6y ago
> Applications should see nothing but their executable jail, and whatever was intentionally allowed to them by the user Whilst this works for some programs, it gets... Difficult... When dealing with others. What permissions should sh get, for example? And do the programs it will call inherit the same, or do they get their own permissions, or a hybrid?
- dwaite 6y ago
  > What permissions should sh get, for example? The permission model works pretty similar here to a restricted user account. It sees system files as read-only, cannot see the contents of certain files and directories, etc. The root of the filesystem might be of the parent system or of the sandbox itself. On macOS, reading certain directories (like the user's Desktop) will result in a user consent prompt due the sensitive contents. There is, after all, no guarantee that the request was directly initiated by the user, and not some curl-pipe shell script. There is however a "Developer Tools" entitlement that encompasses all of these sorts of prompts - but this is meant to be enabled through a developer action and not any user-presented prompt. On macOS, there are basically higher-than-root system integrity protections, such as modifying files that the OS maintains. You can disable this system protection by booting into recovery mode and running a command-line tool. Generally, the goal with system integrity protection is not to restrict professional work but to restrict the ability to publish software that tells the user to disable system-wide protections. There was recently an issue with the Google installer where a Chrome update wiped out part of the system when these protections were disabled, primarily noticed on hackintoshes and video production Macs where tools require SPI to be disabled to run unsigned kernel extensions, etc. Oops. Apple has been trying to reduce the need across macOS releases to have applications need to be installed at all, with recent releases making items like browser, system, and kernel extensions bundled inside the application itself rather than being distributed across the filesystem. The goal is likely to eliminate app installation on macOS from needing to be a privileged operation.
  - shakna 6y ago
    The question was more about _should_, than _does_, and there's all sorts of places it currently breaks down. For example, say you use pass [0], it's just a Bash script. You want it to be able to access pbcopy/pbpaste, for basic functionality to work. You don't want to give it permission every time. However, you probably don't want sh to be able to access pbcopy/pbpaste without permission. Scripts themselves should hold certain permissions, but those permissions are currently held by their host application, because sh /usr/local/bin/pass isn't identified by the system as an application. The app is still considered to be sh. [0] https://www.passwordstore.org/ https://www.passwordstore.org/
badsectoracula 6y ago
This works for some type of software, but not all type of software. For example a file server or a file manager wont work. A VCS client wont work. A game engine that needs to keep track of imported resources (especially when you want automatic imports when the file is saved via a 3rd party tool - e.g. saving a model on Blender or a texture on Krita causes an automatic reimport/convert to the engine's format). Basically any sort of content management software that doesn't provide everything itself but relies on 3rd party tools already installed on the user's machine wont work. Software like clipboard managers also wont work. Screen sharing and remote desktop software similarly wont work. Screencast software wont work. Hotkeys software wont work. Most desktop automation software wont work. I could go on and start looking at what i have installed to extend this list (i'm sure most of the software i have on my PC wont work), but i guess you get the idea. Almost everything that doesn't fit in the media consumption model that you'll often find on a phone or a tablet wont work (and amusingly enough, at least on my Android, stuff like a file server does work, though i've heard Google wants to remove that functionality).
- josephg 6y ago
  Sure it does! We just need sufficiently granular permissions for all of this stuff. “Do you want to give ClipboardManager access to your clipboard?” Yes. “Do you want to give TikTok access to your clipboard?” No. I agree that clicking a million permission boxes is annoying but ideally it should only be something needed for apps that don’t fit the media consumption model. The real problem is that the desktop security model is outdated - it was designed for a world where software developers are trusted by default and users need to protect their data from each other. Today we can’t trust that developers will respect my data. I mean, the fact that any application I run or any npm module I transitively install could upload or delete any of my personal documents is insane. We absolutely need to preserve my ability to run software I write, and run screencast software, file servers, etc. But permission to read my data should not be given by default to any software I happen to run. The Epic thing makes me nervous but generally I think Apple’s direction here is the right one.
  - lukeschlather 6y ago
stjohnswarts 6y ago
That should probably be an option, but I'll take ownership of my hardware and data not you or Apple. I don't mind having the checks in there as long as I can overrule them. Otherwise you just get the Epic treatment and you don't really own your hardware, you're just loaning it from Apple and you can only do what they let you do. That, to me, is a losing proposition in the long haul.
kumarvvr 6y ago
The average user would be terribly confused by all this and would hardly bother to even analyze requirements that are asked by any app. They will simply allow everything. More importantly, if they see something like a permissions screen, they will have a false sense of security. And severe restrictions on the app, would hamper user experience. Code signing and developer ID are the most practical means to ensure quality software.
- angry_octet 6y ago
  Users of iOS seem capable of forming nuanced views of the permissions each app should have. I don't see why this shouldn't be done for macos. The problem is 'everything' apps like browsers -- you need to be able to enforce permissions for individual sites. With weak sandboxing we're still left with the problem of LPE -- once you're on the box (with, by default, unlimited network access!) you can gain root quite quickly, because the kernel interface is rather large. So you still need code signing and developer IDs. However dev IDs could be a federated system -- user's shouldn't have to accept Apple as the total and sole authority for accepting or rejecting apps/developers.
deleted 6y ago
[deleted]
necovek 6y ago
You get that with "snaps" on Ubuntu (and I imagine flatpak too).
bagacrap 6y ago
I don't think the permissions model in mobile OSes was good to start although now it's slightly better. The web is where "they" got it right.

saagarjha 6y ago

macOS ships with a quite strong and granular capability-based security model with its sandboxing mechanism (at least, when it works and is applied correctly). The feature is there, advanced applications already make use of it, but it is difficult to get arbitrary applications to adopt it (its inner workings are declared SPI after all) and it is not really exposed to the user at all except via App Sandbox, which is fairly limiting.

andrekandre 6y ago
> but it is difficult to get arbitrary applications to adopt it just curious, but what makes it specifically hard?
- saagarjha 6y ago
  > its inner workings are declared SPI after all SPI is system private interface, also known as private API–Apple doesn't document it, can change it at any time, and usually discourages its use.
  - andrekandre 6y ago
    ah, i see the term threw me off
hyperdimension 6y ago
What does SPI stand for?
- saagarjha 6y ago
  https://news.ycombinator.com/item?id=24217553 https://news.ycombinator.com/item?id=24217553

shakna 6y ago

> Applications should see nothing but their executable jail, and whatever was intentionally allowed to them by the user Whilst this works for some programs, it gets... Difficult... When dealing with others. What permissions should sh get, for example? And do the programs it will call inherit the same, or do they get their own permissions, or a hybrid?

dwaite 6y ago
> What permissions should sh get, for example? The permission model works pretty similar here to a restricted user account. It sees system files as read-only, cannot see the contents of certain files and directories, etc. The root of the filesystem might be of the parent system or of the sandbox itself. On macOS, reading certain directories (like the user's Desktop) will result in a user consent prompt due the sensitive contents. There is, after all, no guarantee that the request was directly initiated by the user, and not some curl-pipe shell script. There is however a "Developer Tools" entitlement that encompasses all of these sorts of prompts - but this is meant to be enabled through a developer action and not any user-presented prompt. On macOS, there are basically higher-than-root system integrity protections, such as modifying files that the OS maintains. You can disable this system protection by booting into recovery mode and running a command-line tool. Generally, the goal with system integrity protection is not to restrict professional work but to restrict the ability to publish software that tells the user to disable system-wide protections. There was recently an issue with the Google installer where a Chrome update wiped out part of the system when these protections were disabled, primarily noticed on hackintoshes and video production Macs where tools require SPI to be disabled to run unsigned kernel extensions, etc. Oops. Apple has been trying to reduce the need across macOS releases to have applications need to be installed at all, with recent releases making items like browser, system, and kernel extensions bundled inside the application itself rather than being distributed across the filesystem. The goal is likely to eliminate app installation on macOS from needing to be a privileged operation.
- shakna 6y ago
  The question was more about _should_, than _does_, and there's all sorts of places it currently breaks down. For example, say you use pass [0], it's just a Bash script. You want it to be able to access pbcopy/pbpaste, for basic functionality to work. You don't want to give it permission every time. However, you probably don't want sh to be able to access pbcopy/pbpaste without permission. Scripts themselves should hold certain permissions, but those permissions are currently held by their host application, because sh /usr/local/bin/pass isn't identified by the system as an application. The app is still considered to be sh. [0] https://www.passwordstore.org/ https://www.passwordstore.org/

badsectoracula 6y ago

This works for some type of software, but not all type of software. For example a file server or a file manager wont work. A VCS client wont work. A game engine that needs to keep track of imported resources (especially when you want automatic imports when the file is saved via a 3rd party tool - e.g. saving a model on Blender or a texture on Krita causes an automatic reimport/convert to the engine's format). Basically any sort of content management software that doesn't provide everything itself but relies on 3rd party tools already installed on the user's machine wont work. Software like clipboard managers also wont work. Screen sharing and remote desktop software similarly wont work. Screencast software wont work. Hotkeys software wont work. Most desktop automation software wont work. I could go on and start looking at what i have installed to extend this list (i'm sure most of the software i have on my PC wont work), but i guess you get the idea. Almost everything that doesn't fit in the media consumption model that you'll often find on a phone or a tablet wont work (and amusingly enough, at least on my Android, stuff like a file server does work, though i've heard Google wants to remove that functionality).

josephg 6y ago
Sure it does! We just need sufficiently granular permissions for all of this stuff. “Do you want to give ClipboardManager access to your clipboard?” Yes. “Do you want to give TikTok access to your clipboard?” No. I agree that clicking a million permission boxes is annoying but ideally it should only be something needed for apps that don’t fit the media consumption model. The real problem is that the desktop security model is outdated - it was designed for a world where software developers are trusted by default and users need to protect their data from each other. Today we can’t trust that developers will respect my data. I mean, the fact that any application I run or any npm module I transitively install could upload or delete any of my personal documents is insane. We absolutely need to preserve my ability to run software I write, and run screencast software, file servers, etc. But permission to read my data should not be given by default to any software I happen to run. The Epic thing makes me nervous but generally I think Apple’s direction here is the right one.
- lukeschlather 6y ago

stjohnswarts 6y ago

That should probably be an option, but I'll take ownership of my hardware and data not you or Apple. I don't mind having the checks in there as long as I can overrule them. Otherwise you just get the Epic treatment and you don't really own your hardware, you're just loaning it from Apple and you can only do what they let you do. That, to me, is a losing proposition in the long haul.

kumarvvr 6y ago

The average user would be terribly confused by all this and would hardly bother to even analyze requirements that are asked by any app. They will simply allow everything. More importantly, if they see something like a permissions screen, they will have a false sense of security. And severe restrictions on the app, would hamper user experience. Code signing and developer ID are the most practical means to ensure quality software.

angry_octet 6y ago
Users of iOS seem capable of forming nuanced views of the permissions each app should have. I don't see why this shouldn't be done for macos. The problem is 'everything' apps like browsers -- you need to be able to enforce permissions for individual sites. With weak sandboxing we're still left with the problem of LPE -- once you're on the box (with, by default, unlimited network access!) you can gain root quite quickly, because the kernel interface is rather large. So you still need code signing and developer IDs. However dev IDs could be a federated system -- user's shouldn't have to accept Apple as the total and sole authority for accepting or rejecting apps/developers.

deleted 6y ago

[deleted]

necovek 6y ago

You get that with "snaps" on Ubuntu (and I imagine flatpak too).

bagacrap 6y ago

I don't think the permissions model in mobile OSes was good to start although now it's slightly better. The web is where "they" got it right.