-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable App Sandbox on macOS builds #10478
base: develop
Are you sure you want to change the base?
Conversation
This commit enables the App Sandbox feature, as well as explicitly enabling the following entitlements * USB device access (for hardware keys) * User selected file access (r/w) * Network client (for HIBP and icon download) * Application groups (for IPC with keepassxc-proxy) This commit is a WIP, so expect bugs.
App sandbox breaks browser integration, because there are no fitting entitlements for it. |
Not true. Apple just is not great at documenting them and they are not visible in the dumb and limited default Xcode UI for sandboxing. Here's a large list of examples, all allowed even in app store. Not a comprehensive list, but serves as an example. Pick and choose depending on your use cases. com.apple.security.temporary-exception.sbpl key is especially interesting because it allows full support of the actual .sb sandbox file format exotic cases.
|
Further, it can get tricky finding what exactly you would need to allow in the sandbox rule set. The best way is to run console app and simply work through the entire app and its functionality. You need to use all the features including browser extensions. Then stop the console app recording and filter for "processName sandbox", so in this case it should be "keepassxc sandbox". This will show all the sandbox violations and usually (but not consistently), which exact sandbox rule was violated. Then simply allow this using the above .plist entitlements format. For a complex app the list can grow quite long. |
Seems like by the time you finish all this work you pretty much nullify the point of a sandbox. Perhaps not entirely, but pretty darn close. |
All the ones I could find in the docs were either for specific default locations or required the user to explicitly select a path with the open file dialogue. If these work without user interaction for arbitrary paths, I'm happy to use them. |
Not quite. The point is to protect against unintended breaches and thus potential vulnerabilities. The entitlements essentially document the application security model. Only allow what you know is necessary. If a vulnerability pops up, it does not escape the sandbox. |
This pull request enables the App Sandbox feature, as well as explicitly enabling the following entitlements:
The following entitlement has not been added/tested:
This commit is a WIP, so expect bugs.
Enabling the App Sandbox on KeePassXC can further enhance the security of the app. If some malicious code/payload is inserted into a KeePassXC database, and somehow get executed, the sandbox can protect the rest of the OS from being further compromised.
Screenshots
N/A
Testing strategy
Type of change