5 ms·

> 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 al

by 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".

milen 12y ago
> 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. That doesn't follow. Sandboxing privileges present a wide spectrum ranging from providing no entitlements on one end to providing an "allow anything" entitlement on the other. Obviously, as developers, we want as much functionality exposed in a secure way but the unfortunate reality is that Apple either do not have the resources or willingness to do so. > However, Mac apps are not required to be sandboxed. Only apps distributed on the MAS are. While that's technically true, an argument can be made that due to the inclusion of the MAS as part of OS X, it's practically required for an app to be on the MAS as that's where a lot of the users are and it's how they get their software. > Can you give examples? Yes, Coda 2.5 [1] was not released on the MAS due to sandboxing issues. There are some radars on openradar [2] referring to other sandboxing issues, too - some of them are reasonable. Obviously, I do not have access to Radar itself otherwise I would have provided more examples. > But that's not even remotely a trivial task. I don't see that as a valid excuse for not providing an API while at the same time rejecting the usage of a temporary entitlement due to lack of said API. It's a given that providing functionality in a sandbox compatible way would not be trivial - the work needs to be done if we want everything to be nice and secure. I'm perfectly aware that the effort required to implement such an API would be considerable and it might not be worth it but that doesn't make it the right approach. And that's why I accept the current situation - it's a compromise between what could be and what Apple have decided to implement at present. > Others would require massive work. Yes and in an ideal world, if we're fully committed to sandboxing, that work would be done. You said: > Apple developed the OS that you're using, so there's hardly a trust issue when talking about running applications from Apple on top of the Apple-developed OS. Sandboxing is not just about trust, it's also about security. Apple's own software not being sandboxed means its vulnerable to exploits, exactly what sandboxing is trying to prevent. If you check Activity Monitor, you will see plenty of Apple and others' apps being non-sandboxed - all of these are potential targets. A system is only as secure as it's weakest link, so if we want a more secure system, we should working towards having more sandbox entitlements. As a side note, the trust side of things is taken care of by code signing. > 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. No, the implication is that Apple should be working towards exposing more functionality in a secure, sandbox compatible way. [1] http://www.panic.com/blog/coda-2-5-and-the-mac-app-store/ http://www.panic.com/blog/coda-2-5-and-the-mac-app-store/ [2] http://www.openradar.me/search?query=sandbox http://www.openradar.me/search?query=sandbox

by eridius 12y ago

milen 12y ago

> 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. That doesn't follow. Sandboxing privileges present a wide spectrum ranging from providing no entitlements on one end to providing an "allow anything" entitlement on the other. Obviously, as developers, we want as much functionality exposed in a secure way but the unfortunate reality is that Apple either do not have the resources or willingness to do so. > However, Mac apps are not required to be sandboxed. Only apps distributed on the MAS are. While that's technically true, an argument can be made that due to the inclusion of the MAS as part of OS X, it's practically required for an app to be on the MAS as that's where a lot of the users are and it's how they get their software. > Can you give examples? Yes, Coda 2.5 [1] was not released on the MAS due to sandboxing issues. There are some radars on openradar [2] referring to other sandboxing issues, too - some of them are reasonable. Obviously, I do not have access to Radar itself otherwise I would have provided more examples. > But that's not even remotely a trivial task. I don't see that as a valid excuse for not providing an API while at the same time rejecting the usage of a temporary entitlement due to lack of said API. It's a given that providing functionality in a sandbox compatible way would not be trivial - the work needs to be done if we want everything to be nice and secure. I'm perfectly aware that the effort required to implement such an API would be considerable and it might not be worth it but that doesn't make it the right approach. And that's why I accept the current situation - it's a compromise between what could be and what Apple have decided to implement at present. > Others would require massive work. Yes and in an ideal world, if we're fully committed to sandboxing, that work would be done. You said: > Apple developed the OS that you're using, so there's hardly a trust issue when talking about running applications from Apple on top of the Apple-developed OS. Sandboxing is not just about trust, it's also about security. Apple's own software not being sandboxed means its vulnerable to exploits, exactly what sandboxing is trying to prevent. If you check Activity Monitor, you will see plenty of Apple and others' apps being non-sandboxed - all of these are potential targets. A system is only as secure as it's weakest link, so if we want a more secure system, we should working towards having more sandbox entitlements. As a side note, the trust side of things is taken care of by code signing. > 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. No, the implication is that Apple should be working towards exposing more functionality in a secure, sandbox compatible way. [1] http://www.panic.com/blog/coda-2-5-and-the-mac-app-store/ http://www.panic.com/blog/coda-2-5-and-the-mac-app-store/ [2] http://www.openradar.me/search?query=sandbox http://www.openradar.me/search?query=sandbox