Hey Devs, please don't do that! (from a dev)

Its a bit off-topic, but those who are meant may find themselves in this forum

Im not only a developer, I actually use software from other pro-audio companies as a user. What I have found in installation routines of at least 3 software companies from the pro-audio area (I will not mention any names now) is terrifying:

→ They install binaries in the MacOS-Path /Library/PrivilegedHelperTools
That means this software modules can be executed with full-admin rights, without additional opt-in of the user, anytime.
This bypasses the whole security concept of a modern operation system. This can quickly lead to critical security vulnerabilities if they are not properly secured.

→ Opt-Out sending of “Analytics”-Data to external servers
Yes, there are still companies who do that.
Make it Opt-IN or let it be, make it transparent (not pseudo transparent)
Don’t trick the user to get the opt-in

→ Do not let the program crash when debugging
Hackers laugh at this trick, everyone else (who want to find bugs) just gets annoyed.

So that’s it with my little rant, maybe you have something to add :wink:

7 Likes

What is the correct thing to do instead? Traditionally I’d use AuthorizationExecuteWithPrivileges to ask the user for their password and then run a quick script to do the privileged operation. However this function is now deprecated and Apple instead recommends “Use a launchd-launched helper tool and/or the Service Management framework for this functionality.”

So that means if you want to write an auto updater, you pretty much need to use tool in PrivilegedHelperTools. Or if you want to install content into /Library/Audio/Presets

I try and keep my tool as small as possible, to minimize the risk of exploits, but I recognize it’s still a possibility.

I do not understand why Apple has deprecated AuthorizationExecuteWithPrivileges, it seems so much safer.

1 Like

What is the correct thing to do instead?

TBH, I don’t know. Does apple really want that all kind of developers install privileged deamons, who can literary do anything on the system, I don’t think so.
An option could be just to download a pkg into the Download-Folder directly, and prompt the file to the user, then you can also run script with higher privileges. As a user I would prefer this, because its more transparent, when the installation process starts and ends.
Any solution where a password is cached in a user process seems also fishy.
The best solution is when you don’t need any privileges.

3 Likes