See if GPG Sync can work with OSX sandboxing

[micahflee]

Enabling sandboxing is a prerequisite for getting in the App Store. I'm pretty sure that it simply won't work with this project, not as long as we're subprocessing out to gpg. But it would be good to confirm, because turning on the sandbox would be great.

Relevant research:

• https://developer.apple.com/library/ios/documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/EnablingAppSandbox.html
• https://stackoverflow.com/questions/12594380/how-to-launch-another-process-in-sandbox-on-mac
• https://github.com/electron/electron/blob/master/docs/tutorial/mac-app-store-submission-guide.md

If we could find a good python library that implements the OpenPGP spec, and can read/write to ~/.gnupg, and interface with key servers, we could use that instead executing gpg subprocesses. But it does seem not that likely.

[micahflee]

So, it looks like GPG Sync can't be sandboxed so long as it's subprocessing out to a gpg2 binary that was installed via GPG Tools, homebrew, etc. But it is possible to have multiple processes within the same app sandbox.

So GPG Sync could bundle its own gpg2 binary, and then it could call that. So long as the gpg homedir is within the app's container directory, then this should all work. The only problem then, of course, that GPG Sync won't be able to read/write to ~/.gnupg, where the user's real keyring lives.

However what it could probably do is refresh all of the keys, then export them into a file like gpgsync-pubkeys.asc, and then it can maybe open that file using the default handler for it, which is most likely GPG Keychain Access. So basically, each time a sync finishes, at the end of the process it will briefly pop up GPG Keychain Access to import all of the fresh keys.

I haven't verified if this will work or not. But it might, and it's certainly worth more research.

[micahflee]

It just occurs to me that if we did go this route, I don't think #36 will be possible.

[ageis]

@micahflee I want to help with the Linux build process, because I can provide advice on hardening the GPGSync service via systemd.

You could perhaps also use seccomp-bpf somehow, but that's for ELF binaries I think? If you want to wrap your Python program in C that might work. Example: https://blog.yadutaf.fr/2014/05/29/introduction-to-seccomp-bpf-linux-syscall-filter/ vsftpd3.0 also has an approach.. OpenSSH has UsePrivilegeEscalation and Tor has the Sandbox option... I am surprised I can't find ANYTHING about GnuPG implementing seccomp-bpf.

In any event, systemd can sandbox probably just as well as seccomp at this point.

[micahflee]

I think I'm going to close this issue, because sandboxing in OSX isn't possible as long as we want to interact with the user's main keyring in ~/.gnupg.

And @ageis sorry about replying 20 months late :). GPG Sync doesn't actually run a background service. The entire thing is a GUI app that runs in your systray when it's not active. If you quit the app, it no longer runs. So I don't think systemd hardening is the right tool for this -- maybe AppArmor is though? In any case, we can figure out hardening in a separate issue.

[micahflee]

I was wrong, I think sandboxing is possible. I've started work on enabled the Mac app sandbox for OnionShare, and I think I have a better idea of how it could work.

In order to have the sandbox, we'll need to:

• Bundle a copy of the gpg2 binary with GPG Sync (instead of making the user install GPG Tools first) and codesign that binary as part of the release.
• The entitlements plist file must grant read/write access to ~/.gnupg.

I think if we do those things, we can enable the sandbox.