I have a macOS app that I have been distributing for free outside the app store for more than 15 years, without notarization, without sandboxing, and without hardened runtime, all with no problems.
If I understand correctly, macOS will soon be modified so that it will not launch any developer-distributed apps that are not notarized. Notarization will require both hardened runtime and sandboxing, and unhappily, my app will not run when notarized -- I have added sandboxing and hardened runtime, than gotten it notarized and tried -- and that is because it will not run when sandboxed. Thus I have two questions:
Will there be some means, that I perhaps have missed, for my users to run my app as is, in un-notarized form with no sandboxing and no hardened runtime? (Assume that they are willing to click "Okay" on any macOS popups of the form "Abandon hope, all ye who enter here.") Perhaps I have missed something about the signing or distribution process ... ?
If not, is there some entitlement I can obtain to allow my app to run when sandboxed? Perhaps the question is even "Should there be such an entitlement?" And to that end, I must now explain why it cannot run sandboxed:
My app is a parallel processing system: To work properly it must open multiple copies of itself -- that's right, there will be multiple instances of the app window visible on the console, distinguished by tint, title and location so the user can tell which is which, and multiple app badges in the dock, similarly distinguished. Doing so is easy -- I use the c++ "system" function to call the Unix executable that is buried within the ".app" folder, passing it a command tail whereby the launched copy can tell how to distinguish itself. I build up the text string for the call piece by piece, but the result looks rather like this:
system("<path-to-my-app>/MyApp.app/Contents/MacOS/MyApp -tail-item-1 -tail-item-2 ... &");
The app is written in mixed C++ and Objective C. The usual "Main.mm" file contains the entry point for the program, a "main()" function that does nothing but call "NSApplicationMain()", but I have added code to "main()" that runs before the call of NSApplicationMain(). That code uses C function "getopt()" to look for the extra command-tail items. If any are present, the app acts appropriately -- generally assigning non-default values to global variables that are used later in initialization.
The first instance of the app that is called -- presumably by the user mousing on an icon somewhere -- knows by the absence of extra command-tail items that it is the first one launched, and thus knows to launch multiple additional instances of itself using this mechanism. The launched instances know by the presence of extra command-tail items that they are not the first one launched, and act differently, based on the command-tail items themselves.
All this has been working fine for over a decade when the app is not sandboxed and does not have a hardened runtime.
For what it is worth, the app will run with hardened runtime, provided the option "Disable Executable Memory Protection" is checked. Furthermore, when it is also sandboxed and I open it with no extra copies of itself launched (the number to launch is a preferences option), that single app instance runs fine.
I have instrumented the code, and what seems to be happening is that the system call to launch another app returns zero -- implying it succeeded -- but has no effect: It is as if someone had special-cased "system" to do nothing, but to report success nonetheless. That is an entirely reasonable feature of a hardened runtime -- allowing arbitrary system calls would be a security disaster looking for a place to happen.
The point is that my app would not be making an arbitrary system call -- it would be trying to open one specific app -- itself -- which would be sandboxed with a hardened runtime, and notarized. That is not likely to be a huge security problem.
Incidentally, not all system calls fail this way -- I can do
system("osascript -e 'tell app \"Safari\" to activate';");
or
system( "open -a \"Safari\" <path to a help file located in MyApp's Resources>");
with impunity.
Also incidentally, using AppleScript to launch another copy of MyApp from within itself doesn't do what I want: The system notices that MyApp is already running and just makes it active instead of launching a new copy, and there is no way to pass in a command tail anyway.
I don't wish to appear to be advertising, so I won't identify my app, but a little more detail might be useful: It is a parallel program interpreter. The language implemented is the "Scheme" dialect of Lisp. Each instance running is a complete read/eval/print loop embedded in an application window where the user can read and type. The first instance of the app launched mmaps a large memory area for the Lisp system's main memory: That works kind of like a big heap in more conventional programs. It is not executable code, it contains Lisp data structures that an application instance can access. The other instances launched use the same mmapped area. The shared memory has lots of lock bits. I use low-level "lockless coding" -- hand-coded assembler with the Intel "lock" prefix or the more complicated arm64 stuff -- to keep simultaneous access by different app instances from corrupting the shared memory.
Parallel Scheme has many uses, which include debugging and monitoring of running Scheme programs, and having multiple tail-recursive "actors" (Lisp jargon) operate on the same data at the same time.
Enough said. I would like to be able to notarize this app so that users who obtained it outside the app store could understand that Apple had checked it for dangerous code. If that were possible, I might even try submitting it to the app store -- but that would be another story.
Do I have any hope of keeping this product available?
5
0
1.8k