У нас є невелика проблема на сервері. Ми хочемо, щоб деякі користувачі мали змогу це зробити, наприклад, sudoі стати root, але з тим обмеженням, що користувач не може змінити пароль root. Тобто, це гарантія того, що ми все ще можемо увійти на цей сервер і стати root, незалежно від того, що робитимуть інші користувачі.

Це можливо?

Ми хочемо, щоб деякі користувачі мали змогу це зробити, наприклад, sudoі стати root,

Ну, ось цю проблему судо покликаний вирішити, тому ця частина досить проста.

але з обмеженням, що користувач не може змінити пароль root.

Ви можете, як SHW вказував у коментарі, налаштувати sudo лише для того, щоб певні користувачі могли взяти за основу певні дії. Тобто, ви можете дозволити user1 зробити sudo services apache2 restart, дозволяють user2 робити , sudo rebootале нічого іншого, дозволяючи при цьому найманий-як-система-адміністратор user3зробити sudo -i. Існують способи, як налаштувати подібне sudo, або ви можете шукати (або запитувати) тут. Це є вирішуваною проблемою.

Однак користувач, якому надана можливість sudo -iабо sudoв оболонку ( sudo bashнаприклад), може робити все, що завгодно. Це тому, що до того часу, як судо запустить оболонку, саме судо не виходить із картини. Він надає контекст безпеки іншого користувача (найчастіше кореневого), але не має жодного слова в тому, що робить виконана програма. Якщо ця програма по черзі запускається passwd root, судо нічого з цим не може зробити. Зауважте, що це можна зробити і через інші програми; Наприклад, багато більш досконалих редакторів надають засоби для виконання команди через оболонку, оболонка якої буде виконана за допомогою ефективного uid цього редакторського процесу (тобто root).

Тобто, це гарантія того, що ми все-таки можемо увійти на цей сервер і стати root незалежно від того, що робитимуть інші користувачі.

Вибачте; якщо ви дійсно означаєте, "переконайтеся, що ми зможемо увійти та використовувати систему незалежно від того, що робить хтось із кореневим доступом до неї", це (для всіх намірів і цілей) зробити не можна. Швидкий "sudo rm / etc / passwd" або "sudo chmod -x / bin / bash" (або будь-який інший корінь оболонки), і ви все одно сильно шлангували. "Досить сильно шланг", що означає "вам потрібно буде відновити з резервного копіювання і сподіваюся, що вони не зробили нічого гіршого, ніж промацування пальців". Ви можете вжити певних заходів, щоб знизити ризик випадкових випадкових випадків, що призводять до непридатної системи, але ви не можете запобігти зловмисню викликати дуже серйозні проблеми аж до того, що потрібно відновити систему з нуля або принаймні з відомих хороші резервні копії.

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

Обмежений доступ до кореня через напр. Sudo є трохи кращим, але ви все ж повинні бути обережними, щоб не відкрити жодних векторів нападу. І з кореневим доступом існує безліч можливих векторів атак для атак ескалації привілеїв.

Якщо ви не можете довіряти їм рівень доступу, який спричиняє root, вам знадобиться або дуже затягнута конфігурація sudo, або просто не надавати користувачеві, про який йдеться, кореневий доступ будь-якими засобами, sudo чи іншим способом.

Це практично неможливо. Перш за все, якщо ви наділите їх владою стати корінними , то ви нічого не можете зробити, щоб завадити їм щось робити. У вашому випадку використання, sudoслід використовувати для надання вашим користувачам деяких кореневих повноважень, обмежуючи інших, не дозволяючи їм стати root .

У вашому випадку, вам необхідно буде обмежити доступ до suі passwdкомандам і відкритий доступ до досить багато всього іншого. Проблема полягає в тому, що ви нічого не можете зробити для того, щоб ваші користувачі не могли безпосередньо редагувати /etc/shadow(або /etc/sudoersз цього приводу) редагувати і не впадати в пароль замінного корінця для викрадення root. І це лише найпростіший можливий сценарій "атаки". Судери з необмеженою потужністю, за винятком однієї або двох команд, можуть обійти обмеження щодо викрадення повного кореневого доступу.

Єдине рішення, запропоноване SHW в коментарях, - використовувати, sudoщоб надати своїм користувачам доступ до обмеженого набору команд.

Оновлення

Можливо, є спосіб досягти цього, якщо ви використовуєте квитки Kerberos для аутентифікації. Прочитайте цей документ, що пояснює використання .k5loginфайлу.

Я цитую відповідні частини:

Припустимо, користувач alice мав у своєму домашньому каталозі файл .k5login, що містить такий рядок:
bob@FOOBAR.ORG
Це дозволить bob використовувати мережеві додатки Kerberos, такі як ssh (1), для доступу до облікового запису Аліси, використовуючи квитки Kerbros на бобі .
...
Зауважте, що оскільки боб зберігає квитки на Kerberos за власного директора, bob@FOOBAR.ORGвін не матиме жодних привілеїв, які вимагають квитки Аліси, наприклад, кореневий доступ до будь-якого з хостів сайту або можливість змінити пароль Аліси.

Я, можливо, помиляюся. Я до сих пір переглядаю документацію і ще маю випробувати Керберос на собі.

Я припускаю, що ви хочете переконатися, що у вас є доступ до "адміністратора надзвичайних ситуацій", навіть якщо ваш фактичний адміністратор накрутив (але крім цього, ви повністю довіряєте головному адміністратору).

Популярний підхід (хоча і дуже хакітний) полягає у тому, щоб мати другого користувачаuid=0 , який зазвичай називається toor(корінь назад). Він має інший пароль і може служити резервним доступом. Щоб додати, вам, ймовірно, потрібно буде відредагувати /etc/passwdта /etc/shadow(скопіювати rootрядки).

Це все, крім відмов, але якщо вам просто потрібно захиститись від "головного адміністратора", змінивши пароль без попереднього повідомлення, це спрацює. Деактивувати відключення, видаливши toorобліковий запис, тривіально ; тому єдиною перевагою є наявність окремого пароля.

Крім того, ви можете переглянути альтернативні механізми аутентифікації, тобто sshключі libnss-extrausers, LDAP тощо.

Зауважте, що адміністратор все ще може погано викручуватися. Наприклад, блокуючи брандмауер.

Якщо ви хочете мати дуже захищену систему, подумайте про використання SELinux, де користувач unix (наприклад, root) також надходить з роллю, яка може бути набагато більш тонкою. Ви можете надати кореневому доступу адміністратора, але лише обмежену роль (наприклад, лише для адміністрування апаша). Але для цього вам знадобиться досить багато зусиль, щоб правильно налаштувати політику.

Суть кореня полягає в необмеженому командуванні системою. Ви можете налаштувати його за допомогою SELinux (раніше був демонстраційний сайт, де кожен міг увійти як root, але його потужність була скалічена через систему доступу), але це не в цьому. Справа в тому, що це неправильне рішення вашої проблеми.

Тепер ви ще не сказали, у чому полягає ваша проблема, але якщо ви не довіряєте цим користувачам тримати їх руки від кореневого пароля, вони не мають жодної справи. Якщо їм потрібно адмініструвати веб-сервер чи різні апаратні пристрої, або warp-накопичувач чи будь-що інше, налаштуйте рішення для цього. Створіть надпотужну групу, надайте їй весь необхідний доступ та додайте їх до неї. Якщо їм потрібно виконувати лише кореневі системні виклики, напишіть кілька встановлених програм.

Звичайно, користувач з таким доступом (і трохи знань), ймовірно, може легко зламати систему, але ви принаймні працюєте з моделлю безпеки ОС, а не проти неї.

PS. Існує багато способів влаштувати кореневий доступ для себе без пароля; для одного, якщо ви знаходитесь /etc/sudoers(без обмежень), вам потрібен лише власний пароль, щоб стати root, наприклад, з sudo bash. Але вам просто не потрібно було їхати туди.

Можливо, принаймні теоретично, це можна зробити за допомогою SELinux . Це дозволяє налаштувати набагато більш точні правила щодо того, що користувач чи процес чи ні заборонено робити. Навіть із системою SELinux може бути складним унеможливити зміну кореневого пароля користувачеві, але все-таки в змозі зробити все, що їм може знадобитися.

Дійсно, це залежить від того, що дійсно потрібно користувачеві, якому заборонено змінювати пароль root. Напевно, буде простіше і безпечніше просто розробити, що це таке, і надати ці дозволи, спеціально використовуючи sudo.

Можливо, вам слід подумати про те, щоб дозволити користувачам мати root-доступ до віртуальної машини або контейнера LXC. Це дозволило б їм отримати повний кореневий доступ до системи, не дозволяючи їм заважати входити в хост або вживати адміністративних дій.

Я не знаю, що це буде практично здійсненно, але ось один брудний злом:

1. напишіть скрипт / програму для обгортки, яка скопіює /etc/passwdфайл у якесь інше місце, перш ніж викликати фактичнеsudo
2. Дозволити звичайному користувачеві користуватися sudo
3. Як тільки він закінчив своє завдання, або коли він вийшов із судо, відновіть /etc/passwdфайл

Я знаю, що для цього потрібно врахувати багато плюсів-мінусів. Зрештою, це брудний злом

Заява, яка sudoпризначена лише для надання root, і після цього немає захисту, явно неправдива.

Ви використовуєте visudoдля зміни файлу sudoers. Ось приклад рядка:

redsandro ALL=(ALL:ALL) NOPASSWD:/path/to/command

• redsandroце ім'я користувача, на яке ми надаємо дозвіл. Поставте %фронт, щоб він застосовувався до групи.
• ALL- це назва цього правила. Судонери можуть зробити набагато більше, ніж просто надати глобальні дозволи. Ось де все ускладнюється.
• = не потребує пояснень
• ALL:ALLчитається як (who_to_run_it_as: what_group_to_run_it_as). Таким чином ви можете дозволити запуск команди, але тільки в контексті конкретного користувача або групи.
• NOPASSWD: вказує, щоб вимкнути підказку пароля.
• /path/to/command дозволяє вказати конкретні команди path_to_commmand, another_command

Слід пам’ятати, що хоча sudoдомашні користувачі в основному використовуються для переходу до кореневих привілеїв, він може бути і використовується для контролю доступу до певних команд набагато більш детально.

Список літератури

• з моєї іншої відповіді тут

(Я не знаю ubuntu, але це має бути схоже на Fedora / Red-Hat)
Єдине, що я можу собі уявити обмеженням доступу до зміни кореневого пароля - це не надавати повного доступу до кореня, можливо, із судо, або використовувати SElinux для обмеження доступу до файлу паролів ... але я б не довіряв ні великому доступу, оскільки root зазвичай має необмежений доступ і може оновити SElinux, або відновити файл пароля, або запустити якусь попередньо підготовлену програму для зміни пароля.

Якщо ви їм недостатньо довіряєте, щоб не змінити пароль, ви, мабуть, не повинні надавати їм кореневий доступ. Інакше я б здогадався, що ти намагаєшся уникати нещасних випадків.

Якщо ви лише намагаєтеся захистити свій доступ до root, встановіть програму, яка може відновити пароль root, так що навіть якщо він змінений, його можна відновити з мінімальним доступом. (Судо добре справляється самостійно)

Ваша вимога:

У нас є невелика проблема на сервері [...], тобто гарантія того, що ми все одно можемо увійти на цей сервер і стати root, незалежно від того, що робитимуть інші користувачі.

З вашого запитання здається, що ви не стикаєтеся з випадковими зловмисними користувачами, які мають намір знищити вашу систему, а натомість мають напівдовірчих користувачів, які можуть спричинити непорозуміння час від часу (студенти, можливо?). Мої пропозиції стосуються цієї ситуації, а не загального нападу зловмисних користувачів.

1. Запустіть сервер всередині віртуального середовища. Ви зможете змонтувати файлову систему сервера та замінити змінені файли відомими хорошими версіями. Залежно від можливого збитку, який ви очікуєте, ви можете зробити знімок усіх критичних каталогів (/ bin, / sbin, / тощо, / usr, / var тощо) та розширити знімок, щоб перезаписати пошкоджені файли, залишаючи решту система неушкодженою.

2. Запустіть систему лише для читання, наприклад, з DVD-R. Якщо ви можете жити, коли більшість частин системи є статичними до наступного перезавантаження, це хороший варіант. Ви також можете скористатися резервним сховищем лише для читання з віртуальним середовищем або завантажити базову систему по мережі, що робить зміни між перезавантаженнями набагато простішими, ніж написання нового DVD-R.

3. Модулі ядра. Модулі безпеки Linux (LSM) ядра служать основою для створення захищених модулів. LSM використовується SELinux, але також використовується низкою менш відомих і простіших систем, таких як Smack, TOMOYO та AppArmor. У цій статті є хороший огляд варіантів. Швидше за все, це одна з тих, які можна налаштувати поза вікном, щоб не допустити доступу для запису до / etc / passwd, / etc / shadow або будь-якого іншого файлу, який ви хочете, навіть під корінь.

4. Та сама ідея, що і №1, але коли сервер не знаходиться у віртуальному середовищі. У вас може бути завантажена ланцюг сервера в ОС, доступній лише для читання, такі як живий компакт-диск, який автоматично монтує файлову систему сервера і замінює базову систему на кожному завантаженні з відомими хорошими копіями. ОС тоді лише для читання завантажиться в основну ОС.

5. Знову ж таки, якщо припустити, що це напівнадійні користувачі, які підзвітні вищому керівнику (вчитель / начальник), найкращою відповіддю може бути аудит Linux . Таким чином ви дізнаєтесь про всі дії, пов’язані з безпекою, і хто їх здійснив (ви дізнаєтесь, хто вчинив, тому що навіть якщо всі користувачі мають спільний корінний обліковий запис, вони спочатку отримають доступ до свого облікового запису користувача). Насправді ви навіть зможете проаналізувати журнал аудиту в режимі реального часу та замінити пошкоджені файли. / тощо / тінь переписана? Немає проблем, просто сервер моніторингу миттєво замінить його на добре відому версію.

Інші технології, які ви можете вивчити, виходячи з ваших потреб:

• Архітектура вимірювання цілісності Linux / модуль розширеної верифікації (IMA / EVM) та
• Моделі надійної платформи (TPM).

Щоб доповнити інші відповіді, я припускаю, що сценарій полягає в тому, що ви вважаєте, що втрачаєте контроль над коренем рідкісною ситуацією, і що в таких випадках перезавантаження сервера дозволено. (Зрештою, якщо ви вважаєте, що машина зламана, ви все одно захочете її зняти в автономному режимі.)

Велика перевага цього в тому, що налаштовувати нічого. Ваше запитання стає таким: " Я забув корінний пароль, як я можу повернутися? ", І відповідь на це - перезавантажити систему та вибрати режим однокористування, коли машина з'явиться. Це дає вам кореневу оболонку без необхідності знати пароль. У цей момент ви можете встановити новий пароль. (А також зайдіть і відремонтуйте будь-які пошкодження ...)

Якщо ви клонуєте ваш сервер у віртуальній машині (наприклад, VirtualBox ), ви можете надати людям безперебійний доступ до коренів і все одно гарантуєте, що ви завжди матимете прямий доступ до розділів (-ів) гостьової операційної системи, а тому підтримуєте остаточний контроль над /etc/passwdі подібне, оскільки ви будете мати root в хост-системі.

Зрозуміло, надання безперебійного доступу до кореня все ще не може бути правильним рішенням: якщо безпека даних взагалі є проблемою або вашою відповідальністю, ви не можете надати доступ до кореневого доступу.

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

Однак, якщо ви можете довіряти своїм користувачам, що вони не злі, ви можете обмежити зміну пароля питаннями політики . Ви можете створити обгортку для passwdпрограми, яка буде нагадувати їм "будь ласка, не змінюйте кореневий пароль". Це передбачає, що джерелом проблеми є те, що користувачі, які змінюють пароль root, роблять це через непорозуміння (як, можливо, думають, що вони змінюють власний пароль після того, як це зробили sudo bash).

За особливих (рідкісних) обставин, якщо повна довіра неможлива і неможливо порушити sudoдоступ до адекватних, але досить безпечних фрагментів, ви можете розглянути можливість встановлення організаційних санкцій проти зміни пароля (або будь-якої іншої визначеної форми підробки системи), домовіться про це моніторинг найважливіших ресурсів, щоб нелегко не помітити, щоб обійти встановлену політику - і бути публічним та прозорим щодо правил використання та моніторингу.

Аспект моніторингу та виявлення - це важка технічна проблема, яка може отримати користь від іншого питання, якщо ви вирішите пройти цей шлях. Мені здається, нам це потрібно

1. виявити, коли користувач змінює ідентифікацію на root і відстежувати будь-які створені процеси;
2. з цього часу занотуйте створення процесів, щоб побачити, хто є оригінальним користувачем, відповідальним за кожен процес, та використовуючи віддалений хост, де напівдовірні користувачі не мають доступу для надсилання журналів;
3. використовувати якесь системне відстеження, щоб зареєструвати те, що відбувається, і щоб згодом виявити, хто стояв за порушенням політики.

Нам потрібно, принаймні, увімкнути відкриття іншого, ніж безпечного набору файлів для запису, створення процесів exec(), і звичайно будь-яку спробу змінити мережу.

Реалізація може бути здійснена за допомогою модифікованого libc або (набагато краще) системного відстеження викликів.

Звичайно, неможливо змусити такі відстежування та ведення журналів на 100% правильно, це непросто у здійсненні, а для роботи також потрібні додаткові ресурси. Це не зупинить зміну пароля чи іншу недоброзичливу підробку системи, але це зробить можливим (скоріше) знайти винного користувача або, принаймні, створити ілюзію, що існує моніторинг, і зробить його менш привабливим для злих недобросовісних користувачів (але деякі проблеми, котрі люблять хакерів, які бачать фундаментальну марність вжитих технічних заходів, можуть відчути спонукання прийняти виклик і спробувати обійти систему лише заради задоволення від неї).

Оригінально сформульоване питання марно. Схоже, головна мета - «все-таки мати вхід», тому кажучи про якийсь екстрений вхід, який продовжує працювати напевно, навіть якщо кореневий доступ надається іншій особі. Привіт Аноні-Муссе, який перший це явно зазначив.

Проблема полягає в тому, що якщо власник має фізичний доступ до вікна, він може легко відновити логічні доступ до системи (за умови, що він ще живий :). Якщо ні - зберігання кореневого пароля не врятує, наприклад, sshd вниз або погана настройка мереж, таким чином система все одно недоступна.

Тема про те, як запобігти пошкодженню системи особою, яка має адміністративні привілеї, видається занадто широкою, щоб відповідати формату питань SE.

Якщо говорити про віддалене рішення щодо введення надзвичайних ситуацій, найкращим способом є IPMI (я думаю), якщо він є. Власник системи може приєднати віртуальний диск у будь-який час, завантажитися з нього та розпочати відновлення системи.

Якщо IPMI відсутній, будь-яка підходяща технологія віртуалізації не може обійтися, як уже було запропоновано вище.

Ви можете обмежити доступ до sudo у вашому /etc/sudoersфайлі

Щоб повністю пояснити синтаксис / etc / sudoers, ми будемо використовувати зразок правила та розбивати кожен стовпець:

jorge  ALL=(root) /usr/bin/find, /bin/rm

Перший стовпець визначає, до якого користувача чи групи застосовується це правило sudo. У цьому випадку це jorge користувача. Якщо слову в цьому стовпці передує символ%, воно позначає це значення як групу замість користувача, оскільки система може мати користувачів та групи з тим самим іменем.

Друге значення (ALL) визначає, до яких хостів це правило sudo застосовується. Цей стовпець є найбільш корисним при розгортанні середовища sudo в декількох системах. Для настільної системи Ubuntu або для системи, де ви не плануєте розгортати ролі sudo в декількох системах, ви можете залишити це значення встановленим на ВСІ, це є мальованою карткою, яка відповідає всім хостам.

Третє значення задається в дужках і визначає, яким користувачем або користувачами користувач у першому стовпці може виконати команду як. Це значення встановлено на root, що означає, що jorge буде дозволений виконувати команди, вказані в останньому стовпчику, як користувач root. Це значення також може бути встановлено на ВСЕ підстановку, що дозволить jorge виконувати команди, як будь-який користувач у системі.

Останнє значення (/ usr / bin / find, / bin / rm) - це розділений комами список команд, який користувач у першому стовпці може виконувати як користувачі (і) у третьому стовпці. У цьому випадку ми дозволяємо jorge запускати find і rm як root. Це значення також можна встановити на ВСЕ підстановку, що дозволило б jorge запускати всі команди в системі як корінь.

Зважаючи на це, ви можете дозволити X-команди в обмеженому комою порядку, і поки ви не додасте passwdдо цього, ви повинні бути добре

Немає жодного 1/2 кореня :) Після надання привілеїв root вони можуть робити все, що завгодно. Крім того, ви можете використовувати sudo для запуску обмеженої оболонки bash або запуску rbash без привілеїв root.

Якщо ви хочете мати механізм відмови, щоб увійти на сервер як root, ви можете або створити іншого користувача, uid=0або створити простий cron, який періодично скидає пароль root.

Спробуйте додати групу коліс, а не використовувати судо. sudo дозволяє користувачеві виконувати так, ніби вони є root, а це означає, що він не відрізняється від запуску:

су -

стати коренем. Корінь uid = 0; колесо uid = 10. Люди використовують імена, але ОС використовує uid. Деякі команди не можуть виконувати член колесної групи. (Якщо ви використовуєте колесо, не робіть помилки, додаючи корінь як член групи колеса). Погляньте на документацію Red Hat, якщо ви не знаєте, що таке колесо.

Інший варіант - використовувати ключ ssh, а не пароль. Припускаючи, що ви можете бути впевнені, що люди, які використовують sudo, не додають свої відкриті ключі до файлу ~ / .ssh / санкціонованих ключів, це сприймає будь-які проблеми щодо зміни кореневого пароля, оскільки пароль root фактично ігнорується.

Якщо ви бажаєте заохочувати довіру до цих користувачів (не додавати їх власний відкритий ключ), спробуйте скористатися розширеними атрибутами файлів та за допомогою біта Immutable. Після створення файлу ~ / .ssh / санкціонованих ключів та після конфігурації / etc / ssh / sshd_config та / etc / ssh / ssh_config встановіть потрібний біт. Звичайно, є й способи накрутити це - нічого ідеального.

У будь-якій системі інсайдери є найвищим ризиком. Людина, яка веде шоу, знаходиться у верхній частині купи. Пов'язана думка стосується контрактів. Юристи скажуть вам: "Ніколи не займайтеся бізнесом з кимось, з ким вам потрібен контракт для ведення бізнесу". Здоровий глузд говорить нам: "Ніколи не ведіть бізнес без договору". Коли ви знайдете когось, якому ви достатньо довіряєте, щоб вести бізнес, пишіть договір, виходячи з потреб один одного.

Усі надіслані відповіді, включаючи мою, не відповідають фізичному доступу. Хто б не мав, той має контроль. Якщо це не ви, то, ймовірно, ви зможете отримати людину, яка робить фізичний доступ до машини, якщо хтось знайде спосіб запобігти вам увійти, або якщо він знайде спосіб увійти навіть після вас я намагався не допустити цього. Звичайно, якщо у вас фізичний доступ, можливо, не буде необхідності жодна з цих речей, хоча реалізація пари все-таки повинна бути розглянута, якщо вам цікаво НЕ бути незручним.

-Джон Крут

Одним із способів було б переконатися, що /etcце не піддається запису. Ніхто, доки може бути sudoerнавколо.

Це можна зробити, встановивши її по мережі та переконайтесь, що з іншого боку не можна записати пристрій.

Це можна зробити за допомогою локального пристрою, який перешкоджає доступу до нього запису. (Пошук write blockerапаратного забезпечення)

Важлива частина полягає в тому, що обмеження має застосовуватися поза кореневою концепцією цієї машини. Творчий хакер знайде всі перешкоди, які ви їм поставите, в оточенні, яке він може контролювати. Отже, якщо root міг змінити свій пароль, то може sudoer.

Щоб бути впевненим, що користувач також не може виконувати ваші здібності до входу, у вас повинні бути встановлені лише читання /binта /sbin.

І вам доведеться мати сценарій, який періодично відновлює мережеве з'єднання.

(Як сторонне позначення: Якщо ви дозволите судеру лише дуже обмежений набір команд, і для кожної з них переконайтеся, що вони не можуть вирватися з них / замінити їх і т.д., то ви можете запобігти цьому, під час /etcзапису.)