fcntl() is just to lock the file so I can do the call to SecStaticCodeCheckValidity() and then dlopen() atomically without someone switching the dylib at just the right time, leaving us loading an unvalidated dylib.
I think that’s unlikely to provide the level of TOCTTOU protection that you need. For example, even if you lock the file someone could rename the parent directory so that path points to a different file.
IMO the only way to get reasonable TOCTTOU protection is to ensure that the file is in a location that’s not writable by potential attackers.
could we somehow create an open-ended constraint on who could create one of these plugins?
Yes, but it’s not easy to do in a Developer ID signed world. Ideally you’d like the signing certificate to include some sort of indication that it was ‘blessed’ by you for this purpose. You can’t do that in a Developer ID world because the signing certificates are issued by Apple. You could use your own CA to issue signing certificates to your partners, and that’d allow you to check that the code was actually signed by one of those partner.
Does Apple have any guidance or policy regarding where application developers should be putting dylib plugins like this in /Library/?
Check out the following sections of the File System Programming Guide:
In your case I recommend
/Library/Application Support/YourCompanyName
as your base and, within that, you can break it up however you like.
WARNING I assume you’re targeting 10.7 and later. Older systems don’t necessarily protect
/Library/Application Support/
properly, so you have to jump through extra hoops.
Share and Enjoy
—
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"