
macOS Sierra and Gatekeeper Path Randomization - milen
http://weblog.rogueamoeba.com/2016/06/29/sierra-and-gatekeeper-path-randomization/
======
makecheck
This sounds strange; in order to refer to files outside your bundle with a
_relative_ path, you would have to be using something like
"../../../SomewhereElse/filename.xyz", which is utterly fragile to begin with.

I can only assume that this was used to find other applications. Still a
fragile dependency; for example, sometimes I put things in
"/Applications/Utilities" but sometimes I put them in "/Applications", which
means there is no single parent directory that is guaranteed to hold
everything. And even if that weren’t the case, the OS has always let you run
applications from anywhere you want.

Therefore, it has always been possible for apps to break when doing this, and
they were just _lucky_ if they ran on a system where it worked. It sounds like
in Sierra it will just be much more likely to break.

~~~
rarepostinlurkr
Thats pretty much exactly what people do. If you are feeling bored, you can
check the post and pre flight installer package scripts of some of your most
used software.

Regex system versions, string compare versions in Ruby (great for "10.9" ->
"10.10"), check that their installer package (an OS X binary) is running on...
OS X. Sometime developers do this out of ignorance, sometimes its done out of
laziness (don't want to do anything platform specific), or business decisions
(don't want to do anything platform specific!) or because there was no better
way to do it (no supported API).

How about applications that have an installer, lay themselves down in
/Applications/ then have a folder inside called "Plugins", from which they
load relative arbitrary code? More common than you might think!

------
eridius
> _The problem with Gatekeeper Path Randomization is that copying applications
> to a read-only disk image will break functionality in many, if not most,
> existing applications._

This is extremely hyperbolic. I'd say it could break functionality in a small
number of apps (that don't support running from read-only media, which is
definitely a problem with the app and not a problem with the system). I doubt
it's a lot, and it's sure as hell not "most".

------
veidr
This just goes to show that Apple _really_ needs to solve their app
installation problem.

I remember a time when "just move the app into the Applications folder" seemed
really simple. Like Apple, I thought it was a fine idea.

We were wrong. Having to move the application in Applications turns out to be
absolutely _baffling_ to most users. (Including many people I am fond of, e.g.
my dad.)

A lot of apps now offer to move themselves when first launched from the
Dowloads or Desktop folder; the OS should handle this.

GPR itself still seems janky, but this would help (since apps in Applications
don't get GPR'd).

~~~
zepto
The Mac App Store should have solved that problem, but they have severely
neglected it, both as a software component and a business service.

------
zZorgz
The main concern is that software updaters will not be able to easily replace
an app bundle if it is translocated to a readonly mount. The user will have to
move the app somewhere else first.

Apple wants developers to use dmgs (and signed ones particularly) but updaters
don't have an easy time with apps being launched from those either, and people
don't think dmgs provide a good user experience as well.

~~~
eridius
Software updaters need to handle the case of the app being on read-only media
_anyway_. If your app breaks because it was launched from read-only media,
that's absolutely a problem with the app and not a problem with the system.

~~~
zZorgz
Perhaps, but it's unlikely that many do. Updating such an app would involve
writing the new update to a different location, which could pose a challenge
for not confusing the user. The Mac App Store doesn't have to deal with this.

Some developers that distribute their app in dmg's try to nudge the user to
move the application for them into /Applications, but that's kind of hostile,
and developers shouldn't have to go out of their way to do that.

Before 10.12 at least, developers were generally okay with the updater not
running on read-only media - this is more intended behavior rather than being
'broken'.

Anyway, just pointing out the real concern from the article.

~~~
eridius
In the case of a software updater, I think "not updating" is probably correct
behavior. Broken behavior would be the app crashing or misbehaving or throwing
errors because it tries to update the app on read-only media.

~~~
zZorgz
Not updating is what most apps currently do in this case.

The author's concern is that they (and many other developers) ship apps in
zips, have many users download them, and run them from ~/Downloads/ or
wherever their browser downloaded the app to. Only in 10.12, this practice
will prevent most 3rd party apps from being able to update themselves.

The author wants an info.plist key (plus perhaps app signing) to opt-out of
translocation and say that they are competent enough. Before thinking that
this "defeats" the point, people may miss that Apple is fine with opting out
provided you code sign and package a dmg.

The author and many others also don't like dmgs, however, and find that they
confuse many users. What the author is concerned about does indeed affect a
lot of apps.

~~~
eridius
I would expect that people who run an app from ~/Downloads are doing so
because they don't know if they want to actually keep it and are just testing
it out. Similarly, many apps already check if they're launched from a DMG or
from ~/Downloads and ask the user if they want to move the app to the
Applications folder, so that's a pretty simple fix for any self-updating app
to adopt.

~~~
zZorgz
I don't want to be asked about moving apps somewhere else especially for
testing them. It is kind of hostile. And it's a burden for the dev to include
yet more code for this. IMO, Apple should have a way to solve the issue for
out-of-store apps.

(I really don't know if that many apps do this btw, I think most apps I
download today are packaged in zip..)

Other users are just baffled and run apps from disk images or Downloads just
because.

The authors point is that at least before 10.12 zip was a decent approach.

Too bad they aren't offering signed zip or something similar that takes same
advantages that a signed dmg does..

~~~
eridius
A signed zip is still dangerous. If the attacker can convince the user to
download two files instead of just one, the attacker controls the names of the
folders that contains the extracted zip contents (i.e. the name of the zip),
so any app that looks at ../foo/bar would still be vulnerable.

The Info.plist approach (where the app declares that it has no such relative
path dependencies and so should skip gatekeeper path randomization) seems like
the best approach for fixing this "issue".

------
chmaynard
After reading this post, I still don't understand what the problem is. Are Mac
developers writing apps that modify files stored inside the app bundle? If so,
isn't this considered a dangerous practice?

~~~
Rumudiez
I think the concern is stated here:

> However, many users run applications from the Downloads folder, never moving
> them.

Basically, unsigned apps __might __not work when run from the Downloads folder
without changing the Gatekeeper setting in Security & Privacy settings.

I don't view this as an issue because I already have to go there to launch an
unsigned app for the first time to hit "Allow."

~~~
pfranz
I'm still amazed Apple hasn't done anything to encourage people to move apps
from Downloads into Applications (or from a disk image); which is a big part
of this problem. I see Applications launched from Downloads or copied to the
Desktop all the time. It's almost always out of ignorance and maybe laziness.

Almost every App has a custom background image on the disk image and shortcut
instructing people to copy the application to Applications. I've also seen
various apps check and pop up a dialog asking if they should move themselves
to Applications for you.

Much like the first-run warning dialog, I'm surprised Apple doesn't have a
similar dialog offering to "Leave App and Launch", "Move App to Applications
and Launch", or "Move App, Create a Shortcut Here, and Launch". With a
preference or flag to suppress the dialog.

~~~
blacksmith_tb
I doubt it's laziness, I would think most users have no idea what the
implications of running from a dmg / the desktop / ~/Applications or
/Applications really are... It doesn't help that there are also .pkg
installers that have a wizard-y interface (and which often are run from a
mounted dmg, e.g. VirtualBox). Apple could impose some order on the mess, but
I tend to find their solutions to problems like these heavy-handed, so though
that would probably benefit most users, it might not be a win for the more
technical ones.

~~~
pfranz
I'm sure it's ignorance for most people, but I know it's laziness with some
people I know.

I think the whole .app folder idea was a great idea that I'm surprised others
(Windows/Linux) haven't copied. The /intention/ is that anything that would
need to get installed/fixed happen when the app is first launched. This both
removes the need for an installer and helps repair things (if the App was
moved or preferences were deleted). Thankfully installers are pretty rare in
my experience. Usually it's for pretty involved things (network monitor, VM
environment) or lazy multi-platform devs (Microsoft Word, or Adobe).

I think the App Store is the most straightforward for the average user--I just
wish they'd improve it so it was used more.

