Secure architecture for updating in a sandboxed environment

[kornelski]

🔥 Here's the new implementation that will be Sparkle 2.0: https://github.com/sparkle-project/Sparkle/tree/ui-separation-and-xpc 🔥 It implements the changes discussed in the issue below.

---

There has been a very old branch with a sandbox support, but Andy has rejected it due to unresolved security issues.

So I'm opening an issue here to start a discussion how we can support sandboxed applications in Sparkle while keeping the sandbox as tight as possible.

I think minimal requirements are:

• The XPC helper must not trust the host app at all, so it must verify integrity of downloaded update and unpack it by itself. The current approach of telling XPC helper "hey, install this path, I've unpacked it and checked it's ok" can't be secure.
• the XPC can't trust the host to supply a valid DSA key (a compromised host could give a valid and signed update, but signed by the wrong person). The XPC helper must find the trusted DSA key by itself (i.e. find the app's path and read Info.plist from there) and refuse to update any other path.
• Apple Code Signing verification code needs to be refactored (or not supported in sandboxed environment), because the host app checks against its own signature, but the host app is not supposed to be doing the checking.

[fernandomorgan]

Hi, updating my status - so, I do have a fork working since May or so, but I am still waiting the legal department ok to publish it.

I don't think it is in finished in terms of having completely addressing Andy's requirements BUT it does at least code signing validation in the XPC copy process.

I am mailing legal today - I do need to write a small doc about the changes, so I share the blame of the lateness - but I probably won't get an answer until tomorrow (California time), and then I will update this item.

I have distributed around 10 updates or so to around 1000 users, mostly in 10.9. There is a very small percentage in 10.8 and only test machines in 10.7. For a smaller group of 20-30 people I send around 5+ upgrades every day (our dev team, etc).

[SevenBits]

@fernandomorgan That's great! Look forward to hearing more on this!

[fernandomorgan]

Ok, here is the first release - I used a fork from your repo, Pornel

https://github.com/yahoo/Sparkle

[SevenBits]

@fernandomorgan Could you perhaps include documentation on how to set it up? Are any special steps required to get it to work with sandboxing?

[fernandomorgan]

actually you don't need to do anything. If your app isn't sandboxed, it uses the old copy. If the app is sandboxed, it will use a XPC helper - com.yahoo.Sparkle.SandboxService.xpc

I will add a note on distributing this helper

[jakepetroules]

@fernandomorgan Can you rebase on the latest master and send us a pull request please?

[fernandomorgan]

Somewhere, somehow, I guess some git info from the old Pornells fork was lost.

[kornelski]

I'll rebase it, don't worry

[fernandomorgan]

great! thanks

[kornelski]

The yahooxpc branch is ready for review.

Due to recent massive reorganization of the repository (sigh) it wasn't easy to merge and there are some messy merge conflicts/regressions, but at least we can start reviewing security of it and test it on top of the codebase.

[jakepetroules]

Are you sure you pushed? It looks like it's still 32 commits behind master.

[kornelski]

ok, 32 more

[jakepetroules]

OK, I've fixed this up enough that it actually builds. Some things might have been lost during your merging, Xcode complains of a missing implementation for a method in SUUpdater. Probably should compare diffs manually to look things over.

[kornelski]

Ah, yes. I've been brutally skipping over conflicting bits that didn't seem worth pulling out, e.g. log statements, 10.4 support.

One notable thing I've skipped was support for JSON appcasts. While JSON is fashionable, I don't think it solves enough problems, also xkcd-927.