Mac sandbox escape(lapcatsoftware.com)
lapcatsoftware.com
Mac sandbox escape
https://lapcatsoftware.com/articles/sandbox-escape.html
10 comments
> I get the apps want to present their own UI for the photos.
If it were up to me and my 100k photo library, none of those apps would pass App Store validation because they are inevitably a miserable experience. Even the OS photo picker isn't 100% jank-free on that number of photos but it at least works effectively unlike everyone who implements their own (takes 30s to appear, photos in random* order, albums in random* order, smart* albums missing, extraneous albums, etc.)
> I hate that apps either get permission to read all photos or none
I thought they had introduced a "get a single photo for this app without photos permission" picker (I'm pretty sure I've used it in apps!) but I can't find any indication I'm not wildly hallucinating. But that would be a great thing.
If it were up to me and my 100k photo library, none of those apps would pass App Store validation because they are inevitably a miserable experience. Even the OS photo picker isn't 100% jank-free on that number of photos but it at least works effectively unlike everyone who implements their own (takes 30s to appear, photos in random* order, albums in random* order, smart* albums missing, extraneous albums, etc.)
> I hate that apps either get permission to read all photos or none
I thought they had introduced a "get a single photo for this app without photos permission" picker (I'm pretty sure I've used it in apps!) but I can't find any indication I'm not wildly hallucinating. But that would be a great thing.
> I thought they had introduced a "get a single photo for this app without photos permission" picker (I'm pretty sure I've used it in apps!) but I can't find any indication I'm not wildly hallucinating.
It exists (https://developer.apple.com/documentation/uikit/uiimagepicke...) but apps don’t want to use it.
It exists (https://developer.apple.com/documentation/uikit/uiimagepicke...) but apps don’t want to use it.
The problem is not the viewing, but editing. When you say "Open In Photoshop" does this mean you can make changes and then save the "file"? What if Photoshop doesn't just "save" a file, but writes several intermediate files onto the filesystem and does a bunch of file renames to create a "backup" of the original image. Those operations are no longer just operating on a single file any more. From the perspective of a security system implementor, how can you understand such intent from sequences of raw POSIX filesystem calls -- because that is all the sandbox enforcement code in the OS kernel gets to see and approve or deny.
For code that uses Apple's Cocoa frameworks, when you ask at a high level to work on a file (or a bundle) a "Powerbox" is used -- it runs out of process and hands back the App permission to make modifications to that file (or bundle) based on the way Cocoa manipulates objects. If the app doesn't use Cocoa, the best that can be done is delegate permission to a directory.
The iPhone allowed a different security model to be created as there was no direct access to "files" and "folders". There were and still are problematic APIs that are based on a give me full access or nothing model. It is quite a challenge to retrofit a security model onto something that ultimately doesn't break something major in an unexpected way.
For code that uses Apple's Cocoa frameworks, when you ask at a high level to work on a file (or a bundle) a "Powerbox" is used -- it runs out of process and hands back the App permission to make modifications to that file (or bundle) based on the way Cocoa manipulates objects. If the app doesn't use Cocoa, the best that can be done is delegate permission to a directory.
The iPhone allowed a different security model to be created as there was no direct access to "files" and "folders". There were and still are problematic APIs that are based on a give me full access or nothing model. It is quite a challenge to retrofit a security model onto something that ultimately doesn't break something major in an unexpected way.
This is why Google is forcing everyone to go through SAF, even though it is available since Android Android 4.4.
After the outcry to remove direct file access on Android 10, they decided to give one more version for devs to adapt to it, but it is coming on Android 11 no matter what.
And the old style access on Android 11 are just wrappers on top of SAF, which makes it even slower than using SAF directly.
On Windows, while UWP sandbox on its own might not have won lots of friends, with MSIX sandbox model for UWP/Win32 and the upcoming picosandboxes in Windows 10X also for UWP/Win32, these direct file APIs might eventually be a thing of the past, even if it still takes a couple of years to get there.
Ah and Linux applications on ChromeOS only sees what the hypervisor/gVisor allow them to see.
After the outcry to remove direct file access on Android 10, they decided to give one more version for devs to adapt to it, but it is coming on Android 11 no matter what.
And the old style access on Android 11 are just wrappers on top of SAF, which makes it even slower than using SAF directly.
On Windows, while UWP sandbox on its own might not have won lots of friends, with MSIX sandbox model for UWP/Win32 and the upcoming picosandboxes in Windows 10X also for UWP/Win32, these direct file APIs might eventually be a thing of the past, even if it still takes a couple of years to get there.
Ah and Linux applications on ChromeOS only sees what the hypervisor/gVisor allow them to see.
Wait, does that mean that programs like FTP server[0] wont work anymore? I use that very often to transfer files from my file manager to and from my phone (e.g. capture a video).
Or there is a way to bypass that and have access to the underlying FS?
(or am i entirely missing what you refer to?)
[0] https://github.com/ppareit/swiftp
Or there is a way to bypass that and have access to the underlying FS?
(or am i entirely missing what you refer to?)
[0] https://github.com/ppareit/swiftp
Yes, they need to adapt if they want to work on Android 11 onwards.
https://developer.android.com/preview/privacy/storage
https://developer.android.com/preview/privacy/storage#all-fi...
https://developer.android.com/preview/privacy/storage
https://developer.android.com/preview/privacy/storage#all-fi...
That doesn't sound like something that would ever work for something like an FTP server. I think i'll stick with my current phone for the foreseeable future, until some workaround is found.
> What if Photoshop doesn't just "save" a file, but writes several intermediate files onto the filesystem and does a bunch of file renames to create a "backup" of the original image.
Powerbox actually has support for this.
Powerbox actually has support for this.
Surely it can store files in a working folder of its own, and keep a reference to the original file. The other files don't need to live side-by-side
There is official support for auxiliary files in macOS/sandbox. A prime example is the use of SQLite in WAL mode which requires write access to $dir/my_db.sqlite + a bunch of other files in the same directory (for transaction handling etc). But this problem was solved years ago already because Core Data (an apple framework) actually uses SQLite under the hood.
Absolutely, but this then means if apps want to adopt some sort of sandboxing, they will quite possibly have to adopt or obey some rules. Sometimes app developers will refuse. Being pragmatic, what can be done then?
Observing the system calls apps make can be eye-opening and sometimes very sad.
Observing the system calls apps make can be eye-opening and sometimes very sad.
I thought that was already how the macOS sandbox worked?
The issue is with apps that aren't sandboxed (basically anything outside the app store - e.g. Adobe apps)
https://developer.apple.com/library/archive/documentation/Se...
> When a user of your app specifies they want to use a file or a folder, the system adds the associated path to your app’s sandbox. Say, for example, a user drags the ~/Documents folder onto your app’s Dock tile (or onto your app’s Finder icon, or into an open window of your app), thereby indicating they want to use that folder. In response, the system makes the ~/Documents folder, its contents, and its subfolders available to your app.
> If a user instead opens a specific file, or saves to a new file, the system makes the specified file, and that file alone, available to your app.
Starting in Catalina, even unsandboxed apps have gotten locked down a bit - you get permissions dialogs if they try to access Documents, Downloads or Desktop.
The exploit in the OP is using an open, world-writable directory (/Users/Shared) since it can't access user files
The issue is with apps that aren't sandboxed (basically anything outside the app store - e.g. Adobe apps)
https://developer.apple.com/library/archive/documentation/Se...
> When a user of your app specifies they want to use a file or a folder, the system adds the associated path to your app’s sandbox. Say, for example, a user drags the ~/Documents folder onto your app’s Dock tile (or onto your app’s Finder icon, or into an open window of your app), thereby indicating they want to use that folder. In response, the system makes the ~/Documents folder, its contents, and its subfolders available to your app.
> If a user instead opens a specific file, or saves to a new file, the system makes the specified file, and that file alone, available to your app.
Starting in Catalina, even unsandboxed apps have gotten locked down a bit - you get permissions dialogs if they try to access Documents, Downloads or Desktop.
The exploit in the OP is using an open, world-writable directory (/Users/Shared) since it can't access user files
Completely agree and you put this perfectly.
It looks like the core problem here is not that the TextEdit entitlement gives arbitrary code execution, but rather that sandboxing is not transitive. If application X has its actions restricted in some way, it should not be able to bypass that by running application Y, for any Y.
Is it just me or is the MacOS security often not fully thought through.
I mean this isn't the first vulnerabilities of it's kind.
I mean this isn't the first vulnerabilities of it's kind.
The key part seems to be this:
> Then click to allow when the system dialog asks if the sample app can control TextEdit via Apple Events.
The author argues,
> This should appear very innocuous to the user, because nobody thinks that TextEdit is dangerous, so one would think it's not much of a risk to allow TextEdit to be controlled.
This is what the dialog looks like: https://imgur.com/a/HRXDG0x
The smaller text is where the app developer provides an explanation for why they are requesting the permission.
> Then click to allow when the system dialog asks if the sample app can control TextEdit via Apple Events.
The author argues,
> This should appear very innocuous to the user, because nobody thinks that TextEdit is dangerous, so one would think it's not much of a risk to allow TextEdit to be controlled.
This is what the dialog looks like: https://imgur.com/a/HRXDG0x
The smaller text is where the app developer provides an explanation for why they are requesting the permission.
And to explain his argument he explained
> However, when an app such as TextEdit with the "com.apple.security.files.user-selected.executable" entitlement saves a file, it removes the quarantine extended attribute!
> However, when an app such as TextEdit with the "com.apple.security.files.user-selected.executable" entitlement saves a file, it removes the quarantine extended attribute!
> Then click to allow when the system dialog asks if the sample app can control TextEdit via Apple Events.
Seems to require the user to explicitly give the application permission to escape the sandbox?
Seems to require the user to explicitly give the application permission to escape the sandbox?
The author is right that controlling TextEdit seems harmless. It could be done in the context of showing the user release notes or something.
AppleEvents must be a nightmare for Apple's security auditors.
You can tell another app to open a document without having permissions to send arbitrary Apple Events (which effectively let you act as a user interacting with the app).
Even if TextEdit files were quarantined so you could not execute them, you would still be able to do harm, such as snooping on the user's recent documents, or trashing the disk by overwriting files that TextEdit has access to. Likely it could even install a LaunchAgent to run arbitrary code outside of the sandbox as well.
There's already a security dialog here that warns the user. Maybe the user's imagination doesn't run wild with all the ways that the access could be abused, but they _were_ warned.
Even if TextEdit files were quarantined so you could not execute them, you would still be able to do harm, such as snooping on the user's recent documents, or trashing the disk by overwriting files that TextEdit has access to. Likely it could even install a LaunchAgent to run arbitrary code outside of the sandbox as well.
There's already a security dialog here that warns the user. Maybe the user's imagination doesn't run wild with all the ways that the access could be abused, but they _were_ warned.
I work on the platform all day, and I would not put that together as obviously dangerous.
The latest version of Zoom (released yesterday) also has the entitlement to send Events to other applications. It's unclear why it requires this entitlement. Anyone know?
[>] codesign -d --entitlements :- /Applications/zoom.us.app
...
<key>com.apple.security.automation.apple-events</key>
<true/>I believe there’s a feature that allows others to take control of the screen. It could be related to this
I had the same thought, but that feature is https://support.zoom.us/hc/en-us/articles/201362673-Request-... and needs permissions under Accessibility.
Maybe they also intend to allow controlling single applications at some point.
I would imagine it’s used for scheduling meetings in other apps.
Which is horrific. It should export an event/intent for the user to to route.
iirc remote mouse & keyboard control was added recently.
I just don't known what to make of OP last sentence :
> Note that I chose the directory /Users/Shared to avoid macOS "privacy protections" that prevent interaction with various other directories such as Desktop, Documents, and Downloads.
If the script can't access protected locations did it actually break the sandbox? Can you actually run the file in /Users/Shared scripts afterward and access those locations from there on? On Catalina the shell is kinda sandboxed when run interactively, does this exploit bypass by tuning as TextEdit?
> Note that I chose the directory /Users/Shared to avoid macOS "privacy protections" that prevent interaction with various other directories such as Desktop, Documents, and Downloads.
If the script can't access protected locations did it actually break the sandbox? Can you actually run the file in /Users/Shared scripts afterward and access those locations from there on? On Catalina the shell is kinda sandboxed when run interactively, does this exploit bypass by tuning as TextEdit?
There is a bit of confusion because macOS has two sandboxes: app store app isolation and permissions and file system isolation. Think of the latter as everything on the file system except /Users and a few other cherry picked directories being mounted from a read-only CD-ROM.
The latter usually goes by the name "Data Vaults" and actually extends to a blacklist of directories (and at a technical level is enforced in a different manner). Things like ~/Documents, ~/Downloads and ~/Desktop are inaccessible to applications without permission.
Putting on the other hat for a minute, I'm curious what the author things a good resolution for this would be.
Perhaps that any time you use a text editor to create, edit, or save a shell script, that script should be treated as a freshly downloaded and untrusted script? Or that it should be impossible to control a text editor from another application, even when given explicit permission from the operator? Both of those sound awful. Is there a third option I'm missing here?
I'm with Apple on this one.
-----
Also, who would think controlling a text editor is innocuous? A text editor's modus operandi is literally to create, read, update, or delete any file to which your user has access.
Perhaps that any time you use a text editor to create, edit, or save a shell script, that script should be treated as a freshly downloaded and untrusted script? Or that it should be impossible to control a text editor from another application, even when given explicit permission from the operator? Both of those sound awful. Is there a third option I'm missing here?
I'm with Apple on this one.
-----
Also, who would think controlling a text editor is innocuous? A text editor's modus operandi is literally to create, read, update, or delete any file to which your user has access.
Tricking a higher-privileged bit of code into doing the bidding of a lower-privileged app is really common in the history of nasty security exploits. Windows Kernel developers and Web Browser developers have both spent over a decade systematically eliminating scenarios where this can happen, whether it's forging WM_TIMER messages or attempting to get around javascript API origin/trust restrictions.
"I convinced this other program to dump an executable shell script onto disk for me so I could run it without a prompt" is a textbook escalation of privilege vulnerability, and being able to do it with a common app like TextEdit or BBEdit is pretty serious.
One solution is for the outermost caller's credentials to apply all the way down the chain. This is common in Windows and in web browsers - web browsers basically track whether the current chain of actions originated from user input or not so that they can prevent websites from silently doing nasty stuff without user consent. At this point browsers actually track that consent data across asynchronous computation so everything will work.
I personally don't think an app with 'create shell script' permissions should be able to be controlled by Joe's Random Unprivileged App, but that's just me. Windows certainly doesn't allow low integrity apps to communicate with arbitrary high integrity apps. Introducing that restriction is an essential security improvement.
"I convinced this other program to dump an executable shell script onto disk for me so I could run it without a prompt" is a textbook escalation of privilege vulnerability, and being able to do it with a common app like TextEdit or BBEdit is pretty serious.
One solution is for the outermost caller's credentials to apply all the way down the chain. This is common in Windows and in web browsers - web browsers basically track whether the current chain of actions originated from user input or not so that they can prevent websites from silently doing nasty stuff without user consent. At this point browsers actually track that consent data across asynchronous computation so everything will work.
I personally don't think an app with 'create shell script' permissions should be able to be controlled by Joe's Random Unprivileged App, but that's just me. Windows certainly doesn't allow low integrity apps to communicate with arbitrary high integrity apps. Introducing that restriction is an essential security improvement.
This class of problem is interesting and well-known because it doesn't have a great resolution within the most popular access control schemes.
https://en.wikipedia.org/wiki/Confused_deputy_problem
https://en.wikipedia.org/wiki/Confused_deputy_problem
Maybe explaining to the user the implications of controlling TextEdit? How scope is expanding? Just thinking out loud here.
I mean, it does alert you of the consequences when you grant it Apple Events access.
Sure. I was thinking more along the lines of a mobile OS, where you're given some insight as to what the app is actually asking for. Which I think overall is a good thing...although the granularity or function of the permissions you can request here might not be as easy to understand.
(Not sure why I'm being downvoted above)
(Not sure why I'm being downvoted above)
It does give you a similar alert as it would on iOS; the issue with Apple Events is that it generally gives you the same permissions as the process that you're controlling so it's fairly hard to describe it in general. This isn't an issue on iOS because such a permission doesn't really exist.
(I can't explain the downvotes, either. Hacker News is fickle ¯\_(ツ)_/¯)
(I can't explain the downvotes, either. Hacker News is fickle ¯\_(ツ)_/¯)
Why not list the entitlements, outright? They might not mean anything to most, but the one's that do understand can raise the alarm.
My takeaway is more that the entire security model that Apple is pushing for the Mac just doesn't really make sense. E.g., here's a quick list of apps that aren't sandboxed: Logic Pro, Final Cut, most of Adobe Creative Cloud, Visual Studio Code/Atom/TextMate, Xcode, and Sketch. If I were to make a list of the main apps people buy Macs to run, it's pretty much the same list.
The particular case highlighted in the blog post is specific to code editors, but similar types of problems arise in all of the most important app categories for Macs.
The particular case highlighted in the blog post is specific to code editors, but similar types of problems arise in all of the most important app categories for Macs.
This issue goes beyond MacOS too. The traditional model of allowing any process to read and write anything created by the same user, send IPC messages (unix sockets, mach ports, window messages etc.) to most processes, and execute any subprocess has serious security and privacy implications. iOS, Android, and to a lesser extent ChromeOS offer a different, more intuitive, security model, but one which is difficult to retrofit to traditional OSs.
Attempts to retrofit a sandbox to older OSs are full of holes, and it's interesting to see how different ecosystems attempt to do this, with containers, AppArmor, the seatbelt sandbox, and other things brewing in Redmond.
Attempts to retrofit a sandbox to older OSs are full of holes, and it's interesting to see how different ecosystems attempt to do this, with containers, AppArmor, the seatbelt sandbox, and other things brewing in Redmond.
Snap / Flatpack are probably the most promising attempts in this area.
Personally I think it will be incredibly hard and tedious to morph the Linux desktop into a properly sandboxed environment, exactly because you are fighting long established conventions and norms in just about every aspect of development and application usage.
Fuchsia (Googles new OS) might prove very interesting in this regard.
Personally I think it will be incredibly hard and tedious to morph the Linux desktop into a properly sandboxed environment, exactly because you are fighting long established conventions and norms in just about every aspect of development and application usage.
Fuchsia (Googles new OS) might prove very interesting in this regard.
I find most of the time when I’m installing snaps I need to use —dangerous. I’m not sure what exactly it does, but my guess is that it renders whatever security snaps are supposed to provide moot.
You could look at something like Qubes OS which tries to sandbox things as much as possible via virtualization. It’s pretty cumbersome to use however.
https://en.m.wikipedia.org/wiki/Qubes_OS
https://en.m.wikipedia.org/wiki/Qubes_OS
Not cumbersome at all if you adhere to the core principles and think through how you actually use your computer.
Contrary to popular belief, you do not have to run every application in its own (VM).
You can run any number of apps in a single VM, so the principle is that you define what applications (use cases) can and should be isolated from each other and use multiple VMs to implement that segmentation between (groups of) apps.
For example, you can have one VM for all your work apps and another for the remaining use cases.
Contrary to popular belief, you do not have to run every application in its own (VM).
You can run any number of apps in a single VM, so the principle is that you define what applications (use cases) can and should be isolated from each other and use multiple VMs to implement that segmentation between (groups of) apps.
For example, you can have one VM for all your work apps and another for the remaining use cases.
Regarding the things brewing in Redmond I am looking forward to how Windows 10X will turn out to be.
What’s brewing in Redmond, and how is Microsoft going to get old legacy apps to play along with it?
Windows 10X has sandboxes for everything, there are no exceptions.
This is a path that started when people voted against UWP, then they went the other way around, bringing the UWP sandbox model to Win32.
First there was Desktop Bridge where Win32 apps would run sandboxed, but with full trust. Then came the MSIX package format that would apply a bit more of sandboxing and less trust than Desktop Bridge introduced.
Now with Windows 10X they are building on top of the picoprocesses that came from Project Drawbridge and were used in WSL 1 to wrap each Win32 application into its own little world.
It is only a matter of time until this expands to other SKUs.
As for the legacy applications, I guess just like with those stuck in Windows XP, either adopt the future or stay behind.
This is a path that started when people voted against UWP, then they went the other way around, bringing the UWP sandbox model to Win32.
First there was Desktop Bridge where Win32 apps would run sandboxed, but with full trust. Then came the MSIX package format that would apply a bit more of sandboxing and less trust than Desktop Bridge introduced.
Now with Windows 10X they are building on top of the picoprocesses that came from Project Drawbridge and were used in WSL 1 to wrap each Win32 application into its own little world.
It is only a matter of time until this expands to other SKUs.
As for the legacy applications, I guess just like with those stuck in Windows XP, either adopt the future or stay behind.
> As for the legacy applications, I guess just like with those stuck in Windows XP, either adopt the future or stay behind.
I have a very strong feeling that it will be Windows 10X that will be "left behind". The entire point of using Windows nowadays is to be able to use existing Windows applications.
I have a very strong feeling that it will be Windows 10X that will be "left behind". The entire point of using Windows nowadays is to be able to use existing Windows applications.
I don't think so, given I have been following the evolution of Windows sandbox model for a decade now.
Every time there were any issues, it was dealt with one step back two forward tactic.
Every time there were any issues, it was dealt with one step back two forward tactic.
That tactic only works for as long as nothing breaks. So far the stuff Windows introduced for better security (ie. UAC) very rarely break things both by trying to emulate the older behavior (ie. UAC tries to virtualize writes to Program Files older programs do) and by allowing you to bypass it and just let the program do what it wants (run as Admin, compatibility flags in registry/settings in shortcut, etc). Even when that isn't possible there are often workarounds to make things work.
In general i'm very confident i can make any older program or game for Windows to run on modern Windows 10 - usually with minor tweaks.
If Microsoft breaks this, i'm certain they'll completely misunderstand why people keep using Windows.
In general i'm very confident i can make any older program or game for Windows to run on modern Windows 10 - usually with minor tweaks.
If Microsoft breaks this, i'm certain they'll completely misunderstand why people keep using Windows.
> If I were to make a list of the main apps people buy Macs to run, it's pretty much the same list.
That is exactly the point. The apps you listed are used in tons of corporate environments and fairly well vetted, usually with bug bounty programs or full time security teams backing them. It's the smaller one-off apps that people aren't putting eyes on regularly that get sandboxed.
That is exactly the point. The apps you listed are used in tons of corporate environments and fairly well vetted, usually with bug bounty programs or full time security teams backing them. It's the smaller one-off apps that people aren't putting eyes on regularly that get sandboxed.
To me, that's the absolute worst possible outcome: All of the important software use cases become owned by the existing players forever, because no other competitor can gain traction without Apple's marketing help by being in the App Store, but then they can't become powerful enough to truly compete with the big players by being outside the sandbox.
That's exactly what happened with Pixelmator, and it's happening now with the Affinity Suite. Before the sandbox, Pixelmator looked like it would one day be a real Photoshop competitor, but now they're mainly for people who don't want to pay for Adobe's subscription.
And, the real Adobe competitors are more likely to come from somewhere else, like the web with Figma. The funny thing is that now Figma is usable on an iPad, because it's a web app, and Sketch, which is an all-Apple technology AppKit app, isn't. Because web apps can avoid the sandbox, even on iOS. Some of the biggest beneficiaries of Apple's security strategy are poised to be some of the apps least invested in Apple's platforms.
That's exactly what happened with Pixelmator, and it's happening now with the Affinity Suite. Before the sandbox, Pixelmator looked like it would one day be a real Photoshop competitor, but now they're mainly for people who don't want to pay for Adobe's subscription.
And, the real Adobe competitors are more likely to come from somewhere else, like the web with Figma. The funny thing is that now Figma is usable on an iPad, because it's a web app, and Sketch, which is an all-Apple technology AppKit app, isn't. Because web apps can avoid the sandbox, even on iOS. Some of the biggest beneficiaries of Apple's security strategy are poised to be some of the apps least invested in Apple's platforms.
> Before the sandbox, Pixelmator looked like it would one day be a real Photoshop competitor, but now they're mainly for people who don't want to pay for Adobe's subscription.
Can you point to any evidence that the macOS sandbox is what’s holding Pixelmator back from dethroning the undisputed 20+ year king of professional photo editing?
Can you point to any evidence that the macOS sandbox is what’s holding Pixelmator back from dethroning the undisputed 20+ year king of professional photo editing?
I wrote an analysis of the most popular creative apps across various industries[0], none of them are sandboxed, and all of them support plugins of some kind, which is the main type of functionality that sandboxing makes difficult.
Also, Photoshop was once also the undisputed king of user-interface design, but they were dethroned by Sketch, an app that was first released one year before sandboxing came into effect.
Is any of this conclusive? No. But do I see a pattern sandboxing putting a ceiling on how successful a creative app can be? Overwhelmingly yes.
[0]: https://blog.robenkleene.com/2019/08/07/apples-app-stores-ha...
Also, Photoshop was once also the undisputed king of user-interface design, but they were dethroned by Sketch, an app that was first released one year before sandboxing came into effect.
Is any of this conclusive? No. But do I see a pattern sandboxing putting a ceiling on how successful a creative app can be? Overwhelmingly yes.
[0]: https://blog.robenkleene.com/2019/08/07/apples-app-stores-ha...
The way things are going across all consumer OSes, running without a sandbox will eventually something only available in FOSS OS clones.
And I seriously doubt that applications like Photoshop will migrate to them just because of that.
And I seriously doubt that applications like Photoshop will migrate to them just because of that.
If that happens then interesting new applications and ideas will start appearing on these FOSS OSes since those will be the OSes where such things will be possible. People do not use computers for their OSes, they use computers for the applications they can run on them and if all the new interesting stuff comes out in the free FOSS OSes then people will start migrating to using those OSes.
Nowadays this doesn't happen much because there is no incentive.
Nowadays this doesn't happen much because there is no incentive.
I remember that speech when DX 10 was not available on XP, I also used to believe in Desktop Linux dream, nowadays I just use Apple, Google, MS desktop and mobile platforms.
Both of what you write have nothing to do with what i wrote. DirectX 10 might not have been available on XP, but DirectX 9 was, as was OpenGL that exposed the DX10 level functionality through extensions. If anything, DX10 pretty much failed to gain traction exactly because it was not available on the OS gamers wanted to use at the time. Very very few engines used DX10 and pretty much every engine skipped form DX9 to DX11.
Also as i already wrote above, currently there isn't really much of an incentive for people to switch (outside of ideological and/or very niche reasons) so the "Desktop Linux dream" doesn't apply.
Also as i already wrote above, currently there isn't really much of an incentive for people to switch (outside of ideological and/or very niche reasons) so the "Desktop Linux dream" doesn't apply.
> Pixelmator looked like it would one day be a real Photoshop competitor
I am, at best, a journeyman in the ways of graphic editing and someone who bought Pixelmator the instant it arrived but this isn't right - it might have become a real Photoshop competitor for people who needed basic graphic editing facilities once or twice a month, yes. Same with Affinity Photo. Without a laser focus on quality-of-life tweaks and jank removal (haven't seen it in either yet!), they're both doomed to GIMP-level "coulda beena contender!" existence.
I am, at best, a journeyman in the ways of graphic editing and someone who bought Pixelmator the instant it arrived but this isn't right - it might have become a real Photoshop competitor for people who needed basic graphic editing facilities once or twice a month, yes. Same with Affinity Photo. Without a laser focus on quality-of-life tweaks and jank removal (haven't seen it in either yet!), they're both doomed to GIMP-level "coulda beena contender!" existence.
Yeah. That's kind of the point. Don't expect to buy or write alternatives for the established, trusted apps. Just consume product and get excited for next product.
Judging by the entitlements, it seems that a script can save an executable file. Would it be possible to ensure that any file written by a script remains quarantined?
> I'm curious what the author things a good resolution for this would be.
Files created by an app (app1) that is being controlled by another app (app2) should inherit the security context of app2, not app1 (or better yet, where privileges differ, apply the lesser of the the two). The fix should be applied where the security characteristics of a file are written. Perhaps that would mean introducing a new primitive that tracks when an app is being controlled by another app -- not sure.
Also, perhaps have special exceptions for files written to places like /Library/Application Support/app1/ -- an app's own working files are unlikely to present privilege escalation opportunities unless app2 is able to exploit a vulnerability in app1.
> Also, who would think controlling a text editor is innocuous?
I can think of several family members who might think "um why?" but not have any idea of the security implications.
Files created by an app (app1) that is being controlled by another app (app2) should inherit the security context of app2, not app1 (or better yet, where privileges differ, apply the lesser of the the two). The fix should be applied where the security characteristics of a file are written. Perhaps that would mean introducing a new primitive that tracks when an app is being controlled by another app -- not sure.
Also, perhaps have special exceptions for files written to places like /Library/Application Support/app1/ -- an app's own working files are unlikely to present privilege escalation opportunities unless app2 is able to exploit a vulnerability in app1.
> Also, who would think controlling a text editor is innocuous?
I can think of several family members who might think "um why?" but not have any idea of the security implications.
> I can think of several family members who might think "um why?" but not have any idea of the security implications.
This is definitely the case. When presented with a dialog that prevents progression, many, many users will click whatever makes it "go away."
However, when I see something like this, I get the heebie-jeebies. Apple's done a great job at locking down stuff, and when I have to provide accessibility or some other weirdness I know what I'm doing.
I think if a successful exploit of this started spreading, Apple might add some exception for TextEdit. But in lieu of that, I can only imagine the amount of substantial, unprompted security problems are quite extensive.
This is definitely the case. When presented with a dialog that prevents progression, many, many users will click whatever makes it "go away."
However, when I see something like this, I get the heebie-jeebies. Apple's done a great job at locking down stuff, and when I have to provide accessibility or some other weirdness I know what I'm doing.
I think if a successful exploit of this started spreading, Apple might add some exception for TextEdit. But in lieu of that, I can only imagine the amount of substantial, unprompted security problems are quite extensive.
This is cool because it shows Apple built a castle on a foundation of sand.
The author points to the sand, and Apple says "we're only interested in the castle."
In one sense, to agree with most of the comments here, thats the practical answer for Apple! Show us the problem with what we've built!
In another sense, I scooped the sand away from the foundation of your castle, and now I'm inside.
The author points to the sand, and Apple says "we're only interested in the castle."
In one sense, to agree with most of the comments here, thats the practical answer for Apple! Show us the problem with what we've built!
In another sense, I scooped the sand away from the foundation of your castle, and now I'm inside.
I'm not sure this is necessarily a security issue, it is perhaps more of a social engineering issue. The user IS shown a suspicious dialogue "App wants access to control TextEdit".
What apple could do is perhaps add some sort of indication or extra step to help users make the informed choice.
What apple could do is perhaps add some sort of indication or extra step to help users make the informed choice.
You have the problem that too much information will just get skipped over by the user too. It has to be the right length of text if you want to try and get them to read it.
My text editor for example, I personally wouldn't mind if once per project I had to give it permission to access a project's folder.
I also wish there was a way to edit a file without giving access to the folder. For example Photoshop, I can select from the finder "Open In Photoshop" which is enough intent to give the app permission to access that file without having to give it access to the other files in the same folder.
I get that would require API changes and that Apple doing that overnight would break apps but basically going forward I wish OS makers would work toward something like that.
Even on iPhone I hate that apps either get permission to read all photos or none. Yes I get you can send a photo to an app but many apps can not receive them for every use. I get the apps want to present their own UI for the photos. Maybe some kind of OS run sandboxed process where the app can provide a limited function to present thumbnails but can't actually read any data and all they get out of that process from the OS is the user selected files? Oh well, I can dream.