3 ms·

> The only real argument to be made here is claiming that 3rd-party apps should be able to ship on the MAS without being sandboxed, but that runs counter to the

by milen 12y ago

> The only real argument to be made here is claiming that 3rd-party apps should be able to ship on the MAS without being sandboxed, but that runs counter to the entire purpose of the MAS and will never happen. The argument that I've been making for years is that proper entitlements should have existed for all the functionality necessary before the requirement for all apps to be sandboxed was introduced. > The only really useful thing to actually try and get Apple to change is to expand the sandboxing capabilities to allow certain things that 3rd-party apps want to do and cannot do today. They've added more and more capabilities over time. The question is what functionality can be effectively exposed to sandboxed apps without opening up a security hole. Exactly, that's what should have been happening and has been to some extent but not aggressively enough. Part of the problem is that a lot of things pose no security threats but there are still no way to access that functionality in a sandboxed app - that's the crux of the problem. In the case of GaragePay, it used an external utility to deal with encrypted disk images. The app has already been given access to the file via the powerbox [1], there is no additional security threat. Unfortunately, there are no APIs to operate on such disk images except the external hdiutil utility. The correct way to have resolved this was to expose APIs to access that functionality or else allow a temporary exception until such APIs exist. > That functionality should never have been in the MAS app to begin with. Why shouldn't it be? In almost all cases, the functionality can be sandboxed if Apple provided an API to access it securely but there just isn't a entitlement for those cases - not because it's not possible but because it's just not implemented. > Also note that the claim "Apple shouldn't apply that rule, because it removes app functionality, and that's bad for users" is quite ridiculous. I never claimed that. I only claimed that removing functionality objectively leads to an inferior experience due to the lack of said features. In an ideal world, the correct way to have gone about it would be to provide the necessary security mechanisms to make that possible. While Apple did add additional entitlements over the years, there are still many operations that reasonable and do not pose a security threat that are still not supported. > If your app requires violating app store rules for certain functionality, then you shouldn't be using the MAS as your distribution channel. While that's true a statement, that's not the crux of the problem. The root issue is that if the required entitlements were available, then the app wouldn't be violating any rules at all and we wouldn't even be having this conversation. [1] http://en.wikipedia.org/wiki/File_dialog#Powerbox http://en.wikipedia.org/wiki/File_dialog#Powerbox

eridius 12y ago
> The argument that I've been making for years is that proper entitlements should have existed for all the functionality necessary before the requirement for all apps to be sandboxed was introduced In that case, sandboxing could never be introduced. It is quite literally impossible to provide entitlements for any and all functionality under the sun, unless you include the entitlement "allow anything" in the mix. Sandboxing is by its very nature restrictive, requiring bits of functionality to be whitelisted. That's the only way in which it can possibly ever be even remotely secure. However, Mac apps are not required to be sandboxed. Only apps distributed on the MAS are. If you cannot ship your app with the sandbox, then you can continue to be distributed the way all apps were for the past few decades. > Part of the problem is that a lot of things pose no security threats but there are still no way to access that functionality in a sandboxed app - that's the crux of the problem. Can you give examples? I do not blindly accept that GaragePay's use of `hdiutil` is harmless, like you are claiming. `hdiutil` is not sandboxed, and I have no idea what kind of security audit, if any, has been done on it to see if there's any security vulnerabilities that would be exposed by allowing it to be run from a sandboxed application. > The correct way to have resolved this was to expose APIs to access that functionality Yes, APIs that allow for manipulation of disk images would be nice. But that's not even remotely a trivial task. > In almost all cases, the functionality can be sandboxed if Apple provided an API to access it securely That's practically tautological. "The functionality can be sandboxed if Apple allowed it to be sandboxed". Some missing entitlements would be trivial to add. Others would require massive work. I suspect that exposing proper APIs to manipulate the Disk Images infrastructure would require a massive security audit, and probably significant work modifying the APIs as well as I expect they probably don't meet the usability standard expected of public API. > removing functionality objectively leads to an inferior experience due to the lack of said features And implied that this means Apple should allow third-party apps to continue violating rules because the existing experience of using that 3rd-party application somehow trumps everything else. Beyond that, I don't necessarily agree that this does objectively lead to an inferior experience as well. Removing insecure functionality, or functionality that relies on non-public APIs, can lead to a superior experience, because the application is now more trustworthy, much less vulnerable to exploitation, and perhaps more stable or future-proof (in the case of non-public API). So it really can be quite subjective, and quite dependent upon the particular merits of the functionality in question. > The root issue is that if the required entitlements were available, then the app wouldn't be violating any rules at all and we wouldn't even be having this conversation. Again, tautological. "If the app wasn't violating any rules, it wouldn't be violating any rules".

by milen 12y ago

eridius 12y ago

> The argument that I've been making for years is that proper entitlements should have existed for all the functionality necessary before the requirement for all apps to be sandboxed was introduced In that case, sandboxing could never be introduced. It is quite literally impossible to provide entitlements for any and all functionality under the sun, unless you include the entitlement "allow anything" in the mix. Sandboxing is by its very nature restrictive, requiring bits of functionality to be whitelisted. That's the only way in which it can possibly ever be even remotely secure. However, Mac apps are not required to be sandboxed. Only apps distributed on the MAS are. If you cannot ship your app with the sandbox, then you can continue to be distributed the way all apps were for the past few decades. > Part of the problem is that a lot of things pose no security threats but there are still no way to access that functionality in a sandboxed app - that's the crux of the problem. Can you give examples? I do not blindly accept that GaragePay's use of `hdiutil` is harmless, like you are claiming. `hdiutil` is not sandboxed, and I have no idea what kind of security audit, if any, has been done on it to see if there's any security vulnerabilities that would be exposed by allowing it to be run from a sandboxed application. > The correct way to have resolved this was to expose APIs to access that functionality Yes, APIs that allow for manipulation of disk images would be nice. But that's not even remotely a trivial task. > In almost all cases, the functionality can be sandboxed if Apple provided an API to access it securely That's practically tautological. "The functionality can be sandboxed if Apple allowed it to be sandboxed". Some missing entitlements would be trivial to add. Others would require massive work. I suspect that exposing proper APIs to manipulate the Disk Images infrastructure would require a massive security audit, and probably significant work modifying the APIs as well as I expect they probably don't meet the usability standard expected of public API. > removing functionality objectively leads to an inferior experience due to the lack of said features And implied that this means Apple should allow third-party apps to continue violating rules because the existing experience of using that 3rd-party application somehow trumps everything else. Beyond that, I don't necessarily agree that this does objectively lead to an inferior experience as well. Removing insecure functionality, or functionality that relies on non-public APIs, can lead to a superior experience, because the application is now more trustworthy, much less vulnerable to exploitation, and perhaps more stable or future-proof (in the case of non-public API). So it really can be quite subjective, and quite dependent upon the particular merits of the functionality in question. > The root issue is that if the required entitlements were available, then the app wouldn't be violating any rules at all and we wouldn't even be having this conversation. Again, tautological. "If the app wasn't violating any rules, it wouldn't be violating any rules".