Чи є оболонка, яка перевіряє, щоб переконатися, що код підписаний?

На цьому тижні я зіпсувався з PowerShell і виявив, що вам потрібно підписати сценарії, щоб їх можна було запустити. Чи є в Linux подібний захищений функціонал, який стосується запобігання запуску bash-скриптів?

Єдиний функціонал, подібний до цього, про який я знаю, - це функція SSH, яка потребує певного ключа.

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

Якщо ім'я команди з префіксом Digest_Spec, команда буде успішно збігатися, лише якщо її можна перевірити, використовуючи вказаний дайджест SHA-2. Це може бути корисно в ситуаціях, коли користувач, який викликає sudo, має доступ до запису до команди або до його батьківського каталогу. Підтримуються наступні формати дайджесту: sha224, sha256, sha384 та sha512. Рядок може бути визначений у шістнадцятковому або базовому форматі (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: дистрибуція програмного забезпечення є однією з основних точок розмежування дистрибутивів) і підписана ключем постачальника. Дистрибутиви 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шарі, ми можемо його обійти, запустивши лише інтерпретатор із сценарієм як параметр.

Це означає, що код підписання повинен був бути в самому перекладачі. І що заважає користувачу збирати власну копію оболонки без підпису коду примусового виконання?

Стандартним рішенням цього є не використання підпису, а використання обов'язкового контролю доступу (MAC), такого як SELinux. За допомогою систем MAC можна точно вказати, що кожному користувачеві дозволено запускати та переходити шари. Так, наприклад, ви можете сказати, що "звичайні користувачі можуть запускати все, окрім веб-сервера та процесів CGI можуть отримати доступ лише до матеріалів із /var/httpdкаталогу; все інше відхилено".

У дистрибутивах Linux зазвичай є gnupg . Мені здається, що все, що вам потрібно, - це проста баш-обгортка, яка перевіряє відокремлений 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 запустити виконуваний файл з виконуваним набором бітів, який було завантажено з Інтернету, навіть якщо ви копіюєте та переміщуєте файл. Можна додати правило, що такі файли можна запускати лише через інший двійковий файл, який би перевіряв підпис, не на відміну від того, що ви згадували у своєму запитанні.

Отже, врешті-решт, це питання конфігурації загальновстановлених інструментів, і відповідь - так .