How the trust chain works

In a recent article, “VPN to every home,” it is proposed to do a tremendous folly, namely, go to your VPS and enter this:
')

curl -sS https://sockeye.cc/instavpn.sh | sudo bash 

As I wrote in the commentary to that article, this is a very big folly. You blindly run the code from the Internet, which you have not even seen, and even then it does not matter from under sudo or not.

The main reasons are as follows:

• You teach yourself that you can do this. This is the biggest problem here, and you can compare such an action with the user who opens the executable file from the incoming letter. On the consequences of such actions, we all know well on the huge botnets on Windows, as well as all sorts of leaked private data.
• You do not check the checksums and thus cannot say whether you are launching what you think you are running. The script can be replaced by a large number of methods, including substitution of a record in the DNS by the provider, as this week was with the github, hacking the site from which you are downloading, etc.
• You do not use long-term practice to use checksums to verify running code, which is one of the main reasons for the relatively high security of UNIX and the like.

To understand, consider the correct way to install programs, first in general:

• You are looking for information about the author, and are trying to understand whether you can trust him. Such information is usually found even about the authors of small programs.
• Download your program, it does not matter in what form, a package, an archive or an iso image.
• Consider with sha256sum (or at least md5sum) the checksum of what you downloaded.
• Go to the developer's website and see if what you counted is the same as what is written there.
• You drive a checksum into Google and find another source.
• You are convinced that most likely you downloaded exactly what the author of the program wanted to give you.
• Now you have sufficient reason to install a software package and not worry too much .

Again. Absolutely all security is built on your trust in certain people or companies, be it Linus Torvalds, the Ubuntu Security Team, or the author of a small useful utility. You need to make sure that 1. the author is trustworthy, and 2. you run what the author has posted.

Now consider the application of the above method for example, installing Ubuntu Desktop 14.04.01. Absolutely the same method is used when installing everything else, only you do not download a disk image, but, for example, an archive.

• Canonical is a relatively well-known company, you can be cautiously trusted. You can always trust only with caution.
• You download the disk image from any mirror: wget whatever / ubuntu-14.04.1-desktop-amd64.iso It doesn’t matter if the mirror is cracked or the connection is secure.
• Next, consider the checksum, they do not have sha256 on the site, so md5 will go: "md5sum ubuntu-14.04.1-desktop-amd64.iso"
• Go to their website and see this “ help.ubuntu.com/community/UbuntuHashes ”. All right, the checksum matched.
• Looking for this checksum in google. At a minimum, make sure that it is the same on other mirrors, ideally find the Canonical mailing list in which it is mentioned.
• Now you are convinced that the downloaded image is not fake, and you can install it.

Now let's look at how the batch manager works with the example of apt-get:

• When you install the system you have already configured some repositories.
• In these repositories there are files with a list of all the packages and their checksums.
• These files are in turn signed by the developers' private key.
• After installation the public key is already sewn into the distribution kit.
• Thus, when you install a new package, you download the corresponding list of all packages (if there was an update in the repository), then the package itself, and you can be sure that the trust chain will be traced: {package checksum} - {list of packages with checksums} - {signature by the private key of the package list} - {the public key entered into your distribution package} .

As you can see, verification happens at all levels. There is no unsigned executable code in your system. In cases similar to those described in a recent article, all these checks are not performed. You have no reason to trust such a code. Therefore, the rule is:

Never run incomprehensible code from the Internet! Either independently make sure that it is safe, or make sure that the author can be trusted, and this is his code. If you do not have enough knowledge to check the code yourself, use only official repositories, there is a special team of specialists who try (and usually she is good at it) to do it for you.

Addition. The only correct way to open access to samopisnymi control panels from the Internet

In a web application, many elements may be vulnerable, the most vulnerable of which is, of course, the code of the application itself. To minimize risks, use http basic authentication with https . This way you shift vulnerability concerns onto the powerful shoulders of the web server.

Understandably, this only works if it’s an internal site; end users need more convenient ways to log in. But samopisnye control panels and other tools are usually designed for internal use and intended.

Offtop. The problem.

Attention! Do not do it on your working machine or server, it will break!
The problem is simply formulated, I assume you have a 64-bit system:

 chmod -x /lib64/ld-linux-x86-64.so.2 

There are several solutions; in the most difficult case, you have no loopholes. I will not specify not to help with the decision.

UPD: The problem is solved in the comments by the person with the login kay , I do not give a solution in case you want to break the brain yourself.

UPD2: As amarao correctly noted, if you don’t understand exactly what you are doing, use only official repositories.