Doas — лёгкая альтернатива sudo

Содержание

• Проблема с sudo
• Зачем использовать doas
• Установка doas на разные дистрибутивы
• Конфигурационный файл doas (/etc/doas.conf)
• Примеры правил и рекомендации
• Постнастройка и проверки
• Советы по безопасности и переносу с sudo
• Часто задаваемые вопросы
• Краткое резюме и чек‑листы

Проблема с sudo

Со временем sudo стал де‑факто стандартом для повышения привилегий в UNIX‑системах. Чтобы поддержать множество сценариев и потребностей, sudo вырос в функционально богатую, но сложную программу. Эта сложность проявляется в синтаксисе файла sudoers и в необходимости использовать вспомогательную утилиту visudo для безопасного редактирования.

visudo выполняет две важные функции: проверяет синтаксис файла /etc/sudoers и блокирует файл для одновременного редактирования. На практике это полезно в средах с несколькими администраторами, но также является симптомом усложнения конфигурации — необходимость в специальном загрузчике указывает на то, что файл конфигурации стал трудно читаемым и подверженным ошибкам.

Для опытного администратора гибкость sudo — достоинство: можно построить тонкие политики доступа. Для большинства пользователей же sudo нужен лишь для запуска команд с правами root: установка пакетов, редактирование системных файлов, диагностика. В таких случаях сложность мешает, а не помогает.

Зачем использовать doas

Doas решает задачу упрощения. Его цели:

• Минимализм — небольшой, понятный код и синтаксис.
• Простота конфигурации — читаемые правила, редактируемые любым текстовым редактором.
• Прозрачность — отсутствие «магии» и специальных загрузчиков.

Пример: чтобы разрешить всем пользователям из группы wheel выполнять команды как root без пароля, в sudo нужно было бы написать:

%wheel ALL=(ALL) NOPASSWD: ALL

В doas эквивалент выглядит понятнее:

permit nopass :wheel as root

Doas не требует отдельной утилиты наподобие visudo: редактируйте /etc/doas.conf любым редактором, убедитесь, что права и владелец файла корректны, — и всё готово.

Установка doas на разные дистрибутивы

Doas доступен в виде пакета opendoas в большинстве популярных дистрибутивов. Команды установки (выполняются с правами пользователя, имеющего sudo):

Debian / Ubuntu:

sudo apt update && sudo apt install doas

Arch Linux:

sudo pacman -Syu opendoas

Fedora:

sudo dnf install opendoas

Void Linux:

sudo xbps-install -S opendoas

Если ваш дистрибутив содержит пакет opendoas, он может называться именно так. На OpenBSD doas уже включён по умолчанию.

Примечание: на некоторых системах бинарник может называться doas, а пакет — opendoas. Проверяйте менеджер пакетов.

Конфигурационный файл doas (/etc/doas.conf)

Откройте или создайте файл /etc/doas.conf под root. На системах с su можно выполнить, например:

su --command="nano /etc/doas.conf"

Файл может быть пустым — это нормально: doas действует только по правилам, которые вы добавите.

Синтаксис конфигурации

Общая форма записи:

permit|deny [options] identity [as target] [cmd command [args ...]]

Коротко о компонентах:

• permit / deny — разрешить или запретить правило.
• options — дополнительные ключи: persist, nopass, env_keep и т.п. (по умолчанию нет).
• identity — пользователь или группа (группы обозначаются с двоеточием, например :wheel).
• as target — пользователь, от имени которого выполняется команда (например root).
• cmd command — конкретная команда. Если не указан, правило относится ко всем программам.
• args — аргументы команды (опционально).

Примеры правил:

Разрешить группе wheel выполнять команды как root и сохранять сессию:

permit persist :wheel as root

Разрешить пользователю bob запускать apt от root без пароля:

permit nopass bob as root cmd apt

Запретить конкретному пользователю aga выполнять команды как root (даже если он в wheel):

deny aga as root

Важно: порядок правил имеет значение — doas обрабатывает их сверху вниз; как правило, сначала пишут общие правила, затем более специфичные.

Примеры правил и лучшие практики

1. Стандартное разрешение для администраторов:

permit persist :wheel as root

2. Разрешить конкретную команду (например /usr/bin/systemctl) для группы support без пароля:

permit nopass :support as root cmd /usr/bin/systemctl

3. Разрешить запуск только с определёнными аргументами (если поддерживается):

permit nopass alice as root cmd /usr/bin/rsync args --archive

4. Отдельная строка deny для исключений — всегда ниже общей строки allow, если требуется изъятие прав:

permit :wheel as root

deny bob as root

Ключевые рекомендации:

• Минимизируйте права — отдавайте доступ только к нужным командам.
• Используйте полные пути к командам (например /usr/bin/apt), чтобы избежать амбигуити.
• Старайтесь не использовать глобальные nopass без веской причины.

Постнастройка: владельцы, права и проверка конфигурации

После редактирования убедитесь, что владелец и права файла корректны:

sudo chown root:root /etc/doas.conf
sudo chmod 0644 /etc/doas.conf

Проверьте синтаксис конфигурации doas (если ваша версия поддерживает проверку):

sudo doas -C /etc/doas.conf && echo "OK" || echo "ERROR"

Если команда выводит OK — всё в порядке. Если выводит ERROR, пересмотрите строки в конфигурации.

Советы по безопасности и жёсткая политика

Doas — это упрощение, но безопасность по‑прежнему важна:

• Ограничивайте команды по пути и аргументам.
• Избегайте широких правил nopass для групп, содержащих непроверенных пользователей.
• Проверяйте, какие программы в системе можно использовать для обхода ограничений (например оболочки, интерпретаторы, скриптовые движки).
• Логируйте все выполнения (конфигурация doas обычно пишет в syslog). Проверьте настройки rsyslog/ journalctl для записи действий doas.

Короткий чеклист безопасности:

• /etc/doas.conf принадлежит root:root
• Права файла 0644 или строже
• Нет глобальных nopass для всех пользователей
• Указаны полные пути к исполняемым файлам
• Логи действий доступны и мониторятся

Совместное использование sudo и doas

Doas и sudo не конфликтуют. Можно оставить sudo в системе и постепенно перевести повседневные операции на doas. Некоторые сценарии лучше оставлять в sudo (например, интеграция с ldap/AD или сложные политики), где нужна богатая функциональность.

Советы по миграции:

• Переносите правила постепенно — сначала основные админские сценарии.
• Тестируйте каждый шаг в тестовой среде.
• Документируйте отличия синтаксиса (doas читабельнее — используйте это при обучении команды).

Модель принятия решений (когда выбрать doas, когда оставить sudo)

flowchart TD
  A{Нужна тонкая ACL / интеграция} -->|Да| B[sudo]
  A -->|Нет| C{Нужна простота и прозрачность}
  C -->|Да| D[doas]
  C -->|Нет| B
  B --> E[Оставить sudo]
  D --> F[Установить doas и мигрировать постепенно]

Роли и чек‑листы (кто что делает)

Администратор:

• Установить пакет opendoas.
• Создать/отредактировать /etc/doas.conf.
• Проверить владельца и права файла.
• Настроить логирование и мониторинг.
• Документировать правила и порядок отказа.

Обычный пользователь:

• Запросить точное правило у администратора (какую команду и с какими аргументами нужно разрешить).
• Использовать doas для выполнения только одобренных операций.
• Сообщать об ошибках и непредвиденном поведении.

Критерии приёмки

• doas установлен и бинарник доступен в PATH.
• /etc/doas.conf существует и принадлежит root:root.
• Тестовые команды работают согласно правилам (включая проверки nopass/persist).
• Логи фиксируют попытки использования doas.

Тестовые сценарии (acceptance)

1. Проверить, что пользователь из :wheel может выполнить sudo эквивалент:

doas -s

Ожидается: получение shell с UID 0 (если правило разрешает).

2. Проверить правило для конкретной команды:

doas apt update

Ожидается: команда выполняется без запроса пароля, если прописан nopass.

3. Проверить запрет для конкретного пользователя (deny): попытка должна быть отклонена и записана в лог.

Часто задаваемые вопросы

1. Моя конфигурация не работает: правило для конкретного пользователя не срабатывает, хотя есть общее правило.

Doas читает правила сверху вниз. Общие правила обычно определяют поведение для групп; если вы хотите, чтобы специфическая строка для пользователя применялась, разместите её ниже общей строки allow, но следите за логикой deny/permit. В сложных случаях переставьте порядок или явно запретите/разрешите нужные комбинации.

2. Можно ли иметь sudo и doas одновременно?

Да. Они независимы и не мешают друг другу. Оставьте sudo для сценариев, где нужна его расширенная функциональность.

3. Можно ли получить root‑shell через doas?

Да. Если конфигурация позволяет, команда doas -s открывает shell от имени целевого пользователя (обычно root). Всегда применяйте принцип наименьших привилегий.

4. Как отладить ошибки конфигурации?

Проверяйте синтаксис командой:

doas -C /etc/doas.conf && echo "OK" || echo "ERROR"

Также смотрите логи syslog / journalctl на предмет сообщений doas.

Глоссарий (1‑строчная справка)

• doas — упрощённый механизм повышения привилегий (OpenDoas).
• nopass — опция в doas.conf, позволяющая не запрашивать пароль.
• persist — сохраняет сессию повышенных привилегий.
• identity — пользователь или группа, к которым применяется правило.

Альтернативные подходы и когда doas не подходит

Когда стоит предпочесть sudo:

• Необходима интеграция с LDAP/AD и централизованными политиками.
• Требуются очень гибкие ACL и специальные возможности sudoers (разветвлённые правила, RunAsMultiple, делегирование с временными правами и др.).

Альтернативы doas:

• sudo — мощный и гибкий, но сложный.
• PolicyKit — для управления привилегиями на уровне приложений (desktop‑ориентирован).

Краткое резюме

Doas — отличный инструмент, если вам нужна простая, понятная и безопасная замена для типичных сценариев повышения привилегий. Он облегчает жизнь администраторам и пользователям благодаря читабельному синтаксису и отсутствию специальных утилит для редактирования конфигурации. Для сложных корпоративных сценариев sudo остаётся предпочтительным.

Важно: планируйте миграцию, тестируйте правила и всегда минимизируйте права.

Быстрые шаблоны (шпаргалка)

• Разрешить группе wheel без пароля:

permit nopass :wheel as root

• Разрешить конкретную команду alice без пароля:

permit nopass alice as root cmd /usr/bin/apt

• Запретить пользователя bob от выполнения команд от root:

deny bob as root

Конец статьи.