sudo, doas и sudo-rs — повышение привилегий: механизм и сравнение

Назначение

sudo и doas — утилиты повышения привилегий в Unix-подобных системах: они позволяют непривилегированному пользователю выполнить команду от имени другого (обычно root), не открывая root-сессию. Обе решают эту задачу одним и тем же механизмом ядра — setuid-бинарём, — а различаются тем, что делают между получением прав root и запуском команды. С 2023 года участников стало трое: sudo-rs, переписанный на Rust sudo, с Ubuntu 25.10 занял место поставщика sudo по умолчанию и бьёт ровно в тот аргумент, ради которого выбирали doas. Поэтому статья сначала разбирает общий механизм, а затем — где реализации расходятся и что из этого следует для выбора.

Архитектура повышения привилегий

Механизм у всех трёх общий, и понимать его нужно раньше сравнения: аргумент «меньше небезопасного кода — меньше дыр» проверяется только тем, что именно этот код делает с euid=0.

Дальше разделы разбирают этот конвейер по шагам — в том же порядке.

setuid-бинарь и execve

И sudo, и doas установлены с битом setuid и владельцем root:

$ ls -l /usr/bin/sudo
-rwsr-xr-x 1 root root ... /usr/bin/sudo

s на месте бита исполнения владельца — это и есть setuid, а вся механика — в ядре, в обработчике execve(2). У каждого процесса три идентификатора пользователя: real UID (кто запустил), effective UID (по нему ядро проверяет права на всё — файлы, порты, сигналы) и saved set-user-ID. При обычном execve они наследуются от вызывающего процесса без изменений. Если же у файла выставлен бит setuid, ядро при загрузке образа поднимает effective UID до владельца файла — для sudo и doas это root, — а real UID оставляет прежним; execve(2): «The effective user ID of the process is copied to the saved set-user-ID». В результате процесс стартует с euid=0, зная при этом настоящего пользователя по real UID.

Отсюда растёт вся модель угроз. Программа запущена непривилегированным пользователем, но исполняется с правами root, и всё, что она делает до сброса привилегий, делается от root по вводу, который контролирует непривилегированная сторона: аргументы, переменные окружения, дескрипторы, управляющий терминал. Каждая из этих поверхностей уже приводила к эскалации (перечень CVE — в разделе «Безопасность»).

Бит setuid ядро чтит не всегда. Он игнорируется, если файловая система смонтирована с nosuid, если для потока выставлен no_new_privs или если процесс трассируется через ptrace, — это стандартный способ обезвредить setuid-бинарь, не снимая бит. На nosuid-разделе попытка непривилегированного пользователя выполнить setuid-файл возвращает EPERM.

Разбор политики

Получив euid=0, инструмент читает свою политику: sudo — /etc/sudoers (плюс /etc/sudoers.d/), doas — /etc/doas.conf. Чтение идёт от root, и это накладывает жёсткое требование на права файла: политику, определяющую, кому что можно от root, нельзя доверить тому, кто сам не root. Файл, доступный на запись группе или посторонним, любой из них перепишет — и получит всё.

Проверяют это обе стороны, но по-разному. doas делает fstat открытого конфига перед разбором и отказывается запускаться вовсе, если файл кому-то доступен на запись или не принадлежит root: doas.conf is writable by group or other. sudo проверяет владельца и права при чтении и предписывает редактировать sudoers только через visudo — обёртку, которая правит копию, проверяет синтаксис перед установкой и держит блокировку, чтобы два администратора не затёрли правки друг друга. Логика одна: правило, которое может переписать кто угодно, ничего не ограничивает, поэтому лучше упасть, чем сделать вид, что политика соблюдается.

Аутентификация

Убедившись, что пользователю в принципе разрешено то, что он просит, инструмент требует доказать, что за клавиатурой тот, за кого он себя выдаёт, — как правило, паролем. Здесь проходит первая крупная архитектурная развилка.

На Linux и sudo, и OpenDoas, и sudo-rs аутентифицируются через PAM: открывают сессию к сервису sudo (/etc/pam.d/sudo) и отдают проверку стеку модулей — pam_unix сверяет пароль с /etc/shadow, pam_faillock считает неудачные попытки, дальше по конфигурации могут стоять модули для LDAP, Kerberos, U2F. Это значит, что доверенная кодовая база инструмента не заканчивается на нём самом: она включает весь стек PAM, загружаемый в адресное пространство процесса с euid=0. Гибко и ценой размера.

На OpenBSD такого стека нет. Оригинальный doas использует BSD authentication — механизм, где проверка вынесена в отдельные программы-аутентификаторы, запускаемые под собственными правами, а не загружаемые в процесс. Это выбор той же школы, что и минимализм самого doas: чем меньше кода исполняется с euid=0, тем меньше того, что может пойти не так.

Кэш аутентификации

Спрашивать пароль на каждую команду невыносимо, поэтому успешную аутентификацию кэшируют на несколько минут. Как именно — третья точка расхождения, и она объясняет, почему persist не работает на FreeBSD.

sudo хранит отметки времени в файлах под /run/sudo/ts/ — по каталогу на пользователя; запись по умолчанию привязана к терминалу (TS_TTY), так что сессии в разных tty аутентифицируются раздельно, а варианты TS_GLOBAL и TS_PPID меняют гранулярность. Каталог лежит на tmpfs, поэтому кэш обнуляется при перезагрузке. OpenDoas делает то же самое собственными timestamp-файлами.

Оригинальный doas файлов не ведёт вовсе. Отметку об успешной аутентификации он хранит в ядре и обращается к ней через ioctl TIOCCHKVERAUTH/TIOCSETVERAUTH на управляющем терминале. Таких ioctl нет в ядре FreeBSD — поэтому persist в порту security/doas не работает механически, а не по недосмотру сборки (подробности — в разделе про установку).

Сброс привилегий и запуск

Пройдя и политику, и аутентификацию, инструмент строит целевые права и передаёт им управление: setgid/setresgid и setgroups на группы целевого пользователя, затем setuid/setresuid на его UID (для root — 0), строит окружение (о нём отдельный раздел — оно тоже часть модели угроз) и делает execve запрошенной команды. Порядок важен: группы сбрасывают до UID, иначе после смены UID уже нет прав менять группы. Ошибку любого из этих вызовов нельзя игнорировать — команда, запущенная с не полностью сброшенными привилегиями, и есть эскалация: ровно этот класс — CVE-2026-35535 в sudo, разобранный ниже. С этого момента setuid-обёртки в цепочке больше нет — работает обычный процесс с правами целевого пользователя.

Откуда берётся разница моделей

Механизм общий, но объём кода, исполняемого с euid=0, у трёх реализаций разный — и именно он определяет attack surface, а не абстрактная «сложность». sudo несёт подключаемую архитектуру (политика и логирование — сменные плагины), I/O-логирование, сетевой сервер журналов, LDAP; всё это код в процессе root. doas — один статический разбор простого языка политики плюс BSD auth или PAM, и сознательно ничего сверх. sudo-rs повторяет модель sudo (тот же sudoers, тот же PAM), но написан на Rust, убирающем целый класс ошибок работы с памятью из того самого кода, что исполняется с euid=0.

Отсюда прямой вывод к сравнению: аргумент «меньше небезопасного кода — меньше дыр», которым обычно продают doas, теперь предъявляет и sudo-rs, не отказываясь при этом от совместимости с sudoers. Видно и его границу: у sudo-rs стек PAM остаётся кодом на C в том же адресном пространстве, то есть memory safety покрывает не всё окно euid=0.

Три реализации, а не две

sudo Тодда Миллера — оригинал на C, живущий с конца 1980-х и ставший стандартом де-факто. Это не утилита, а фреймворк управления доступом: подключаемые плагины политики и логирования, гранулярные правила в sudoers, I/O-логирование с воспроизведением (sudoreplay), сетевой сервер журналов (sudo_logsrvd), хранение правил в LDAP. Всё это — код, исполняемый с euid=0, и цена гибкости.

doas — минималистичный ответ из OpenBSD (Тед Унангст, 2015). Один простой язык политики (правило последнего совпадения, deny по умолчанию), никаких плагинов, на OpenBSD — BSD auth вместо PAM. На порядок меньше кода; цена — отсутствие всего перечисленного у sudo: ни I/O-логов, ни делегирования, ни LDAP.

sudo-rs — переписанный на Rust sudo (разработку Prossimo/ISRG профинансировал в декабре 2022 силами Tweede Golf и Ferrous Systems, первый стабильный релиз — август 2023; с июня 2024 проект живёт в Trifecta Tech Foundation). Совместим с sudoers и работает через PAM, то есть даёт модель sudo, но без целого класса ошибок работы с памятью — того самого, что годами кормил CVE в оригинале. Часть возможностей не реализована намеренно: I/O-логирование и sudoreplay, sudo_logsrvd/sudo_sendlog, sudoers.ldap (LDAP — только через PAM). С Ubuntu 25.10 это поставщик sudo по умолчанию, в 26.04 LTS — штатное умолчание; классический sudo уехал в пакет sudo.ws. То есть на свежей Ubuntu слово «sudo» уже означает другую программу.

Практический подвох при переходе на sudo-rs — другой текст приглашения пароля. Классический sudo печатает [sudo] password for <user>:, sudo-rs — [sudo: authenticate] <method>:. Expect-скрипты и прочая автоматизация, ловящая приглашение по регэкспу, молча уходят в таймаут: ожидаемая строка не появляется. Лечится переписыванием шаблона под новый формат либо запуском с --prompt "", отключающим сравнение приглашения.

Когда что использовать

Выбор решается не противопоставлением «фреймворк против одной команды», а тем, кто будет чинить найденную в коде дыру и сколько этого кода вообще исполняется от root. Ответ поэтому разный на разных системах.

На FreeBSD и OpenBSD doas — нормальный выбор. В OpenBSD он в базе, во FreeBSD security/doas сопровождается в дереве портов автором самого форка. Одного администратора, домашнего сервера, лабораторной VM и embedded это покрывает; цена — отсутствие persist в security/doas, то есть пароль на каждую команду (механическая причина — в разделах про кэш аутентификации и установку). Если такой режим неприемлем, вариантов два: security/opendoas с работающим кэшем, но замороженным апстримом, или sudo.

На Linux по умолчанию берут sudo — и это всё чаще sudo-rs. Довод в пользу doas на Linux — меньше небезопасного кода — теперь перекрывается sudo-rs: memory safety без отказа от экосистемы sudoers, активный апстрим и место штатного поставщика в Ubuntu. Пакет же doas (opendoas) в Debian, Ubuntu, Arch и Alpine — это OpenDoas 6.8.2 без единого коммита с февраля 2022 года и с незакрытой CVE-2023-28339 (подробности — в «Безопасности»). Выигрыш в attack surface здесь оплачивается тем, что следующую находку закрывать будет некому, и для системы, которую обновляют пакетным менеджером, это плохая сделка. Взять doas на Linux осмысленно, только если вы готовы собирать живой форк Джесси Смита сами: в репозиториях мейнстрим-дистрибутивов его нет, только AUR, SlackBuilds и Ravenports.

sudo (в любой из двух реализаций) обязателен там, где несколько администраторов, гранулярные права, делегирование и аудит: doas этого не умеет и не пытается. Но если нужны именно I/O-логи, sudoreplay или правила в LDAP — это классический sudo, а не sudo-rs, где их пока нет.

Пространство выбора шире трёх setuid-утилит. systemd 256+ несёт run0 — обёртку над systemd-run, запускающую команду от root вообще без setuid: привилегированный процесс порождает PID 1 по запросу с авторизацией через polkit, поэтому целого класса setuid-эскалаций у неё нет по построению. Тот же polkit стоит за pkexec (у которого, впрочем, была своя громкая setuid-дыра — PwnKit, CVE-2021-4034). Ни run0, ни pkexec не совместимы с sudoers и заголовком этой статьи не покрыты, но при проектировании доступа их стоит держать в виду.

Установка

FreeBSD

pkg install sudo
pkg install doas        # либо opendoas — они конфликтуют

В портах два конкурирующих варианта doas, объявленных конфликтующими, — ставится только один. Ни один из них не является «тем самым doas из базы OpenBSD»: оба сторонние переносы, и различаются они не происхождением, а тем, жив ли апстрим. security/doas (6.4) собирается из форка Джесси Смита на Codeberg — тег 6.4 поставлен в марте 2026 года, коммиты в апстриме продолжаются (последние — в июле 2026), и порт сопровождает сам автор форка. security/opendoas (6.8.2) — форк Duncaen, остановившийся в начале 2022 года.

Кэш пароля (persist) на FreeBSD умеет только opendoas — механическую причину (недостающие ioctl TIOCCHKVERAUTH/TIOCSETVERAUTH) разбирает раздел «Кэш аутентификации». В форке Смита этот код собирается только под USE_BSD_AUTH, а doas.conf(5) прямо сообщает, что persist работает только на OpenBSD. OpenDoas взамен ведёт собственные timestamp-файлы: порт собирается с --with-timestamp и накладывает патч, добавляющий их поддержку на FreeBSD.

Linux (Debian/Ubuntu)

apt install sudo
apt install doas

На Debian и старых Ubuntu sudo — классическая реализация Миллера. На Ubuntu 25.10 и новее sudo — это уже sudo-rs (см. «Три реализации, а не две»); классический sudo при необходимости ставится из пакета sudo.ws.

Linux (Arch)

pacman -S sudo opendoas

Базовая настройка

sudo

Редактировать конфиг только через visudo:

visudo

Минимальное правило:

%wheel ALL=(ALL:ALL) ALL

или для конкретного пользователя:

username ALL=(ALL:ALL) ALL

Добавить пользователя в группу wheel:

usermod -aG wheel username

На FreeBSD usermod нет, там то же самое делает pw:

pw groupmod wheel -m username

Группа wheel — умолчание FreeBSD, Arch и RHEL, но «умолчание» означает в этих системах разное, и разница ровно в том, заработает ли всё сразу после добавления в группу. В Fedora и RHEL строка %wheel ALL=(ALL) ALL в поставляемом /etc/sudoers раскомментирована, и членства действительно достаточно. В Arch и в порту sudo на FreeBSD едет апстримный sudoers, где та же строка закомментирована: группа существует, прав она не даёт, правило надо включить руками через visudo. В Debian и Ubuntu ту же роль играет группа sudo, правило для которой уже прописано в поставляемом sudoers.

doas

Конфиг: /etc/doas.conf (на FreeBSD — /usr/local/etc/doas.conf).

Минимальная конфигурация:

permit :wheel

С кэшированием пароля:

permit persist :wheel

На FreeBSD это правило разберётся без ошибки, но пароль всё равно будет спрашиваться каждый раз, если стоит security/doas, — см. «Кэш аутентификации».

Права на файл:

chmod 600 /etc/doas.conf

Почему это не ритуал, а условие запуска — в разделе «Разбор политики»: doas делает fstat и отказывается работать, если файл доступен на запись группе или всем или не принадлежит root.

Окружение

Самое частое практическое расхождение между инструментами — не синтаксис правил, а судьба переменных окружения: отсюда пропавший PATH, проигнорированный EDITOR и не сработавшие прокси-переменные.

sudo с флагом env_reset (включён по умолчанию) собирает команде минимальное окружение из TERM, PATH, HOME, MAIL, SHELL, LOGNAME, USER и SUDO_*, а затем возвращает в него то, что перечислено в списках env_keep и env_check. Отдельно от этого работает secure_path: если он задан, его значение подменяет PATH целиком. В апстримном sudo secure_path выключен, а Debian, Ubuntu и Fedora включают его в поставляемом sudoers — именно поэтому под sudo внезапно не находится бинарник из ~/.local/bin. Чинится это не экспортом переменной перед командой, а строкой Defaults secure_path=... или Defaults env_keep += "EDITOR http_proxy" в sudoers.

doas делает то же самое жёстче и без списков на двадцать имён. Он всегда строит окружение заново: HOME, LOGNAME, PATH, SHELL, USER и umask выставляются по целевому пользователю, DOAS_USER — по исходному, из прежнего окружения наследуются только DISPLAY и TERM, остальное исчезает. Расширяют это двумя способами. setenv { EDITOR http_proxy } в правиле пропускает конкретные переменные (синтаксис допускает и присваивание VAR=value, и удаление через -VAR); keepenv сохраняет окружение целиком — вариант для запуска GUI-приложений от root, о небезопасности которого предупреждает даже pkg-message порта. Значение PATH для целевого пользователя у doas зашито на этапе сборки и правилами не меняется вовсе: в порту FreeBSD это /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin. Аналога secure_path, который можно поправить в конфиге, здесь нет — как и всей идеи конфигурируемого окружения.

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

sudo — ограничение команд

Разрешить пользователю перезапуск nginx:

username ALL=(root) NOPASSWD: /usr/sbin/service nginx restart

doas — разрешить только одну команду

permit username as root cmd service args nginx restart

doas — запрет shell root

deny username cmd sh
deny username cmd bash
deny username cmd zsh

Порядок правил важен: действие определяет последнее совпавшее правило, а не первое, поэтому deny имеет смысл только после разрешающего permit. Если не совпало ни одно правило, доступ запрещён.

doas — разрешить только пакетный менеджер

permit username as root cmd pkg

Безопасность

Тезис «меньше кода — меньше дыр» в последние годы подтвердился с обеих сторон. В sudo 1.9.17p1 (июнь 2025) закрыли две локальные эскалации: CVE-2025-32462 — опция -h/--host работала не только вместе с -l, из-за чего имя хоста в правиле sudoers переставало что-либо ограничивать (баг прожил в коде начиная с 1.8.8), и CVE-2025-32463 — через -R/--chroot подсовывался собственный /etc/nsswitch.conf, и sudo грузил произвольную разделяемую библиотеку от root, даже если у пользователя вовсе не было правил. Chroot после этого объявлен устаревшим и будет удалён. Весной 2026 добавился CVE-2026-35535: сбой setuid/setgid/setgroups при сбросе привилегий перед запуском mailer'а не считался фатальной ошибкой — обе фигурирующие здесь подсистемы, chroot и рассылка почты, у doas отсутствуют как класс. Развязки у этого CVE на момент сверки нет: последний выпуск на sudo.ws — по-прежнему 1.9.17p2, исправление живёт в git отдельным коммитом (3e474c2), а до пользователей доходит патчами дистрибутивов — Fedora несёт его как 0001-cve-2026-35535.patch, Ubuntu закрыла в 1.9.17p2-1ubuntu1.1 и бэкпортах для 24.04 и 22.04. Отсюда практический вывод: обновлять пакет дистрибутива, а не собирать sudo из апстримного тарбола, который сейчас старше исправления.

У doas список короче, но не пуст, и главная его проблема — заброшенность. CVE-2023-28339 — эскалация через общий с исходной сессией терминал: ioctl TIOCSTI проталкивает символы во входной поток чужого tty, и оставшийся у непривилегированного процесса дескриптор терминала превращается в канал ввода команд root. В коде OpenDoas она не закрыта и закрыта не будет: последний релиз 6.8.2 датирован январём 2022 года, последний коммит — февралём 2022, и дистрибутивы возят именно эту версию.

Спасает сторона ядра. В OpenBSD TIOCSTI убран начиная с 6.2. В Linux с версии 6.2 есть рантайм-переключатель dev.tty.legacy_tiocsti, умолчание которому задаёт CONFIG_LEGACY_TIOCSTI (в апстриме — y, то есть историческое поведение разрешено), а дистрибутив вправе собрать ядро с n: Debian сделал это с ядра 6.4.4-1, после чего security team помечает opendoas в trixie как not-affected. Проверяется и переключается это одной строкой:

sysctl dev.tty.legacy_tiocsti          # 1 — старое поведение разрешено
sysctl -w dev.tty.legacy_tiocsti=0     # запретить

Стоит понимать, чем именно это является: защитой от последствий одной конкретной находки, а не от причины. Апстрима, который закроет следующую, у OpenDoas нет — и в вердикте выше это весит больше, чем разница в размере кода. Тот же довод разворачивается и против sudo как класса: memory safety у sudo-rs не закрывает логические баги вроде CVE-2025-32462, но снимает именно тот пласт, что у оригинала не иссякает, — ошибки работы с памятью в коде, исполняемом с euid=0.

Источники

• execve(2) — обработка бита setuid при exec: effective UID поднимается до владельца файла, копируется в saved set-user-ID; игнорируется при nosuid, no_new_privs, ptrace
• sudoers_timestamp(5) — кэш аутентификации в /run/sudo/ts, типы записи TS_TTY (умолчание), TS_GLOBAL, TS_PPID
• Релизы sudo — стабильная ветка 1.9.x, состав 1.9.17, 1.9.17p1 и 1.9.17p2
• sudoers(5) — синтаксис правил, теги NOPASSWD и CHROOT, флаг env_reset и его список переменных, secure_path («disabled by default»)
• sudoers.in из исходников sudo — правило %wheel в апстримном образце закомментировано
• sudoers из пакета sudo в Fedora — там же %wheel ALL=(ALL) ALL раскомментировано и задан Defaults secure_path=... (в апстриме оба выключены); в sudo.spec — патч 0001-cve-2026-35535.patch
• doas.conf(5), OpenBSD — язык политики: permit/deny, persist, nopass, nolog, keepenv, setenv, as, cmd, args, правило последнего совпадения и deny по умолчанию
• doas Джесси Смита — живой портативный форк: тег 6.4 (март 2026), проверка прав на doas.conf в doas.c, persist под USE_BSD_AUTH через TIOCCHKVERAUTH/TIOCSETVERAUTH, оговорка «persist is not available on Linux or FreeBSD» в doas.conf.5
• doas(1) из OpenDoas — состав окружения по умолчанию: HOME, LOGNAME, PATH, SHELL, USER, DOAS_USER, наследуемые DISPLAY и TERM
• CVE-2025-32462: sudo local privilege escalation via host option — затронуты 1.8.8–1.9.17, исправлено в 1.9.17p1
• CVE-2025-32463: sudo local privilege escalation via chroot option — затронуты 1.9.14–1.9.17, исправлено в 1.9.17p1, chroot объявлен устаревшим
• CVE-2026-35535 — сброс привилегий перед mailer'ом, sudo вплоть до 1.9.17p2, исправление — коммит 3e474c2
• Стабильный релиз sudo — текущий выпуск 1.9.17p2, релиза с исправлением CVE-2026-35535 пока нет
• CVE-2026-35535 в Ubuntu — закрыто пакетами 1.9.17p2-1ubuntu1.1, 1.9.15p5-3ubuntu5.24.04.2, 1.9.9-1ubuntu2.6
• CVE-2023-28339 в трекере безопасности Debian — OpenDoas вплоть до 6.8.2, «TIOCSTI can be made unavailable in the Linux kernel 6.2 and later», trixie помечен not-affected после отключения TIOCSTI в ядре 6.4.4-1
• drivers/tty/Kconfig — LEGACY_TIOCSTI — опция появилась в 6.2, умолчание y, рантайм-переключатель dev.tty.legacy_tiocsti
• OpenBSD 6.2 changelog — «The TIOCSTI tty ioctl has been removed»; в csh(1) и mail(1) I/O-циклы переписаны под удаление
• sudo-rs — Trifecta Tech Foundation и Prossimo: memory-safe sudo/su — переписывание на Rust ради устранения memory-safety-ошибок, финансирование с декабря 2022, первый стабильный релиз (август 2023), переход в Trifecta Tech Foundation
• Ubuntu 25.10 — release notes — sudo-rs становится поставщиком sudo по умолчанию начиная с 25.10; классический sudo остаётся доступен отдельно
• Ubuntu 26.04 LTS — release notes — sudo-rs как штатное умолчание, переименование классического sudo в sudo.ws
• sudo-rs — Ubuntu Server documentation — что не реализовано (I/O-логи, sudoreplay, sudo_logsrvd, sudoers.ldap); формат приглашения [sudo: authenticate] <method>: против [sudo] password for <user> и обход через --prompt ""
• OpenDoas — портативный форк, релиз 6.8.2 и состояние апстрима
• run0, systemd — запуск от root без setuid: команду порождает PID 1 (systemd-run) с авторизацией через polkit
• PwnKit: CVE-2021-4034 в pkexec (Qualys) — локальная эскалация в setuid-хелпере polkit
• FreeBSD ports: security/doas и security/opendoas — версии портов, конфликт между ними, MASTER_SITES на Codeberg у первого, --with-timestamp и патч FreeBSD-timestamp у второго, GLOBAL_PATH целевого пользователя

Связанные заметки

• FreeBSD — безопасность — повышение привилегий в общей модели hardening FreeBSD
• Linux — безопасность: hardening, SELinux/AppArmor — права, capabilities и аудит в Linux
• FreeBSD — архитектура и философия — doas родом из OpenBSD, актуально для BSD-систем
• Linux — пользователи, группы, PAM и systemd-logind — стек PAM, через который проходят sudo, sudo-rs и OpenDoas