Как работает цепочка доверия

В недавней статье «VPN в каждый дом» предлагается сделать огромную глупость, а именно пойти к себе на VPS и ввести там вот это:

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

Как я в комментарии к той статье написал, это очень большая глупость. Вы вслепую запускаете код из интернета, который вы даже не видели, и тут даже совершенно неважно из под sudo или нет.

Основные причины следующие:

Вы приучаете себя к тому, что так делать можно. Это самая большая здесь проблема, и сравнить такое действие можно с пользователем который открывает исполняемый файл из пришедшего ему письма. О последствиях таких действий мы все отлично знаем по огромным ботнетам на Windows, а также разного рода утекших приватных данных.
Вы не проверяете контрольные суммы и таким образом не можете сказать, запускаете ли вы то, что вы думаете что вы запускаете. Скрипт может быть подменен большим количеством способов, включая подмену записи в DNS провайдером, как на этой неделе было с гитхабом, взлом сайта с которого производится скачивание, и т.д.
Вы не пользуетесь многолетней практикой использовать контрольные суммы для верификации запускаемого кода, которая является одной из основных причин относительно высокой безопасности UNIX и подобных.

Чтобы разобраться, рассмотрим правильный способ установки программ, сначала в общем виде:

Вы ищете информацию про автора, и пытаетесь понять можно ли ему доверять. Такая информация обычно находится даже про авторов небольших программ.
Скачиваете вашу программу, тут неважно в каком виде, пакет это, архив или образ iso.
Считаете с помощью sha256sum (или хотя бы md5sum) контрольную сумму того, что вы скачали.
Идете на сайт разработчика и смотрите, совпадает ли то, что вы насчитали, с тем, что написано там.
Вбиваете контрольную сумму в гугл и находите другой источник.
Убеждаетесь в том, что скорее всего вы скачали именно то, что хотел вам предоставить автор программы.
Теперь у вас есть достаточное основание для того, чтобы ставить программный пакет и не слишком сильно переживать.

Еще раз. Абсолютно вся безопасность построена на вашем доверии к определенным людям или компаниям, будь это Линус Торвальдс, Ubuntu Security Team либо автор маленькой полезной утилиты. Вам необходимо убедиться в том, что 1. автор заслуживает доверия, и 2. вы запускаете то, что выложил автор.

Теперь рассмотрим применение вышеописанного метода на примере установки Ubuntu Desktop 14.04.01. Абсолютно такой же способ применяется при установке всего остального, только скачиваете вы не образ диска а, например, архив.

Canonical относительно известная компания, можно с опаской доверять. Доверять всегда можно только с опаской.
Вы скачиваете образ диска с любого зеркала: wget whatever/ubuntu-14.04.1-desktop-amd64.iso При этом совершенно не важно, взломано ли зеркало или защищенное ли соединение.
Далее считаете контрольную сумму, sha256 у них на сайте нет, поэтому пойдет md5: «md5sum ubuntu-14.04.1-desktop-amd64.iso»
Идете к ним на сайт и видите вот это «help.ubuntu.com/community/UbuntuHashes». Все в порядке, контрольная сумма совпала.
Ищете эту контрольную сумму в гугле. Как минимум убеждаетесь, что на других зеркалах она такая же, в идеале находите почтовую рассылку Canonical, в которой она упоминается.
Теперь вы убедились, что скаченный образ не подделка, и можете его ставить.

Теперь рассмотрим, как работает пакетный менеджер на примере apt-get:

При установке системы у вас уже настроены некоторые репозитории.
В этих репозиторих есть файлы со списком всех пакетов и их контрольными суммами.
Эти файлы в свою очередь подписаны закрытым ключом разработчиков.
В дистрибутив после установки уже вшит открытый ключ.
Таким образом, когда вы ставите новый пакет, вы скачиваете соответствующий ему списков всех пакетов (если в репозитории было обновление), потом сам пакет, и можете быть уверены, что цепочка доверия будут прослежена: {контрольная сумма пакета}--{список пакетов с контрольными суммами}--{подпись закрытым ключом списка пакетов}-{вшитый в ваш дистрибутив открытый ключ}.

Как вы можете видеть, проверка происходит на всех уровнях. Никакого неподписанного исполняемого кода в вашу систему не пролезет. В случаях же, подобных описанным в недавней статье, все эти проверки не выполняются. Никакого основания такому коду доверять у вас нет. Поэтому, правило:

Никогда не запускайте непонятный код из интернета! Либо самостоятельно убедись в том, что он безопасен, либо убедитесь в том, что автору можно доверять, и это именно его код. Если у вас недостаточно знаний, чтобы проверить код самостоятельно, используйте только официальные репозитории, там есть специальная команда специалистов, которая старается (и обычно у нее хорошо получается) делать это за вас.

Дополнение. Единственно правильный способ открывать доступ к самописным панелям управления из интернета

В веб-приложении много элементов может быть подвержено уязвимости, самый уязвимый из них это, конечно же, код самого приложения. Для минимизации рисков используйте http basic authentication по https. Таким образом вы перекладываете заботу об уязвимостях на могучие плечи веб-сервера.

Понятное дело, это работает только если это внутренний сайт, конечным пользователям нужны более удобные способы входа. Но самописные панели управления и другие инструменты обычно именно для внутреннего употребления и предназначены.

Оффтоп. Задачка.

Внимание! Не делайте этого на вашей рабочей машине или сервере, поломается!
Задачка просто формулируется, предполагаю у вас 64-х битную систему:

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

Решений несколько, в самом сложном случае никаких лазеек у вас нет. Не буду уточнять, чтобы не помогать с решением.

UPD: Задачка решена в комментариях человеком с логином kay, решение не привожу на случай, если вам хочется поломать мозг самостоятельно.