Коли на сервері або робочій станції з’являються звичайні акаунти, важливо дати їм стільки можливостей, скільки потрібно для роботи — і не більше. У цій статті покажу, як ви можете обмежити права через sudo, увімкнути обмежені shell‑середовища і грамотно логувати linux команди, щоб завжди знати, хто і що робив. 🛡️

Що саме ми обмежуємо і навіщо

Мета — мінімізувати ризики: надмірні привілеї, випадкові злами, помилкові дії у термінал Linux. Ми сфокусуємося на трьох речах:

  • Точкові привілеї через sudo (принцип найменших прав).
  • Обмежені оболонки (rbash, sftp‑only, nologin) для контролю можливостей.
  • Логування дій: sudo I/O, auditd і відправка команд у syslog (log-файли Linux).

How-to: мінімальні права через sudo

Найкраща практика — не робити користувача «адміном», а дати групі користувачів вузькі дозволи на конкретні команди. Так ви збережете чистоту у права доступу Linux і прозорість для аудиту.

Крок 1. Створюємо групу та додаємо користувача

Припустимо, вам треба, щоб певні люди керували лише сервісом nginx. Створіть групу й додайте користувача:

sudo groupadd webops
sudo usermod -aG webops alice
id alice

Перевірте, що користувача додано до потрібної групи (користувачі та групи Linux — це база безпеки).

Крок 2. Правила у sudoers через включення

Правильно — не редагувати /etc/sudoers напряму, а створити окремий файл у /etc/sudoers.d. Відкрийте його через visudo:

sudo visudo -f /etc/sudoers.d/50-webops

Додайте мінімально необхідні дозволи і журнали:

# Глобальні безпечні дефолти
Defaults use_pty
Defaults env_reset
Defaults secure_path="/usr/sbin:/usr/bin:/sbin:/bin"
Defaults logfile="/var/log/sudo.log"
Defaults log_input, log_output
Defaults iolog_dir="/var/log/sudo-io"

# Дозволяємо групі webops керувати тільки nginx
Cmnd_Alias WEBCTL = /usr/bin/systemctl status nginx, /usr/bin/systemctl restart nginx
%webops ALL=(root) /usr/bin/systemctl status nginx, /usr/bin/systemctl restart nginx

Збережіть файл і перевірте синтаксис (visudo зробить це автоматично). Тепер користувач із групи webops може переглядати статус nginx і перезапускати його під sudo — і більше нічого.

Крок 3. Перевіряємо дозволи

Увійдіть під користувачем або перемкніться на нього і перевірте:

su - alice
sudo -l
sudo systemctl status nginx
sudo systemctl restart nginx

А от sudo -i чи інші команди мають бути заборонені.

Обмежені shell‑середовища

Навіть без sudo користувач може нашкодити. Обмежені оболонки дають контроль: куди можна переходити, які команди запускати та як поводитися з PATH.

Варіант A: rbash (restricted bash)

rbash забороняє змінювати каталоги і PATH, виконувати команди з «/», тощо. Налаштування:

# Призначити обмежену оболонку
sudo chsh -s /bin/rbash guest

# Дозволені команди в окремій «пісочниці»
sudo -u guest mkdir -p /home/guest/bin
sudo ln -s /usr/bin/htop /home/guest/bin/htop
sudo ln -s /usr/bin/journalctl /home/guest/bin/journalctl

# Обмежений PATH у профілі користувача
echo 'export PATH="$HOME/bin"' | sudo tee -a /home/guest/.profile
sudo chown guest:guest /home/guest/.profile

Тепер у гостя виконуються лише ті linux команди, на які є посилання в ~/bin. Спроба змінити каталог або запустити щось поза PATH — відхилиться.

Варіант B: доступ лише до SFTP через SSH

Щоб унеможливити shell взагалі, лишивши лише обмін файлами, використовуйте вбудований internal-sftp і chroot:

sudo mkdir -p /srv/sftp/alex
sudo chown root:root /srv/sftp
sudo chown root:root /srv/sftp/alex
sudo mkdir -p /srv/sftp/alex/upload
sudo chown alex:alex /srv/sftp/alex/upload

sudo nano /etc/ssh/sshd_config
# Додайте в кінець:
Match User alex
  ForceCommand internal-sftp
  ChrootDirectory /srv/sftp/%u
  X11Forwarding no
  AllowTcpForwarding no

sudo systemctl restart ssh

Користувач alex тепер матиме тільки SFTP, без доступу до оболонки.

Варіант C: nologin/false

Щоб заборонити логін повністю:

sudo chsh -s /usr/sbin/nologin someuser
# або
sudo chsh -s /bin/false someuser

Логування команд і дій

Логи рятують, коли треба розібратися, хто що робив. Нижче — три рівні контролю.

1) Sudo I/O logging

Ми вже ввімкнули I/O‑логування у sudoers. Перевірка:

sudo -k
sudo systemctl status nginx
sudo ls /root  # має бути заборонено

# Перегляд сесій
sudo sudoreplay -l /var/log/sudo-io
# Відтворити конкретну сесію за ID (підставте свій):
sudo sudoreplay 000001

2) auditd: хто що запускав (execve)

Auditd фіксує запуск процесів на рівні ядра. Встановлення і правило для UID ≥ 1000:

sudo apt update && sudo apt install -y auditd audispd-plugins
# Fedora/RHEL: sudo dnf install audit

# Постійне правило
echo '-a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=4294967295 -k user-cmd' | sudo tee /etc/audit/rules.d/10-user-cmd.rules
sudo augenrules --load || sudo service auditd restart

# Пошук подій
sudo ausearch -k user-cmd --start today | sudo aureport -x --summary

3) Надсилання історії Bash у syslog

Корисно для швидкого огляду, хоча досвідчений користувач може це обійти. Додаємо у профіль користувача або глобально в /etc/profile:

echo 'export HISTTIMEFORMAT="%F %T "' | sudo tee -a /etc/profile
sudo bash -c 'echo "export PROMPT_COMMAND=\'history -a; logger -p authpriv.notice -t bash[$$] \"\$(whoami)@\$(hostname): \$(history 1)\"\'" >> /etc/profile'

Тепер повідомлення потраплятимуть до authpriv у ваші log-файли Linux (перевіряйте /var/log/auth.log або journald).

Альтернативні підходи

  • SELinux/AppArmor: створюйте профілі, що обмежують доступ процесів до файлів/мережі.
  • Монтования із noexec,nodev,nosuid для тимчасових каталогів зменшують вектори ескалації.
  • Контейнери/подходи із sandboxing для запуску ризикових задач із мінімальним впливом на хост.

GUI-спосіб (коли доречно)

У десктопних дистрибутивах можна частково керувати правами без терміналу:

  • Ubuntu/KDE: Налаштування системи → Користувачі. Вимкніть перемикач «Адміністратор», щоб користувач не мав sudo.
  • openSUSE (YaST): Модуль «User and Group Management» дозволяє керувати користувачі та групи Linux. Список sudo‑прав теж доступний у YaST.

Нагадую: тонке налаштування sudo все ж краще робити через visudo. 🧰

FAQ

Чому не варто давати повний sudo?

Повний sudo = повний root. Будь-яка помилка або шкідлива дія стає критичною. Краще давати вузькі дозволи на окремі команди.

Чи можна дозволити лише apt update?

Можна, але це ризиково (оновлення змінює систему). Якщо все ж потрібно, додайте в окремий Cmnd_Alias лише read‑only операції або використовуйте централізоване оновлення.

Як протестувати правила без ризику?

Створіть тимчасового користувача, увійдіть у нову сесію, використовуйте sudo -l і намагайтеся виконати заборонені дії. Перевіряйте журнали у log-файли Linux.

Чи можна «вирватися» з rbash?

Іноді через редактори або програми з «shell‑escape». Мінімізуйте ризик: не давайте такі утиліти, контролюйте PATH, використовуйте chroot/SFTP‑only там, де треба лише передача файлів.

Як швидко відкликати доступ до sudo?

Приберіть користувача з відповідної групи і (за потреби) тимчасово перемістіть файл у /etc/sudoers.d в інше місце, перевіривши синтаксис через visudo.

Де лежать логи sudo I/O?

Каталог за замовчуванням ми задали як /var/log/sudo-io, а зведений журнал — /var/log/sudo.log. Переглядайте сесії через sudoreplay.

Порада від Kernelka

Починайте з політики: які ролі вам потрібні і які конкретні дії кожна роль повинна виконувати. Потім під ці ролі створюйте групи, правила sudo і, за потреби, обмежені оболонки. Так легше масштабувати й не плутатися в налаштуваннях.

Підсумок

  • Видавайте мінімальні права через sudo і групи, використовуйте включення в /etc/sudoers.d.
  • Обмежуйте оболонку: rbash, SFTP‑only або nologin — за сценарієм використання.
  • Вмикайте журналювання: sudo I/O, auditd, за потреби — відсилання історії Bash у syslog.
  • Перевіряйте налаштування на тестовому користувачі та стежте за log-файли Linux.
  • GUI корисний для базових речей, але тонкі політики — тільки через термінал Linux.