Подписанный скрипт в Linux?

На этой неделе я возился с PowerShell и обнаружил, что вам необходимо подписать свои сценарии, чтобы они могли запускаться. Есть ли в Linux аналогичные безопасные функции, которые связаны с предотвращением запуска сценариев bash?

Единственная функциональность, подобная этой, которую я знаю, – это SSH, требующая определенного ключа.

8 Solutions collect form web for “Подписанный скрипт в Linux?”

Если вы блокируете способность пользователей запускать скрипты через sudo вы можете использовать функцию digest .
Вы можете указать хэш скрипта / исполняемого файла в sudoers который будет проверен sudo перед выполнением. Таким образом, хотя это и не то же самое, что и подписание, оно дает вам основную гарантию того, что сценарий, по крайней мере, не был изменен без изменения sudoers.

Если имя команды имеет префикс Digest_Spec, команда будет успешно соответствовать только в том случае, если ее можно проверить, используя указанный SHA-2 дайджест. Это может быть полезно в ситуациях, когда пользователь, вызывающий sudo, имеет доступ на запись к команде или ее родительскому каталогу. Поддерживаются следующие форматы дайджеста: sha224, sha256, sha384 и sha512. Строка может быть указана в формате hex или base64 (base64 более компактен). Существует несколько утилит, способных генерировать дайджесты SHA-2 в шестнадцатеричном формате, такие как openssl, shasum, sha224sum, sha256sum, sha384sum, sha512sum.

http://www.sudo.ws/man/1.8.13/sudoers.man.html

Да и нет.

Распределение программного обеспечения Linux работает несколько иначе, чем дистрибутив программного обеспечения Windows. В мире (не внедренном) Linux основным методом распространения программного обеспечения является распространение (Ubuntu, Debian, RHEL, Fedora, Arch и т. Д.). Все основные дистрибутивы систематически подписывают свои пакеты примерно на десятилетие.

Когда программное обеспечение распространяется независимо друг от друга, поставщик должен решить, как они будут отправлять свое программное обеспечение. Хорошие поставщики предоставляют источники пакетов, которые совместимы с основными дистрибутивами (нет единого механизма распространения для всей Linux: распространение программного обеспечения является одним из основных моментов дифференциации между дистрибутивами) и которые подписаны с ключом поставщика. Линукс-дистрибутивы редко выступают в качестве авторитета для подписчиков сторонних поставщиков (Canonical делает это с партнерами Ubuntu, но это касается очень немногих поставщиков), и я думаю, что все основные дистрибутивы используют сеть доверия PGP, а не инфраструктуру открытого ключа TLS, поэтому это зависит от пользователя, чтобы выяснить, хотят ли они доверять ключу.

Не существует специального механизма, который выделяет программные пакеты, которые состоят из одного сценария из пакетов программного обеспечения, которые состоят из собственного исполняемого файла, файла данных или нескольких файлов. Также никакая проверка подписи не встроена в какой-либо обычный интерпретатор сценариев, поскольку проверка программного пакета является полностью ортогональной задачей запуска скрипта.

Я думаю, что Windows аннотирует файлы с их началом и требует подтверждения пользователя для запуска файла, происхождение которого «скачено», а не «локально». У Linux действительно нет подобного механизма. Самое близкое – разрешение на выполнение: загруженный файл не имеет разрешения на выполнение, пользователю необходимо явно включить его ( chmod +x в командной строке или эквивалентное действие в файловом менеджере).

Linux не предоставляет возможности ограничить выполнение сценариев bash на основе цифровых подписей.

Существует некоторая работа по аутентификации двоичных исполняемых файлов. См. https://lwn.net/Articles/488906/ для информации.

Одним словом, «нет».

Linux не делает различий между исполняемыми файлами и сценариями; #! в начале это способ рассказать ядру, какую программу запускать для оценки ввода, но это не единственный способ выполнения сценария.

Так, например, если у меня есть скрипт

 $ cat x #!/bin/sh echo hello 

Тогда я могу запустить это с помощью команды

 $ ./x 

Это заставит ядро ​​попытаться выполнить его, назовите #! а затем эффективно запустить /bin/sh x .

Однако я мог бы также запустить любой из этих вариантов:

 $ sh ./x $ bash ./x $ cat x | sh $ cat x | bash $ sh < x 

или даже

 . ./x 

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

Это означает, что код подписи должен быть в самом интерпретаторе. И что может помешать пользователю скомпилировать собственную копию оболочки без кода принудительного подписания?

Стандартным решением для этого является не использование подписи, а использование Mandatory Access Controls (MAC), например SELinux . В системах MAC вы можете точно указать, что каждому пользователю разрешено запускать и переходить на уровни. Так, например, вы можете сказать, что «обычные пользователи могут запускать что угодно, но веб-сервер и процессы CGI могут обращаться к материалам только из каталога /var/httpd а все остальное отклонено».

У дистрибутивов Linux обычно есть gnupg . Мне кажется, что все, что вам нужно, это простая оболочка bash, которая проверяет выделенную подпись gpg на скрипт аргумента и только начинает запускать скрипт, если проверка завершается успешно:

 #!/bin/sh gpgv2 $1.asc && bash "$@" 

Контр-вопрос, который приходит на ум сразу: «Почему вы когда-либо хотели запретить пользователям запускать программы, которые они написали? » Существует несколько возможностей:

  1. В буквальном смысле невозможно определить, кто автор кода в первую очередь. Владелец файла сценария – это тот, кто фактически сохранил содержимое этого файла, независимо от того, откуда он появился. Таким образом, применение подписи – просто сложная замена диалогового окна подтверждения: «Вы уверены, что хотите это сделать?» В Linux часть этой проблемы решена прозрачно с подписанными пакетами и смягчается тем фактом, что пользователи имеют ограниченный доступ по умолчанию. Пользователь также должен знать, что запуск кода других может быть опасным *.
  2. В том же ключе подписание сценария – гораздо более сложная операция, чем сохранение файла. В лучшем случае это побуждает пользователя понять, что они выполняют действие, подобное подписанию документа, и должны проверить, что он говорит, прежде чем продолжить. Скорее всего, это просто обеспечивает минимальный уровень технического мастерства со стороны пользователя, позволяющего запускать сценарий. В худшем случае он демонстрирует готовность перепрыгнуть через длинную серию обручей, чтобы запустить то, что они хотели. Техническое знание предполагается на Linux *.
  3. Скорее всего, люди будут обнаруживать явно вредоносный код при вводе / вставке серии команд в свою командную строку. Фрагментированные фрагменты, предназначенные для копирования и вставки, обычно меньше, чем серия команд, необходимых для выполнения чего-то должного гнусного. Пользователь также может тщательно копировать и вставлять каждую строку отдельно, понимая, что происходит, когда это происходит. С помощью сценария, возможно, пользователь никогда не смотрел на код вообще. Это может быть полезным приложением подписанных скриптов при слишком частой стоимости самоуспокоенности после 12-го раз, когда вы должны это делать.

* Это, вероятно, становится все меньше и меньше, поскольку все больше людей начинают использовать Linux

Причина, по которой системы эволюционировали по-разному, заключается в том, что Linux имеет атрибут файла «exec», а Windows использует расширения файлов для определения исполняемости.

Поэтому в Windows легко обмануть пользователя при загрузке файла с расширением «.exe», «.bat», «.scr», которое по умолчанию будет скрыто . Двойной щелчок по этому файлу даст вам произвольный код. Следовательно, для смягчения этого риска был создан большой механизм отслеживания происхождения и подписания сценария / сценария.

В Linux вы можете получить файл для пользователя, но вы не можете легко заставить бит «exec» быть установленным. Кроме того, возможно создание целых файловых систем noexec.

Вы можете в любом случае запустить сценарий явно, вызвав интерпретатор. Вы даже можете создавать сценарии оболочки во время выполнения и транслировать их в «sh» или запускать «sh -c».

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

Дело в том, что было описано в другом ответе, что отсутствие бит выполнения не мешает вам передавать такой скрипт непосредственно в bash . Хотя можно утверждать, что большинство таких скриптов являются скриптами bash , shebang может указать любую программу в качестве интерпретатора. Это означает, что пользователь должен запустить соответствующий интерпретатор, если они решили игнорировать исполняемую семантику.

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

Как я уже упоминал в одном из комментариев, есть еще один уровень защиты – SeLinux – который отслеживает происхождение файлов на основе набора правил. Настройка SeLinux не позволит, например, разрешить root запускать исполняемый файл с исполняемым битовым набором, который был загружен из Интернета, даже если вы копируете и перемещаете файл. Можно добавить правило, что такие файлы можно запускать только через другой двоичный файл, который будет проверять подпись, в отличие от того, что вы упомянули в своем вопросе.

Итак, в конце концов, это вопрос конфигурации обычно предустановленных инструментов, и ответ да .

  • Переименование пакетного файла с использованием файла сопоставления
  • Объедините несколько файлов на основе md5sum
  • Уведомление программы о завершении сеанса X
  • Как эта команда find использует «find ... -exec sh -c» ... «sh {} +» работает?
  • Выполнить команду при входе пользователя в систему
  • Удалите все файлы в каталогах, кроме тех, чей путь указан в файле
  • переименование нескольких файлов приращения порядка
  • Переименование файлов и переход на другой путь
  • Проводят вывод команды в переменную в кубе awk-скрипта
  • Выполнение команды по многим файлам
  • Попытка конвертировать простую программу C в программу AWK
  • Linux и Unix - лучшая ОС в мире.