Access dot folder file from macOS app with App Sandbox

Question

This macOS app needs to access a file which is located in a custom dot folder (~/.folder/file) but it is not clear how this should be done. Below are a few options I have considered.

Request Permission

Have the app request permission from the user with the path predefined. Then I expect I would need a security-scoped bookmark to retain access across app launches. Is it possible to predefine the path or does the user have to use a Finder window to select the file?

Agent

An agent could read the file and use XPC to communicate with the app. Perhaps this may have different access than a full a macOS app though there are not examples which I could follow for this use case.

Command Line Tool

The app installer could include a tool which the macOS app runs via shell and it would have the access that is needed. It would output JSON to stdout which can be read in with Swift/Codable. Using a shell to run a command may not allow access though. It would likely have the same restrictions as the app itself.

Access to a single file is all I need for now. I would like the option to access all contents of a folder for other use cases, so any API which allow that to work would be appreciated as well.

What is the best way to do this?

Sandbox file access

1.6k

Posted by

brennanAMZN

Reply

Another option I am considering is having the certificate which is stored in this file copied into a keychain item which could be accessed with a keychain access group. Then Mac apps can access it and monitor it for changes.

—
brennanAMZN

Add a Comment

Answer 1

I can use the entitlement below despite that it is named a temporary exception. This has been in place for years and appears to be allowed all this time.

I want to clarify the meaning of the word temporary here. These temporary exception entitlements were named from the context of the Mac App Store. That is, App Review allowed folks to use them while we built out critical App Sandbox infrastructure. For example, the Mac App Store shipped before we had security-scoped bookmarks, and thus it made sense for App Review to allow folks to use these entitlements temporarily.

So, you must look at this from two different angles:

From the perspective of the App Store, these temporary exception entitlements should no be longer necessary and any use of them is carefully examined by App Review. And, while I don’t work for App Review, and thus can’t make definitive statements about their policy, my experience is that they typically reject folks using temporary exception entitlements.
From a purely technical perspective, temporary exception entitlements are public API and we don’t expect them to go away. If you’re sandboxing an app that you don’t plan to ship via the Mac App Store, it’s absolutely fine to use them.

I’ve filed a bug to get this clarification into the official documentation (r. 90755718).

With regards your specific situation, it’s sounds like you’re not planning to distribute via the Mac App Store and thus it’s reasonable for you to use a temporary exception entitlement. My only concern is that ~/.ssh is pretty-darned security sensitive and thus it might make sense to move the code that access this to an XPC Service. That helps to reduce your attack surface. For example, you might code your XPC Service so that it can only read and return one specific key, which means that code running in your main app only has that capability, not the capability to read all files in that directory.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by

eskimo

Add a Comment

Answer 2

I found the answer. I can use the entitlement below despite that it is named a temporary exception. This has been in place for years and appears to be allowed all this time. I can add /.ssh/ to the list under this value to access the config and keys. There are other folders I will need to access which will work this way.

com.apple.security.temporary-exception.files.home-relative-path.read-write

Posted by

brennanAMZN

Add a Comment

Answer 3

I can use the entitlement below despite that it is named a temporary exception. This has been in place for years and appears to be allowed all this time.

I want to clarify the meaning of the word temporary here. These temporary exception entitlements were named from the context of the Mac App Store. That is, App Review allowed folks to use them while we built out critical App Sandbox infrastructure. For example, the Mac App Store shipped before we had security-scoped bookmarks, and thus it made sense for App Review to allow folks to use these entitlements temporarily.

So, you must look at this from two different angles:

From the perspective of the App Store, these temporary exception entitlements should no be longer necessary and any use of them is carefully examined by App Review. And, while I don’t work for App Review, and thus can’t make definitive statements about their policy, my experience is that they typically reject folks using temporary exception entitlements.
From a purely technical perspective, temporary exception entitlements are public API and we don’t expect them to go away. If you’re sandboxing an app that you don’t plan to ship via the Mac App Store, it’s absolutely fine to use them.

I’ve filed a bug to get this clarification into the official documentation (r. 90755718).

With regards your specific situation, it’s sounds like you’re not planning to distribute via the Mac App Store and thus it’s reasonable for you to use a temporary exception entitlement. My only concern is that ~/.ssh is pretty-darned security sensitive and thus it might make sense to move the code that access this to an XPC Service. That helps to reduce your attack surface. For example, you might code your XPC Service so that it can only read and return one specific key, which means that code running in your main app only has that capability, not the capability to read all files in that directory.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by

eskimo

Add a Comment

Answer 4

Thanks Quinn, I appreciate you.

This additional context helps. I currently don't intend to ship via Mac App Store but would like to distribute releases with an installer (.dmg or .pkg) which now appears to require notarization. I'd appreciate clarifications for the temporary exceptions for Enterprise deployments. Leveraging TestFlight so that I can get feedback and crash reports in Xcode would also be appreciated.

There are actually 2 dot folders I'd need to access. One is ~/.ssh because we are using the RSA certificate auth feature in OpenSSH to connect to a system. That auth tool creates a file at ~/.ssh/ id_rsa-cert.pub which is needed to make SSH/SCP connections. Our tooling which authenticates user sessions generates this certificate file with a limited lifetime along with files in another dot folder which I would need to interact with internal services. For both I think the right architecture and security recommendation would be to store these assets in the keychain using an access group. I can make a request to do this, but it may not be a high enough priority to be considered.

I've read up on XPC services, daemon processes and user agents on macOS but I did not see any details about the App Sandbox and Hardened Runtime policies. Could you also request clarification related to these use cases?

Posted by

brennanAMZN

Add a Comment

Answer 5

I'd appreciate clarifications for the temporary exceptions for Enterprise deployments.

macOS does not support anything like the In-House (Enterprise) distribution you find on iOS. For macOS you can ship an app via the Mac App Store or an app (and various other products) independently using Developer ID signing. The former involves App Review, and their temporary exception entitlement policy, the latter does not.

Leveraging TestFlight so that I can get feedback and crash reports in Xcode would also be appreciated.

I don’t know if App Review enforces their temporary exception entitlement policy on TestFlight apps. You’d have to ask them, or just suck it and see.

For both I think the right architecture and security recommendation would be to store these assets in the keychain using an access group.

FWIW, I agree. Leaving security critical credentials lying around in random files on disk is less than ideal.

I've read up on XPC services, daemon processes and user agents on macOS but I did not see any details about the App Sandbox and Hardened Runtime policies. Could you also request clarification related to these use cases?

XPC Services are separate executables that existing in their own app-like wrapper, which means they can have their own sandbox configuration. This allows you to have an app with one sandbox config and an XPC Service with a different one. This is great for both increasing and decreasing privileges:

You might want to run some risky code (decoding a complex image format, say) and so you’d put that work in a XPC Service with a very restricted sandbox.
You might want to do what I suggested above, that is, restricted use of a privilege to just the XPC Service.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by

eskimo

Add a Comment

Access dot folder file from macOS app with App Sandbox

Accepted Reply

Replies