App frequently requests potentially erroneous permission on macOS Sonoma

[ghost]

In macOS 14.0 Sonoma, data in /com.example.app/Data is now protected. If another app (with a different bundle identifier) tries to access this sandbox, the app prompts the user for sandbox access. This is not a traditional permission, but rather one that is requested every single time the app is closed and reopened. For more context, read Jeff Johnson's article about sandbox security.

When any application, even a built-in app like Terminal, attempts to sign an SSH key request, it asks for the permission to "access data from other apps". Weirdly enough, if you deny the permission, the SSH key still authenticates.

Since Secretive may not need this permission, is there any way to fix this?

Edit: Updated this issue to fix an issue with my testing. When you SSH into GitHub it often returns that, no matter what. The main issue with sandboxing still stands.

[ghost]

I was reading #403 and I wonder if a symbolic link will fix this issue. I will test this at some point.

Edit: It does not help.

[maxgoedjen]

Unfortunately I don't think there's a way around this short of outright disabling sandboxing, which I'd prefer not to do... weirdly using terminal to ls that directory shows the prompt for me, but (after relaunching to reset the prompt) performing an actual signature does not for me.

One workaround noted in that article is giving Terminal/other apps Full Disk Access permission – not ideal either as a general thing, but for Terminal a pretty reasonable compromise IMO. Are you hitting it for other apps (eg Git GUIs etc)?

I was hoping that since the app container structured mirrored the home directory's structure, putting a Public folder in there might just do the right thing – unfortunately that doesn't seem to work.

[ghost]

I'll have to test out what you tried, including using other apps.

It's probably better to write the key to a common directory like the home folder, but I'm not sure if that's possible with sandboxes apps sadly.

Not sure of a workaround either.

[maxgoedjen]

I suspect it might be doable with the "User Selected Directory" permission – basically somewhere in onboarding, prompt the user to select where they want their key. Might be kinda complicated because SecretAgent is a separate process though, so I think it'd have to initiate that? I'll think about it a little more.

[ghost]

Makes sense. Can you explain how the handler works though? Usually you use private keys as the identity file, but with your app the documentation instructs people to point to the public key file.

[maxgoedjen]

Basically ssh is just... smart enough to figure it out in certain contexts. If you run ssh -tv [email protected] (assuming you have Secretive configured for that) you'll see this in the logs:

debug1: Offering public key: /Users/max/Library/Containers/com.maxgoedjen.Secretive.SecretAgent/Data/PublicKeys/e30502f14f7f8ed40e7e87dc0c8c54ae.pub ECDSA SHA256:nE0RpoBWke8JjFdHbFxRN+9Ugnvg08GNubKlqx4pD9Y explicit agent

Also you won't be able to link symbolically as you noted, but those files are stable for a given secret – it's just the public key of the secret. Somewhat inconvenient, but you can just copy them to a directory of your choice and it should be fine. You'll probably still get the warnings when it hits the actual socket though, that can't be moved 🤔

[maxgoedjen]

@insidegui suggested https://developer.apple.com/library/archive/documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/AppSandboxTemporaryExceptionEntitlements.html#//apple_ref/doc/uid/TP40011195-CH5-SW7 as a potential solution – basically just declaring ~/.secretive/ to be inside the sandbox and putting public keys/socket there. Playing with that now – the socket does not seem happy being in that location, but if I can get that working properly that might be a decent solution.

[ghost]

That could work, yeah! Is there any reason why keeping sandboxing is that important? I'm not super familiar with macOS development at the moment.