Hacker News Reader

Comment by chias | Hacker News Reader

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.

View on HN

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

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

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.

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

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.

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.

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

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

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.

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.

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.

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

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.

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.

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

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.

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.

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

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.

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)

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 ¯\_(ツ)_/¯)

Why not list the entitlements, outright? They might not mean anything to most, but the one's that do understand can raise the alarm.

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.

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

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?

Reply on news.ycombinator.com