Secure Package Installation

mike-stewart commented 6 years ago

Description

Fixes sensu/sensu-chef/issues/578. This secures the package installation against MITM attacks for linux by downloading the GPG key over HTTPS.

I didn't change the linux repo URLs themselves as there is generally less benefit in downloading the packages over HTTPS given GPG checks. It requires an additional package in some cases, and it can get in the way of caching.

For Windows, I changed the package URL, as I'm not aware of a method to check package signatures there.

Motivation and Context

See sensu/sensu-chef#578.

How Has This Been Tested?

Executed tests.

Screenshots (if appropriate):

Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.

mike-stewart commented 6 years ago

@majormoses We shouldn't actually need to install apt-transport-https here - as I mentioned in the description of the PR the difference is that we're not installing the package itself over HTTPS, we're just fetching the GPG key. The package can be downloaded securely over HTTP if it's signed with a GPG key that we can trust.

I've confirmed this through a manual test on Ubuntu 16.04. With apt-transport-https not installed, I can fetch the key over HTTPS, add the repo, and install the package.

Let me know if this makes sense. I can dig into the test suite more later to try to prove this if necessary.

majormoses commented 6 years ago

@mike-stewart gotcha I read the title and the code and after seeing #594 I assumed it was the same deal. :+1: on merging whether we switch over later and agree that a pgp signed artifact is good enough if you download the key over https/ssl. One concern I have about eventually needing to support it down the road is that at some overzealous admin might redirect http -> https. But we can worry about that later.

Let me know if this makes sense. I can dig into the test suite more later to try to prove this if necessary.

Nope I got you, I will run it through the test suites this weekend and if it looks good I will merge and release this before monday.

I won't pretend to know much about windows but from what I read we should be good to use https.

mike-stewart commented 6 years ago

Sounds great. I hadn't noticed #594, but that would have some advantages as well. I decided to go with the least change required to get good security.

From what I've read about apt, it's typically best from a compatibility perspective to allow package download over HTTP, as that doesn't break environments that use caching proxies for distributing packages.

majormoses commented 6 years ago

Validated this looks good with linux, the windows vagrant failed because of other reasons:

---- Begin output of vagrant up --no-provision --provider virtualbox ----
STDOUT: Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'mwrock/Windows2012R2' could not be found. Attempting to find and install...
    default: Box Provider: virtualbox
    default: Box Version: >= 0
STDERR: The box 'mwrock/Windows2012R2' could not be found or
could not be accessed in the remote catalog. If this is a private
box on HashiCorp's Atlas, please verify you're logged in via
`vagrant login`. Also, please double-check the name. The expanded
URL and error message are shown below:

URL: ["https://atlas.hashicorp.com/mwrock/Windows2012R2"]
Error: The requested URL returned error: 404 Not Found

I say :shipit:

majormoses commented 6 years ago

released: https://supermarket.chef.io/cookbooks/sensu/versions/4.2.1

sensu / sensu-chef