Використання CmndAlias ALLніколи не буде безпечним
Є 1000 способів бігати, service network restartне роблячи sudo service network restart. Ось приклад того, що може спробувати неслухняний користувач:
$ echo "service network restart" > /tmp/hax
$ chmod a+x /tmp/hax
$ sudo /tmp/hax
Якщо ви надасте користувачам ALLпсевдонім команди, а потім спробуєте створити чорний список, вони завжди зможуть знайти шлях до нього. Чорний список bash, і вони будуть використовувати python. Чорний список пітона, і вони використовуватимуть Perl. Чорний список Perl, і вони використовуватимуть PHP. Ніхто цього не хоче!
Якщо ви дійсно не хочете , щоб хто - то що - то зробити, ви повинні робити , як каже Томас, і створити білий список речей , які вони мають право робити.
Налаштування білого списку за винятком
Приклад невеликого білого списку з виключенням можна знайти внизу man sudoers:
pete HPPA = /usr/bin/passwd [A-Za-z]*, !/usr/bin/passwd root
The user pete is allowed to change anyone's password except for root on the HPPA
machines. Note that this assumes passwd(1) does not take multiple user names
on the command line.
(Насправді цей приклад із сторінки сторінки небезпечний і може бути використаний для зміни пароля root! Див. Коментарі нижче про те, як.)
Ми можемо спробувати пристосувати , що ваш випадок, щоб запропонувати все serviceкоманди в групі співробітників, але виключають ті service networkкоманди , які стосуються вас:
%staff ALL = /usr/sbin/service *, \
! /usr/sbin/service *network*, \
! /usr/sbin/service *NetworkManager*
(У ALLцій позиції посилається на Host_Alias, а не на Cmnd_Alias - не так?)
Користувач не зможе запустити sudo bashабо sudo teeабо sudo wgetабо sudo /path/to/malicious_script. Якщо ви обережні, ви можете додати до списку більше команд адміністратора для своїх користувачів. Просто будьте конкретні!
Примітка. *До цього слова я додав слово networkвище, лише на випадок, якщо в serviceмайбутньому до інструменту буде додано нешкідливий прапор . Уявімо, що --verboseпрапор буде додано в майбутньому, і користувачі зможуть запустити наступне:
$ sudo service --verbose network restart
Тому нам потрібно *споживати будь-які прапори перед назвою служби. Один недолік полягає в тому, що це може заблокувати інші сервіси, які ви насправді не заважаєте користувачам, наприклад, послугу, яка викликається safe-networkабо network-monitorтакож буде відхилена.
Дозволити користувачам редагувати файл за допомогою групових дозволів
Нижче ви можете знайти різні спроби, rnanoзавдяки яким sudoкористувачі можуть редагувати файл або файли. Але насправді вони складніші та небезпечніші, ніж повинні бути.
Набагато простішим та безпечнішим рішенням є зміна групових дозволів на конкретні файли, для яких потрібно відкрити права редагування. Ось кілька прикладів:
### Give steve the ability to edit his nginx config:
$ chgrp steve /etc/nginx/sites-available/steves_dodgy_project
$ chmod g+rw /etc/nginx/sites-available/steves_dodgy_project
### Let all members of the staff group edit the group_website config:
$ chgrp staff /etc/nginx/sites-available/group_website
$ chmod g+rw /etc/nginx/sites-available/group_website
Якщо вам потрібен більш тонкий контроль (наприклад, доступ лише для трьох користувачів, але не всіх співробітників), ви можете створити нову групу за допомогою addgroupкоманди та додати до неї лише декілька користувачів.
Дозвольте користувачам редагувати файл наскрізь sudo
Залишок цієї відповіді став розслідуванням того, наскільки легко залишати дірки у своїй sudoконфігурації, намагаючись запропонувати своїм користувачам гнучкість. Я б не рекомендував робити щось із наступного!
Якщо ви хочете надати своїм користувачам доступ для редагування певного файлу, ви можете спробувати скористатися rnano:
%staff ALL = /bin/rnano /etc/nginx/sites-available/host
rnanoдозволить лише їм редагувати вказаний файл. Це важливо, щоб зловмисний користувач не міг редагувати іншу послугу для /etc/init.d/urandomзапуску (наприклад ) та додати до неї рядок, який би запускався service network restart.
На жаль, я не знайшов способу обмежитись rvimдостатньо (користувач все ще може відкрити будь-який файл, використовуючи :e), тому ми застрягли nano.
На жаль, дозволити користувачам редагувати кілька файлів набагато складніше ...
Дозвольте користувачам редагувати кілька файлів (набагато складніше, ніж це повинно бути)
1. Небезпечні підходи
Будьте обережні з подвійних карт! Якщо ви пропонуєте занадто велику гнучкість (або будь-яку гнучкість), її можна використовувати:
%staff ALL = /bin/rnano /etc/nginx/sites-available/* # UNSAFE!
У цьому випадку зловмисний користувач зможе відредагувати будь-який інший сценарій початкової служби та запустити його:
$ sudo rnano /etc/nginx/sites-available/../../../any/file/on/the/system
(Судо насправді запобігає .і ..розширює команду, але, на жаль, не на аргументах.)
Я сподівався, що щось подібне може спрацювати, але воно все ще є небезпечним:
%staff ALL = /bin/rnano /etc/nginx/sites-available/[A-Za-z0-9_-]* # UNSAFE!
Оскільки на sudoсьогоднішній день пропонуються лише глобальні шаблони, це *буде відповідати чому завгодно - це не регулярне вираження!
(Редагувати: я враховував, чи можете ви уникнути вищезазначеного у вашій ситуації, оскільки під ним немає підпапок sites-available. Ми вимагали, щоб одна папка збігалася за папкою, і вона /..повинна вийти з ладу після імені файлу. Однак це не працездатне рішення, оскільки rnanoприймає декілька аргументів. І взагалі це все-таки було б небезпечно для папки, в якій були папки!)
Навіть якщо у нас немає підпапок, і ми виключаємо будь-які рядки, що містять /../, правило, яке пропонує *глобус, все одно може бути використане, оскільки воно rnanoприймає декілька аргументів (проїжджаючи через них <C-X>, і простір з радістю приймається *глобусом.
$ rnano /etc/nginx/sites-available/legal_file /then/any/file/on/the/system
2. Натискання на конверт (також в кінцевому рахунку небезпечно)
Що робити, якщо ми відхиляємо будь-які рядки, що містять пробіли, або намагаємось досягти /..? Тоді остаточним можливим рішенням може бути таке:
# I tried hard to make this safe, but in the end I failed again.
# Please don't use this unless you are really smart or really stupid.
%staff ALL = /bin/rnano /etc/nginx/sites-available/*, \
! /bin/rnano */..*, \
! /bin/rnano /etc/nginx/sites-available/, \
! /bin/rnano */., \
! /bin/rnano * *
# CONCLUSION: It is still NOT SAFE if there are any subfolders, due to
# the bug in rnano described below.
Ми приймаємо що - небудь «під» папку , але ми також відкидаємо будь-який виклик , rnanoякщо /..або /.або /.виключення робить це /..виключення зайвим, але я залишив обох для ясності.)
Я знайшов папку, і /.виключення були потрібні, оскільки в іншому випадку користувач міг націлити на папку. Тепер ви можете подумати, rnanoщо заблокували, якби вказали на папку, але ви помиляєтесь. Насправді моя версія (2.2.6-1ubuntu1) починається з легкого попередження та порожнього файлу, після чого <C-X>просить мене ввести будь-яке ім'я файлу, до якого я хотів би зберегти, відкриваючи новий вектор атаки! Принаймні, він відмовився перезаписати існуючий файл (в одному тесті, який я зробив). У будь-якому випадку, оскільки немає можливості перетворити в папки в чорний список судо, ми повинні зробити висновок, що такий підхід знову небезпечний. Вибачте користувачів!
Це відкриття змусило мене сумніватися у ґрунтовності nano"обмеженого" режиму. Кажуть, ланцюжок настільки ж міцний, як і його найслабша ланка. Я починаю відчувати поєднання sudoчорної магії чорного списку і, rnanoможливо, не є більш безпечним, ніж ланцюжок ромашок.
3. Безпечні, але обмежені підходи
Глобуси дуже обмежені - вони не дозволяють нам кілька разів порівнювати клас персонажів. Ви можете запропонувати кілька редагувань файлів, якщо всі ваші імена файлів мають однакову довжину (у цьому випадку hostслідує одна цифра):
%staff ALL = /bin/rnano /etc/nginx/sites-available/host[0-9] # SAFE
Але якщо ви хочете надати користувачеві доступ для редагування різних файлів, можливо, вам потрібно буде чітко вказати кожен файл:
%staff ALL = /bin/rnano /etc/nginx/sites-available/hothost \
/bin/rnano /etc/nginx/sites-available/coldhost \ # SAFE
/bin/rnano /etc/nginx/sites-available/wethost \
/bin/rnano /etc/nginx/sites-available/steves_dodgy_project
Не спокушайтесь використовувати в*будь-якій точці. Дивіться розділи 1. та 2. вище для чого! Пам’ятайте: одна невелика прокладка може поставити під загрозу весь рахунок суперпользователя та всю систему.
4. Напишіть свою перевірку аргументів (безпека тепер ваша відповідальність)
Я сподіваюся, що вони нададуть підтримку regexp sudoв майбутньому; При правильному використанні це може вирішити багато проблем. Але нам може знадобитися також можливість перевірити властивості аргументів (дозволити лише файли, лише папки або лише певні прапорці).
Але є одна альтернатива - створити гнучкість у судо. Передайте долар:
%staff ALL = /root/bin/staffedit *
Потім напишіть власний staffeditскрипт або виконуваний файл, щоб перевірити, чи аргументи, передані користувачем, є законними, і виконайте їх запит лише у разі їх наявності.
networkingіnetwork-manager? Крім того, чому ваші користувачі маютьsudoдоступ? Вони не повинні, якщо ви не хочете, щоб вони мали повні права root.