Post not yet marked as solved
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).
Post not yet marked as solved
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
Post not yet marked as solved
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.
Post not yet marked as solved
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?
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
Ah, that is good to know. Thank you.
Post not yet marked as solved
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
Post not yet marked as solved
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.
It feels like a pretty serious bug to me. This entitlement is meant for safety, and it seems that the code underpinning it is broken.
I feel I should file a bug report to prevent
Other developers building apps with that entitlements set as false, not knowing this fails
Other bugs in that code (a bug might hide others)
I understand your point about binary compatibility, but at the very least a warning on the documentation page not to explicitly set the value as false would be useful.
Ultimately, I'll rely on your judgement though, what do you think?
Hi Eskimo, thanks for your help.
when I remove the line entirely (but keep the sandbox entitlement), it seems it is not making network connections.
(I am not entirely sure because the network connections are only sporadic, but that seems to be the case).
That is odd, is that entitlement broken?
