
Mac sandbox escape - miles
https://lapcatsoftware.com/articles/sandbox-escape.html
======
greggman3
Just the ability to access the rest of the file system I think I wish was on a
folder by folder basis.

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.

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

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

~~~
sammorrowdrums
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

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

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

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

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

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

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

------
rgovostes
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](https://imgur.com/a/HRXDG0x)

The smaller text is where the app developer provides an explanation for why
they are requesting the permission.

~~~
SalimoS
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!

------
diebeforei485
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/>

~~~
samuelg123
I believe there’s a feature that allows others to take control of the screen.
It could be related to this

~~~
btilly
I had the same thought, but that feature is [https://support.zoom.us/hc/en-
us/articles/201362673-Request-...](https://support.zoom.us/hc/en-
us/articles/201362673-Request-or-Give-Remote-Control) and needs permissions
under Accessibility.

~~~
judge2020
Maybe they also intend to allow controlling single applications at some point.

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

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

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

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

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

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

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

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

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

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

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

