Security concerns when running downloaded shell scripts

[ScaredyCat]

Please stop encouraging people to download and execute scripts directly, it's a horrific idea.

bash <(curl -Ss https://my-netdata.io/kickstart.sh)

[ktsaou]

Well, you are right, but I cannot do this, for the following reasons:

1. ideally installation should be taken care by the distros. However, the main distros fail to keep up to speed. It has been 2 years since the first release of netdata and still they haven't included it (there are exceptions, like arch linux and gentoo that added netdata almost in no time).

2. Before this one-liner, most tickets in this repo were about installation issues. This required a tremendous amount of work, helping users get through the installation procedure.

3. Such one-liners are extremely common - most commercial monitoring solutions provide similar instructions.

4. There are alternative ways of installing netdata - you are not forced to use this.

So, you are right, such one-lines are bad practice. But, we have to use them, mainly due to the amount of support required without them.

Keep in mind that I am seeking for help to setup PPAs or whatever else needed for installing binary packages on major distros #2728

[FedericoCeratto]

@ktsaou running an installer script is not wrong per se. The problem is encouraging users to run a file that can change at any time with no warning and/or cannot easily verified.
See for example https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/

You can deliver a file from a dedicated branch or repo on GitHub where people can easily check its history. The URL can point to a specific tag or commitish.

[ktsaou]

So, you say we should just change the URL to point to github?

[FedericoCeratto]

Users already have to trust GitHub security when pulling the sources and getting install instructions from the wiki.
At least, using:

curl -sS https://raw.githubusercontent.com/firehol/netdata/e8915e26537615282003d6baf094d59712c9b4f1/kickstart.sh -o kickstart.sh

...they are a "known" file from a known location.

GPG-signing tarballs and the kickstart script would be another improvement.

[paulfantom]

So instead of

bash <(curl -Ss my-netdata.io/kickstart.sh)

use

curl -sS https://raw.githubusercontent.com/firehol/netdata/master/kickstart.sh | bash
or
bash <(curl -Ss https://raw.githubusercontent.com/firehol/netdata/master/kickstart.sh)

?

As for GPG signing tarball, I don't think I know any project which does that. SHA checksum is common but GPG - not so much.

[ktsaou]

curl -sS https://raw.githubusercontent.com/firehol/netdata/master/kickstart.sh | bash

This removes stdin from bash, so the script cannot have user input.

As for GPG signing tarball, I don't think I know any project which does that. SHA checksum is common but GPG - not so much

So, how this will work? The script will check itself with a signature it downloads from the server?
I don't see any value to it.

The only possible solution would be to instruct the users the check the signature of the script before running it, but this would require to save the script and the signature and check the downloaded files with an extra command you will run.

[Ferroin]

@paulfantom GPG signing of releases isn't as rare as you might think, it's just that most of the cases that do it have automated verification support (for example, Gentoo signs released portage tree snapshots, and the package manager provides native verification support). The only big one I know of that doesn't provide some form of automated verification is the Linux kernel itself (they GPG sign release tarballs, though they use detached signatures so that only people who care have to deal with the signatures).

@ktsaou ou is right though, there's essentially no value in having the script check signatures, because the script is where the trust issue is to begin with.

[paulfantom]

I wasn't clear enough. I know about GPG checking of packages from repositories (apt, yum, and almost every package manager does it), problem is that we are not releasing package to the repository. We are releasing tarballs. And I meant projects which do the same, when saying that "I don't think I know any project which does that". However seems that linux kernel will go into that category, so that's one 😄

Sorry for not being clear on that.

As for installation method, let's just provide a file with sha control sums for installer script and packages from released assets. This way if someone wants to verify package he/she could do it. Otherwise point people to simple installation script as more people want convenience over security.