You’d think that adding more security measures to your Mac would make it more secure. Last week I learned that, in some circumstances, it doesn’t. In fact, if those added security measures aren’t carefully thought out, they can lead you to behave recklessly, and effectively disable the primary defences in macOS. Without your being fully aware of what you’re doing.

This all arose with several who, in trying to use my free apps, found that they couldn’t open them successfully on their Macs. In most cases – and these are now the most frequent cause of support problems here – these Macs are running Little Snitch, the excellent software firewall which is intended to prevent unwanted software and malware from ‘phoning home’. In essence, when these users tried to open one of my apps as a new install or update, Little Snitch was blocking the app by preventing it from completing its ‘first run’ checks.

Apple has progressively increased the extent and depth of these ‘first run’ checks on apps which are downloaded to your Mac from all software suppliers apart from Apple and its App Store, to make them more comprehensively protective. With Sierra, it introduced app translocation (officially known as Gatekeeper Path Randomisation), which in certain circumstances means that the first run of a freshly downloaded app occurs from a special temporary location. This is to prevent a malware behaviour known as ‘repackaging’, and has been judged an effective measure by many Mac security experts outside Apple.

In Catalina, ‘first run’ checks are even more extensive. They include a deep signature check and assessment of that app’s notarization, both of which will normally involve macOS – not the app – checking the app’s credentials with Apple’s servers. Although Apple is only just about to enforce it fully, notarization brings another important security measure: as of next month (February), all apps which are freshly notarized are also required to be hardened, which brings with it additional protections when the app is running.

The consequence of all this protection should be that any app you download which passes all its first run checks – translocation (where applied), full signature check, notarization check, hardening (required soon for all notarized software), and the concomitant XProtect malware scan – should have an extremely low probability of behaving maliciously, or of being vulnerable to manipulation by malicious software. These are the primary defences in macOS against malware, and apply to software which is transferred by relatively non-secure local mechanisms such as AirDrop too.

As I and many others have pointed out, these all rely on a gentleman’s agreement, for a quarantine flag to be attached to downloaded software. There are rumours that Apple intends closing the loopholes in this: for example, it is well-known, and commonly exploited by malware, that downloading software using the tool curl is outside this agreement, and doesn’t result in a quarantine flag being attached, so bypassing all first run checks.

The user is also free to strip, or clear, the quarantine flag on any downloads that they wish. This provides a way round situations in which items which are correctly put into quarantine, but which the user knows can’t pass first run checks, can still be used when there is no better solution. But stripping a quarantine flag should always be a last measure, and should never be undertaken lightly because it does significantly increase risk.

So what has any of this to do with Little Snitch and running my apps?

My apps and command tools (those which are compatible with Catalina) are all fully signed and notarized, and most have been for more than a year now. Before I Zip up any of those apps and tools for distribution, I attach a quarantine flag and run them in macOS 10.15.2 from a non-application folder on a removable volume, to verify that they pass first run tests. I have also tested many specifically to ensure that they work fine with app translocation, and they do.

I go further than that. Mindful of the fact that, once an app has cleared its first run, its signature is normally never checked fully again, each of my apps checks its signature properly whenever it starts up. This gives you the added assurance that it hasn’t become damaged, either accidentally or as a result of malware. Unfortunately, verifying its notarization isn’t as quick and simple, so the apps don’t attempt to do that.

I have also introduced a simple mechanism by which each app checks whether it is up to date, and offers to download a more recent version when one is available. This involves connecting to my GitHub server and reading a Property List there; where an update is downloaded, this is performed through your default web browser, so that you still have the benefit of its full protection, including the attachment of the quarantine flag so that the downloaded app undergoes full first run checking when you open it.

I have looked very carefully at using the commonly-used Sparkle mechanism for providing updates. This has an option whereby the update is installed without a quarantine flag, but to do so requires high confidence that your update server is completely secure. While this blog is served by Automattic, I can’t put my hand on my heart and promise you that it will remain completely secure, nor do I have any ability to assess its security for serving updates. I would therefore have to pay for a proper secure server, and keep a very close watch on its security, if I were to consider adopting Sparkle’s approach and bypassing first run checks.

In any case, Sparkle only works with updates. No new install of any software downloaded from the Internet should ever bypass first run checks, as doing so blocks the user from receiving any of the benefits of the macOS primary defences, and would allow your Mac to run unsigned, non-notarized, unhardened software with only a quick check by XProtect (in Catalina). Whilst you may wish to do that on occasion, that must be a conscious choice on the part of the user, following careful assessment of the risk.

Bear in mind the fact that software update servers are attractive targets for bad actors. Just over a couple of years ago, a quite substantial and reputable Mac commercial developer had its servers hacked to deliver malware to customers, and every few months another online source of Mac apps gets subverted. The security benchmark here is the App Store: apps delivered from that don’t undergo first run checks because Apple considers its security to be sufficiently robust to guarantee your safety. Any third-party who wishes to make a matching claim needs to attain comparable standards of security in storage and delivery, and that simply isn’t feasible without charging substantially for your products.

Unfortunately, the security behaviour of my apps can cause problems with Little Snitch, most particularly when macOS translocates them for their first run. This stems from two behaviours of Little Snitch: first, its rules are applied not to software identified by its ID (e.g. co.eclecticlight.CirrusMac) but by the full path to the app. Run a whitelisted app from a different folder, and Little Snitch won’t apply the same rules which you already set for running it from, say, your main Applications folder. The other behaviour which trips innocent apps up is that Little Snitch doesn’t appear to apply any default universal rules which, for example, allow apps to have their signatures and notarization checked against Apple’s servers.

So, what advice is given to Little Snitch users to cope with such circumstances? The only support material which I’ve been able to discover is a blog article dating from soon after the introduction of app translocation, back in February 2017. This recognises the problems which occur when an app is translocated and attempting to pass first run checks: Little Snitch blocks the first run checks, so the quarantine flag is left set, then the next time that user tries to run the app, it is launched from a different location, blocked again by Little Snitch, and so on until you give up trying.

That article makes a clear recommendation to resolve this issue: “Well, the best solution of course would be that app developers properly de-quarantine all parts of their software when downloading updates.” The only way that an app can do this is by removing the quarantine flag which macOS has attached.

The recommendation to the user is: “You can de-quarantine all parts of an application yourself. Just launch the Terminal app (/Applications/Utilities/Terminal.app), enter the following command and press Return:” Followng that, a prototype command is given to remove the quarantine flag, “And after doing that please write a friendly reminder email to the guys that created that app… :)”

Nowhere in that blog article is there any caution given to users that stripping the quarantine flag, as recommended, will bypass all first run security checks run by macOS. Indeed, the description of Gatekeeper given at the start omits any mention of those first run checks, stating merely that “Among other things it makes sure that apps that are in quarantine (= were downloaded from the internet or received via AirDrop) are temporarily moved to a private location when launched …”.

Predictably, online discussions about problems with app translocation and Little Snitch usually recommend stripping quarantine flags, and from what I can see, this has become quite widespread practice. Yet – just as in the blog article – no one seems to be concerned that what they are doing is bypassing macOS’s primary security defences.

Gatekeeper’s first run checks and Little Snitch have quite different security roles. Protections provided by macOS are primary defences, in that they are intended to prevent malware from being run on your Mac in the first place. Although there are circumstances in which Little Snitch could act as a primary defence, it normally only has a secondary role, when you are already running malware which then tries to connect to a remote site to download additional malicious software, or to transfer stolen data from your Mac. Secondary defences are important and valuable, but only insofar as they don’t weaken any primary defence.

I believe that however much we might be sceptical about some features of macOS security, additional security should only enhance that common baseline, and never lead users to bypass the protections afforded by macOS.

Bad actors are well known for exploiting weaknesses in human behaviour, and encouraging users to strip quarantine flags to prevent newly-downloaded apps from undergoing full first run checks is inviting them to welcome malware to their Macs. Putting pressure on Mac developers to adopt update methods which rely on server security is also an excellent way of encouraging attacks on those servers, and the delivery of more malware to unsuspecting Mac users.

That isn’t the end of the story, though. Apple’s documentation of app translocation is, as you’d expect, scant and lacking in detail. In the final minute or so of Session 706 at WWDC 2016, Apple gave a little insight into what triggers app translocation in the first place. All my app downloads consist of a Zipped folder, inside which is the app and various supporting files, usually documentation. What determines whether that app is translocated on its first run is whether it alone is moved into another folder, such as /Applications.

Most users, when they have downloaded one of my apps either as a first install or an update, drag the app from the folder it arrived in and put it in /Applications. When you do that, app translocation will be disabled, even though the quarantine flag remains attached and the app will undergo full first run checks.

If you move the whole folder, or leave it where it is, and then try running the app, it will be translocated. If you happen to be running Little Snitch too, this will become an unresolvable problem, as you will be unable to allow the app first run checks, and every time that you try, as it’s translocated to a different folder, Little Snitch will fail you.

Amazingly, Apple seems not to have got around to explaining this problem to users, sysadmins, or developers, except in those few seconds of a presentation over three years ago, as in the transcript:
“If the user […], if they move the app with something else, then this mechanism does not get turned off. If the user moves the single app by itself, maybe to /Applications, then this mechanism will be turned off.”
This is also explained in Jeff Johnson’s article written shortly after that presentation and his own testing.

If you’ve been using Little Snitch or another firewall and have resorted to stripping quarantine flags to bypass your primary security, so that you can get an app through its first run checks, chances are that all you needed to do was to move the app (alone) to your /Applications folder – indeed, any other folder away from the rest of the contents of that download. This won’t of course work with apps which try to update themselves in place, which can apparently face similar problems.

Perhaps after three years, it’s time for Little Snitch to address some of these issues, rather than recommend users to bypass macOS primary protection altogether. It would also be helpful if Apple would tell users about this, now that software firewalls are becoming so popular.

Further reading

Session 706, WWDC 2016, the only place where I can find this described by Apple
Jeff Johnson’s article detailing translocation behaviour, and again here
Patrick Wardle, who describes how he had to work around the problem
Michael Tsai has an extensive compilation of quotes and links (as always).

I am very grateful (really!) to those users who have contacted me about this problem, particularly Ric Ford of Macintouch. I apologise if my responses have been critical, but hopefully this article explains why.