Provide a higher-assurance way to install Sandstorm

[paulproteus]

One security-conscious person remarks it would be nice if, before running a shell script, it were possible to only install code that was verified with (e.g.) a GPG signature.

Here are the obstacles to that right now:

• We currently suggest in https://docs.sandstorm.io/en/latest/install/ that people install Meteor via curl | sh. Meteor is a Sandstorm compile-time dependency. A Sandstorm package in Debian experimental would presumably need to compile Meteor from source.
• We have no GPG signed tags. If we did, we could ask users to git checkout those tags and then verify them.

Some other thoughts:

• I have heard a concern that one Sandstorm user thinks their https connection could be compromised, perhaps through redirecting the domain's DNS to CloudFlare or someone compromising the CloudFlare account. By contrast, perhaps it's easier to keep a GPG signing key safe.
• "Pipe https to shell is never going to be secure" is one thing they said, even if we added HTTPS key pinning.
• They're fine with the easy install staying the way it is; they merely want an option for this.

[wtogami]

their https connection could be compromised,

Not only the user's https connection (through things like malware installing proxies and hostile CA's), but the entire domains being redirected to a hostile server and SSL cert, which is quite possible to do with only compromised e-mail.

"Pipe https to shell is never going to be secure" is one thing they said, even if we added HTTPS key pinning.

Shell will blindly run anything you pipe to it ... it isn't a browser with more sophisticated checks like HSTS.

They're fine with the easy install staying the way it is; they merely want an option for this.

While easy install is scary, I recognize the need to make it super fast and easy for protoyping and demos. I personally wouldn't worry about using easy install on a throwaway VM for evaluation. For a production deployment I would want to verify GPG signed git tags before running anything.

[paulproteus]

On IRC, @kentonv suggested:

• binary packages are signed using ed25519 for verifying updates
• install.sh contains and checks the hash of the package it plans to download (we update install.sh for each release
• we publish a signature of each install.sh using our GPG keys which can be verified by web of trust via the "verified install for nerds" link.

[wtogami]

GPG signed git tags too?

[paulproteus]

Ya, plus GPG-signed git tags.​

[glyph]

If we're going to talk about malware installing proxies and hostile CAs, I don't see how GPG helps with that threat model - can't the malware insert trusted GPG keys just as easily?

[paulproteus]

I think under a threat model of:

"Kenton's Nemesis calls up CloudFlare and convinces a customer support person to change what IP address sandstorm.io resolves to"

then GPG adds something that HTTPS does not provide. Glyph, let me know if you agree/disagree.

If you agree but think that's out of scope for Sandstorm, I think what we're saying on this issue is that we'd like it to be in-scope for Sandstorm, though not necessarily right this second.

@wtogami let me know if that's consistent with your understanding.

[glyph]

@paulproteus - I guess it really depends on where you get your GPG trust roots from.

[paulproteus]

In the case of @wtogami , I imagine he's checked my key personally, and he'll verify that my key signed the Sandstorm signing key.

Someone else could use the Debian keyring to get my key, and then do the same thing.

I think the general assumption in this threat model is that GPG trust roots come from a different connection than the compiled Sandstorm bundle.

[kentonv]

FWIW, keybase.io is doing a great job of making it possible to bootstrap PGP trust from popular sources. For https://keybase.io/kentonv to be a forgery, someone would have to have compromised not just CloudFlare but also Github and Twitter. In theory I could link my reddit and HN accounts there, too. Hopefully they'll eventually add Google, Facebook, etc.

With all that said, my business card also has my PGP key ID on it, so if you meet me in person, then you can bootstrap from that.

[glyph]

@kentonv - I'm a huge fan of keybase as well :). https://keybase.io/glyph

[glyph]

OK, so: the threat model here is that someone with the power to subvert an HTTPS CA (and your network, but we can take that as a given) is attempting to feed you some malware by rewriting https://install.sandstorm.io to be malware.

Our attacker does not have the opportunity to rewrite the keybase installer, because the user already has that installed a-priori, and the attacker does not have the capability to exploit the target machine with malware. However, it's worth noting that GPG itself, NPM (used to install keybase), and Keybase (distributed via NPM) all depend on HTTPS security for their integrity as well; long term compromises of HTTPS therefore make this somewhat moot. But, requiring the exploit to occur during initial install of keybase is a much smaller window of vulnerability.

On the provider side, you do:

keybase sign install.sh
scp install.sh.asc install.sandstorm.io:

On the installer side, you do:

curl -O https://install.sandstorm.io/install.sh.asc;
if keybase decrypt -S sandstorm -o tmp.txt; then
    mv tmp.txt install.sh;
    sh install.sh;
fi;

(The "decrypt" verb in keybase verifies and decodes signed unencrypted messages, as well as decrypting encrypted ones; the "verify" verb simply checks the signature but does not base64 decode the payload.)

That seems pretty heavyweight and is definitely error prone. For example, tmp.txt will happily contain an unverified copy of the installation script, which you could easily run by mistake if you don't watch $? carefully. If keybase had a slightly better command-line for this, you might be able to get this down to

curl https://install.sandstorm.io/install.sh.asc | keybase verify --output - --dont-output-unverified-plaintext -S sandstorm | bash

Would that be a satisfying way to do the installation?

[kentonv]

@glyph Oohhh, maybe we should ask Keybase to add a new command specifically for the purpose of replacing curl | sh.

keybase verify-run https://install.sandstorm.io/install.sh.asc

It would download the file, then look up the author in keybase, display verified info about them, prompt the user to decide if they find this acceptable, then run the file.

That'd be a neat answer to people who complain about curl | sh security.

[glyph]

@kentonv Surely you mean

keybase execute sandstorm https://install.sandstorm.io/ 

Meaning "run this, but only if it's signed by keybase.io/sandstorm".

In my humble but unassailably morally correct opinion, asking the user to make a decision, especially a yes/no decision, after they've specified some input is a recipe for disaster. For starters, it opens the door to things like Unicode homograph attacks. But more basically, as the designers of security software, we always believe the dialog box says:

Are you ABSOLUTELY SURE that the following line says "thing you expect"? If not, MAKE SURE to click DECLINE!

"thing you didn't expect": precise error code: DB0A4E76-10F0-4E9F-883E-E5C1B792F732

[Dangerously ACCEPT] ----- [Responsibly DECLINE]

but in reality - and we see this even as users of software - the dialog box actually says:

Blah blah BLAH BLAH BLAH, blah blah BLAH BLAH some stupid security thing, do you want to get on with your day?

Some Nonsense: DB0A4E76-10F0-4E9F-883E-E5C1B792F732

[Yes Absolutely Get On With My Day] ----- [No, Just Stop Working, I Guess I'll Go Outside]

So just making the user type "sandstorm" on the command line in advance of the URL makes them consciously select the source of trust, and treat failures as an error, as they should be (just like any other error, like "connection reset" or "host name lookup failed").

[glyph]

@kentonv I should add, though; other than this minor detail, that is a great idea.

[wtogami]

I'm seriously confused as to why you're suddenly excited about using a brand new tool, when the tools that existed for well over a decade are just fine.

[wtogami]

I also did not ask for ALL installs to be "higher-assurance", I only suggested that you provide a supported higher-assurance means of installing for those who care about security. The brain dead simple install method should remain as simple as possible.

[wtogami]

Furthermore, while this ticket is isolated to only installing Sandstorm itself in a secure manner, a later and more difficult task would be to verify everything that is downloaded by Sandstorm matches what the packager expects. This probably means committing hashes to the package definition, or verifying upstream GPG signatures, or both.

[glyph]

I'm seriously confused as to why you're suddenly excited about using a brand new tool, when the tools that existed for well over a decade are just fine.

They aren't just fine. If they were just fine, this site wouldn't exist.

[glyph]

I also did not ask for ALL installs to be "higher-assurance", I only suggested that you provide a supported higher-assurance means of installing for those who care about security. The brain dead simple install method should remain as simple as possible.

I wrote about why this is a bad idea earlier this year.

[glyph]

Furthermore, while this ticket is isolated to only installing Sandstorm itself in a secure manner

"in a secure manner" is a very misleading turn of phrase. The installation of sandstorm is already quite secure; the recommended instructions have https in the URL. Cryptography and everything! This is why I started talking about making the threat model for assurance here explicit. Unless the use-case here is just “some people think the letters ‘GPG’ are better than the letters ‘SSL’” in which case, okay, fine :).

[glyph]

And as long as I'm responding to stuff:

"Pipe https to shell is never going to be secure" is one thing they said, even if we added HTTPS key pinning.

Shell will blindly run anything you pipe to it ... it isn't a browser with more sophisticated checks like HSTS.

The problem here is that curl doesn't honor HSTS or pinning; that's not bash's job. It could; curl has everything it needs, except an HSTS database, to implement such a check. This is just a missing feature. But even if it were added, of course, it would fail open (retrieving the page anyway on older versions that don't have this feature). So if the command line were scurl ("secure curl") this would be fine. All we have to do is write it and wait 5 years for every distro to include it :).

[kentonv]

@glyph Please try to phrase your arguments in a way that doesn't sound like you think you're smarter than everyone else. Otherwise you're likely to create a needless flamewar. We're all security experts here, and I think we're all on the same side.

The reason I think it would be nice to show the user the verified identity after the command is because Keybase could print out verified Github, Twitter, etc. identities to help the user make their decision. Whereas if they're just copying the command from a web site, it's unlikely that the user will actually verify the username they're instructed to use, especially if it "sounds right". For example, say we registered "sandstorm" but someone else grabbed "sandstormio" and then managed to inject that name into install.html -- the user will probably trust it without looking it up. They're much more likely to see what the keybase client pushes in their face.

Homograph attacks are only an issue if Keybase allows non-ASCII usernames, which would surprise me; but if homograph attacks are an issue they're almost just as much of an issue either way because the user is likely to copy/paste the text, not type it on a keyboard.

But I suppose you could do both -- have them specify a name on the command-line and show them the attached identities and a prompt before accepting.

[kentonv]

@wtogami Keybase is a friendly wrapper around gpg, combined with a database of verified connections between that key and other social accounts, which is really useful for bootstrapping trust. If you'd prefer to use gpg directly, that will be entirely possible.

FWIW, I'm currently working on extending the package format to include a PGP signature, and I intend to extend the Sandstorm UI to use Keybase to tell you the author's "verified identity" at install time.

[glyph]

Please try to phrase your arguments in a way that doesn't sound like you think you're smarter than everyone else. Otherwise you're likely to create a needless flamewar. We're all security experts here, and I think we're all on the same side.

I'm sorry that I came across this way. I'm not sure what I said that did. Let me make it clear, then, that I have tremendous respect for everyone involved with Sandstorm generally, and specifically I am familiar with the work of every commenter on this issue and think it is all important stuff, and generally outside of my own capabilities. Obviously, I have strong feelings about this topic - but I also have a general willful ignorance of the actual cryptographic math involved and so I am always open to being told that I'm completely wrong.

[kentonv]

@glyph Cool, just wanted to cool things off a bit.

(I also am pretty ignorant when it comes to crypto math, BTW.)

[glyph]

@kentonv - Thanks for saying something rather than just being annoyed :). I know it is often uncomfortable to let people know they're being rude.

[glyph]

The reason I think it would be nice to show the user the verified identity after the command is because Keybase could print out verified Github, Twitter, etc. identities to help the user make their decision. (...)

This gets into a muddy area; if you can register a confusing username on Keybase, you can register a confusing one on Github and Twitter too. This is made even worse by the fact that sandstorm is already sandstorm-io on github and @SandstormIO on twitter and sandstorm.io on facebook; a little punctuation perturbation that was different from that and you could get something legit-looking surprisingly easily.

If the attacker controls the installation page, then they also control the "what to expect" part of the page, so if they manage to get one misleading social media presence, then they're all set. So, your proposal here is a lot more secure than mine... as long as the user brings additional context and expectations for what would be cross-signing that identity. Which I guess they probably will.

[glyph]

Homograph attacks are only an issue if Keybase allows non-ASCII usernames, which would surprise me;

I've never seen one, although I hope they do support them - there are lots of non-ASCII names out there :-.

but if homograph attacks are an issue they're almost just as much of an issue either way because the user is likely to copy/paste the text, not type it on a keyboard.

I think we have to assume that the user in this scenario isn't pasting stuff into a terminal from an untrusted web page, because if you do that you are already pwnt. So then the question is, how trusted is installation-instructions web page?

As @paulproteus pointed out in the initial description, the text that your browser is displaying to you is probably higher-assurance than the output of curl, because your browser can participate in HSTS and OCSP and all that jazz. Would it make sense to include a signing key fingerprint in that command somehow, to assume that the trust chain from text-in-my-browser is a bit stronger than the one to HTTPS-that-always-trusts-upstream-CAs?

[glyph]

But I suppose you could do both -- have them specify a name on the command-line and show them the attached identities and a prompt before accepting.

As I think a bit harder about the keybase trust model, and how the tool responds to various requests, it seems clear that they treat "identifier resolved via keybase.io HTTPS" and "tracked identifier that has been previously trusted" as very different things. And I think I was assuming that sandstorm would be the latter kind of thing, in the same way that you'd have to have the pubic key somehow already to usefully verify it.

For example, if I try to keybase encrypt somebody, it will do the retrieval and verification of proofs, but will then bail out because if somebody isn't someone I've previously tracked, it requires an interactive verification that it can't get.

So, one way for this to potentially work would be, you copy/paste keybase execute sandstormio ..., and then, on the first attempt, you get an error, because you have to keybase track sandstormio first. Then, the user is encouraged to type keybase track sandstormio rather than copy that command from the web page. And, more importantly, they only type that track command once as opposed to the execute command which they will presumably type multiple times, so the window of vulnerability keeps shrinking.

But this all leaves out any user who doesn't have keybase installed, and keybase itself is an invite-only, centralized service, so perhaps this wouldn't serve the largest base of users looking for more assurance…

[glyph]

Sorry for all the additional verbiage. I got really excited because I thought that this was a more limited problem, but it does seem that the more I think and write about it, the closer it gets to the perpetually intractable "solve PKI for everyone everywhere" issue, which I am not equipped to propose a complete solution to :-).

[paulproteus]

Hi @glyph and @wtogami ,

Does this work to address the issue?

• Visit https://sandstorm.io/install/
• See "PGP-verified install"
• Click "Read the docs"
• Visit https://docs.sandstorm.io/en/latest/install/#option-3-pgp-verified-install
• Follow GPG verification instructions

If so, then I am excited to close this issue. Let me know and/or close it if you're satisfied. Thanks!

[paulproteus]

UPDATE: Only I can close it, so I guess as the person who filed it, I will do so now. If others think it's not satisfactory, then please leave a comment and I can re-open.