3 ms·

> It’s not questionable at all, the App Store has been a cornerstone of the iOS security model for years. It's pretty questionable. The most obvious reason iOS

> It’s not questionable at all, the App Store has been a cornerstone of the iOS security model for years. It's pretty questionable. The most obvious reason iOS has better security than Android is because iOS has far better sandboxing than Android. I don't necessarily dismiss claims that moderation reduces malware, but I am at least skeptical of those claims. I haven't seen compelling statistics that moderation on the scale of the iOS App Store has specifically made an impact beyond banning a few high-publicity, wildly bad actors. The evidence I have seen suggests that moderation is likely not a scalable solution to malware. More to the point, what we do know pretty conclusively is that app stores on their own are not a magic bullet. We can look at Windows, Chrome, and Android and see that app stores don't automatically improve security. I think you can make a strong case that iOS shows why having a locked down OS in general helps -- the restrictions around the filesystem in particular close off entire classes of malware. But I think it's mostly conjecture to try and separate the App Store from those other improvements and credit it in specific.

als0 7y ago
> More to the point, what we do know pretty conclusively is that app stores on their own are not a magic bullet. We can look at Windows, Chrome, and Android and see that app stores don't automatically improve security. I've yet to see evidence that those stores actively review apps in the way that Apple does. You never see articles like "my app was rejected from the Chrome store". It's less about having a store and more about having a decent review process. In any case, there are no silver bullets in security. Not one.
derefr 7y ago
You see sand boxing and app stores as two different things, but they’re not—the iOS security model relies on this sequence of steps: 1. The application developer creates a manifest that lists the privileges the app wants, and includes it as part of the code-signing request; 2. Apple’s App Store review team audits the application more thoroughly according to the privileges it has claimed; 3. Apple only code-signs the app bundle if the app stays on the strait-and-narrow; 4. The OS (through Gatekeeper) enforces the content of a code-signed app bundle, and therefore makes any included capability manifest immutable (in the sense that, if you change it, Gatekeeper considers the app considered and won’t start it); 5. The OS (through the capabilities system) enforces the restrictions from any included capabilities manifest on any high-level framework calls. Note that there’s no actual linkage going on between code-signing and the capabilities manifest, in a way you’d expect from e.g. a Docker image. There’s no real “application sandbox” here. There’s just an Apple signature on the app bundle, telling you Apple saw this app as-is and approved it; and then, separately, an entirely optional opt-in capabilities system for which an app can claim any capabilities it wants. If you take Apple out of the picture as a central signer, then 1. apps could claim any capabilities they liked, and nobody could tell them different (this is more like Android, where installing something presents you with a list of the capabilities it claims); but more importantly, 2. apps wouldn’t even need to use the capability system at all. Like I said, it’s opt-in; regular binaries run on macOS (and iOS!) just fine without living in an app-bundle with a paired capabilities manifest. So, the whole security model of iOS (and macOS under Gatekeeper strict mode) comes down to “Apple verifies that apps are doing the right thing at some point.” Without that, there’s pretty much no sandboxing on either OS beyond what little you get from BSD user privileges and Mach port ACLs.
- danShumway 7y ago
  You are missing the forest for the trees. When people talk about app store moderation, they're talking about a moderation team deciding which apps are abusive and which ones aren't. They're not talking about the underlying mechanism of, "there's a system that verifies an app doesn't violate its manifest." The relevant part of the app store that people in this thread are talking about are the decisions about, "should a specific app that asks for location permissions be allowed on the store?" Code signing doesn't have anything to do with that decision. It's an implementation detail. The important part is not "Facebook is signed to a specific manifest", it's "Facebook's app will be rejected if it's submitted with a manifest that asks for privileges that aren't consumer-friendly." The decision about which apps are allowed on the store is the part of the App Store that's relevant. When people question whether or not app stores improve security, what they're asking is, "does a centralized malware filter improve security?" You could have a Gatekeeper model that worked the exact same way as Android, where the Manifest was required and the user confirmed the Manifest. Even in that world, Apple's sandboxing would still be better than Android's, because the capabilities Apple offers in the manifest are more intelligently split up, and can be granted in more limited degrees. The question is whether Apple's security stats are due to moderation, or largely due to having a better set of permissions. I strongly maintain that there is not enough clear data for anyone to claim that the moderation is objectively the main contributor to those stats. And that's really the only claim that djsumdog was ever making -- that it's questionable whether every company adding an app store to every platform is actually going to make most people safer.
  - derefr 7y ago
    IMHO if you had “a Gatekeeper model that worked the exact same way as Android”, then the granularity of the permissions in iOS wouldn’t help you, because developers (and especially malicious developers) would have no incentive to use the fine-grained capabilities. The only reason anyone bothers with the finickyness of capabilities manifests in the first place, is that Apple forces developers to take exactly the capabilities they need, and rejects apps that ask for more than they need, or ask for capabilities that are too coarse-grained for what they need. Without Apple there to do that human-intelligence-complete task of determining whether an app “needs” the permissions it’s asking for, devs would have a much simpler incentive: to avoid work (and “you must re-approve this app” prompts) by just using as far-reaching of capabilities claims as they can. Just as Android-ecosystem apps do today! And so you’d have iOS malware that simply asks for permission to rootkit you and then rootkits you (just like on Android), and it wouldn’t look out of place, since everything would ask for those same permissions. (Yes, system-equivalent capabilities like that exist in iOS. Apple doesn’t issue them to third parties, but they exist for the sake of system apps. Without a curator, nothing would stop any random app from putting those root-kit-y capabilities in its list, and then socially engineering people into thinking they were sensible things for said app to need.) tl;dr: The security of an ecosystem doesn’t just come from its mechanics, but also its economics. If nobody has any reason to “only claim what they need”, then why would they? Right now, Apple (and their rejection of apps that are too coarse-grained in their capabilities requests) is that reason.

als0 7y ago

> More to the point, what we do know pretty conclusively is that app stores on their own are not a magic bullet. We can look at Windows, Chrome, and Android and see that app stores don't automatically improve security. I've yet to see evidence that those stores actively review apps in the way that Apple does. You never see articles like "my app was rejected from the Chrome store". It's less about having a store and more about having a decent review process. In any case, there are no silver bullets in security. Not one.

derefr 7y ago

You see sand boxing and app stores as two different things, but they’re not—the iOS security model relies on this sequence of steps: 1. The application developer creates a manifest that lists the privileges the app wants, and includes it as part of the code-signing request; 2. Apple’s App Store review team audits the application more thoroughly according to the privileges it has claimed; 3. Apple only code-signs the app bundle if the app stays on the strait-and-narrow; 4. The OS (through Gatekeeper) enforces the content of a code-signed app bundle, and therefore makes any included capability manifest immutable (in the sense that, if you change it, Gatekeeper considers the app considered and won’t start it); 5. The OS (through the capabilities system) enforces the restrictions from any included capabilities manifest on any high-level framework calls. Note that there’s no actual linkage going on between code-signing and the capabilities manifest, in a way you’d expect from e.g. a Docker image. There’s no real “application sandbox” here. There’s just an Apple signature on the app bundle, telling you Apple saw this app as-is and approved it; and then, separately, an entirely optional opt-in capabilities system for which an app can claim any capabilities it wants. If you take Apple out of the picture as a central signer, then 1. apps could claim any capabilities they liked, and nobody could tell them different (this is more like Android, where installing something presents you with a list of the capabilities it claims); but more importantly, 2. apps wouldn’t even need to use the capability system at all. Like I said, it’s opt-in; regular binaries run on macOS (and iOS!) just fine without living in an app-bundle with a paired capabilities manifest. So, the whole security model of iOS (and macOS under Gatekeeper strict mode) comes down to “Apple verifies that apps are doing the right thing at some point.” Without that, there’s pretty much no sandboxing on either OS beyond what little you get from BSD user privileges and Mach port ACLs.

danShumway 7y ago
You are missing the forest for the trees. When people talk about app store moderation, they're talking about a moderation team deciding which apps are abusive and which ones aren't. They're not talking about the underlying mechanism of, "there's a system that verifies an app doesn't violate its manifest." The relevant part of the app store that people in this thread are talking about are the decisions about, "should a specific app that asks for location permissions be allowed on the store?" Code signing doesn't have anything to do with that decision. It's an implementation detail. The important part is not "Facebook is signed to a specific manifest", it's "Facebook's app will be rejected if it's submitted with a manifest that asks for privileges that aren't consumer-friendly." The decision about which apps are allowed on the store is the part of the App Store that's relevant. When people question whether or not app stores improve security, what they're asking is, "does a centralized malware filter improve security?" You could have a Gatekeeper model that worked the exact same way as Android, where the Manifest was required and the user confirmed the Manifest. Even in that world, Apple's sandboxing would still be better than Android's, because the capabilities Apple offers in the manifest are more intelligently split up, and can be granted in more limited degrees. The question is whether Apple's security stats are due to moderation, or largely due to having a better set of permissions. I strongly maintain that there is not enough clear data for anyone to claim that the moderation is objectively the main contributor to those stats. And that's really the only claim that djsumdog was ever making -- that it's questionable whether every company adding an app store to every platform is actually going to make most people safer.
- derefr 7y ago
  IMHO if you had “a Gatekeeper model that worked the exact same way as Android”, then the granularity of the permissions in iOS wouldn’t help you, because developers (and especially malicious developers) would have no incentive to use the fine-grained capabilities. The only reason anyone bothers with the finickyness of capabilities manifests in the first place, is that Apple forces developers to take exactly the capabilities they need, and rejects apps that ask for more than they need, or ask for capabilities that are too coarse-grained for what they need. Without Apple there to do that human-intelligence-complete task of determining whether an app “needs” the permissions it’s asking for, devs would have a much simpler incentive: to avoid work (and “you must re-approve this app” prompts) by just using as far-reaching of capabilities claims as they can. Just as Android-ecosystem apps do today! And so you’d have iOS malware that simply asks for permission to rootkit you and then rootkits you (just like on Android), and it wouldn’t look out of place, since everything would ask for those same permissions. (Yes, system-equivalent capabilities like that exist in iOS. Apple doesn’t issue them to third parties, but they exist for the sake of system apps. Without a curator, nothing would stop any random app from putting those root-kit-y capabilities in its list, and then socially engineering people into thinking they were sensible things for said app to need.) tl;dr: The security of an ecosystem doesn’t just come from its mechanics, but also its economics. If nobody has any reason to “only claim what they need”, then why would they? Right now, Apple (and their rejection of apps that are too coarse-grained in their capabilities requests) is that reason.