I agree this is a significant privacy and security concern. I am not talking about us as devs, but from the user perspective, there are clear expectations that when they choose to delete an app and all its data, then this is done. Obviously keeping keychain data - the most sensitive data - despite the user opting to delete all data is clearly not appropriate for the user.

I am trying to explore this a bit further, just to make sure. I understand with your answer that I cannot use an adhoc profile. However, could I create a self-signed certificate, add a team ID to this self-signed certificate, and sign the app with this? I tried to do this, but the binary still appears with "team id=not set". Is there anyway to force setting the team id, from a self-signed certificate?

Hi, I am still struggling with this issue. I never gave permission to the sandboxed app to access iCloud drive and yet, it merely adds files to it. Is there a way maybe to reset icloud access permission to the app? (though I never gave it, the OS might have incorrectly given it).

Sure : I downloaded an app on the macOS app store this app had the entitlements I copy pasted above. In particular, this app was sandbox (as per macOS app store requirement) I never gave permission to the app myself to access iCloud drive. I did not select icloud drive in any way in any panel. In spite of 3), I noticed that the app was able to create a directory for itself in iCloud drive, and store file there To be clear, I am not claiming the app is able to access other directories in iCloud drive (which is what your code above is testing for). Thanks

Understood. But in this case, I have never selected the iCloud drive in an open panel. The sandboxed app is able to store files in iCloud drive without any user interaction.

Ah, thanks that's helpful. I understood from your previous reply that I needed to change the code. However, I am still struggling with this, even after going into the codebase. It is an electron app. I thought that moving the electron build from platform=darwin to platform=mas would be enough. Unfortunately I still hit the exact same snag. This is surprising to me, as I think the socket is created by the electron platform (for communication between the different processes). Do you have any knowledge of electron by any chance, and do you have any random ideas that you could point me to? Thanks!

Ah right, that all makes sense. Is there any way to add the directory /var/folders/s2/j0z79krx321qg318das1r95_zc0000gn/T/com.funkyapp to the app's container, or to the app group's container?

Hey, thanks for that, your guide is great ! It worked and helped me solve the problem of deny(1) forbidden-sandbox-reinit.

Well, let's imagine I have a python script that does something easy to do in python, but hard in swift : script.py I would like to run this python script on a macOS system, but to protect the python process against tempering, I would like this python process to have a hardened runtime. In the link you sent, there is a fully fledged app, in addition to the script. So I was wondering if there was a simpler way to do this, without the full app. Also, with the technique described in the link, I don't know if the runtime of command-line tool itself is actually protected with hardened runtime?

Thanks for the link. I saw this, but this is not exactly the use case : I was hoping to have only a simple command line tool, not embedded inside an app. I guess it's not really possible.

Thanks for your answer. I missed that list was a legacy command. I'll study further the launchctl man page to understand how to list login items. It's not clear on first read what the right command is. I wish there was a command line/system wide way to manage services. I understand your point that managing them from the app is good, but I also feel we should be able to control it from the OS, to avoid rogue services/malware, etc.

Ah, that is good to know. Thank you.

I understand, thank you for your answer. Regarding your point "make sure to re-sign any nested code, from the inside out" is it enough to use the "deep" option when doing so? Specifically, is it good enough to use this command : codesign -s $ID_NUM -f --deep --options runtime --entitlements new_entitlements.txt $APPLICATIONPATH

Ah, that makes sense. Thank you, I was missing that piece.

Ah, I have digged a bit further. If I resign the app with the original entitlements, then it works properly. So it seems the issue was a compatibility one: apps signed in older version of macOS do not honor the entitlement. Simply resigning under the new OS seems to solve the problem.