...But what Gatekeeper fails to do, Wardle said, is check whether an app runs or loads other apps or dynamic libraries from the same or relative directory.... https://threatpost.com/apple-gatekeeper-bypass-opens-door-for-malicious-code/114851/
Looking at the diagram in the article, step 1 is to find a signed app that at runtime loads and runs a relative binary. To that I would add that the developer also broke the rule of always signing any packaged binaries and verifying the signature before loading Since that verifying is done in Apple-signed code, it would be impossible to bypass. It is not difficult and only lazy or uneducated developers skip the signing and verification. Step 2 is to leverage the improperly constructed loader by substituting a different malicious executable or library and trick the user into running two DMGs instead of just one, no easy trick.
It is not unique to system files, any file or library could be loaded and executed by the poorly constructed (lacking proper verification) loader. That could be loaded and run at system privilege in which case the damage is much worse. If it is loaded and run at user privilege it can still be damaging but a privilege escalation is very difficult as we discussed in another threat.
You can't change permissions of existing system files to prevent this since an unverified load at system privilege has permission or can change it easily. Obviously not all installs go to system privilege (you know because it asks you for a password) and those that do are usually more carefully constructed. Obviously relatively few developers load extra libraries and executables and those that do are probably mostly doing it properly by signing in advance and checking the signature at install time in their trusted code.
I know what you are saying. . . and you are right as far as this is going. The point is that it still requires the DEVELOPER to be the malicious bad actor, installing the malicious files in his own distribution. I don't think any developer would do such a self-destructive thing.
Actually, on a Mac it might be possible protect system files from ordinary installers of software as the "Administrator" is not the ultimate level of user. There is still the superuser level. The Administrator is the level required to install software, but the superuser is the level of administrator required to do everything including modify certain system files. Structuring the installers to limit that to not allow these files to permit modifying any of these is certainly possible. The vast majority of Mac users never have access to that super level user as it is turned off by default and is only accessed when an update is being done to the operating system. A mere Administrator level is what they may have access to allow them to install software. . . and they should only be running as a standard user, without even administrator access.
Giving a DMG installer an Administrator name and password should never give it permission to overwrite any critical system files. . . only to install its own executables.