--- tags: [security, tooling] verified: 2026-09-05 --- # sudo, doas и sudo-rs — повышение привилегий: механизм и сравнение ## Назначение `sudo` и `doas` — утилиты повышения привилегий в Unix-подобных системах: они позволяют непривилегированному пользователю выполнить команду от имени другого (обычно root), не открывая root-сессию. Обе решают эту задачу одним и тем же механизмом ядра — setuid-бинарём, — а различаются тем, что делают между получением прав root и запуском команды. С 2023 года участников стало трое: `sudo-rs`, переписанный на Rust sudo, с Ubuntu 25.10 занял место поставщика `sudo` по умолчанию и бьёт ровно в тот аргумент, ради которого выбирали doas. Поэтому статья сначала разбирает общий механизм, а затем — где реализации расходятся и что из этого следует для выбора. --- ## Архитектура повышения привилегий Механизм у всех трёх общий, и понимать его нужно раньше сравнения: аргумент «меньше небезопасного кода — меньше дыр» проверяется только тем, что именно этот код делает с euid=0. ![Конвейер повышения привилегий: execve setuid-бинаря поднимает euid до нуля, дальше идут разбор политики, аутентификация и сброс привилегий; весь этот отрезок исполняется от root, окно закрывает setuid перед запуском команды](./assets/sudo-vs-doas-pipeline.svg) Дальше разделы разбирают этот конвейер по шагам — в том же порядке. ### setuid-бинарь и execve И `sudo`, и `doas` установлены с битом setuid и владельцем root: ```bash $ 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. ![Состав кода, исполняемого с euid=0, у трёх реализаций: у sudo — плагины, I/O-логирование, logsrvd, LDAP и стек PAM на C; у doas — только разбор своего конфига, а на OpenBSD аутентификация вынесена в отдельный процесс; у sudo-rs — модель sudo на Rust, но стек PAM остаётся кодом на C внутри процесса](./assets/sudo-vs-doas-euid0-surface.svg) Отсюда прямой вывод к сравнению: аргумент «меньше небезопасного кода — меньше дыр», которым обычно продают 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 (Миллер) | doas | sudo-rs | | --- | --- | --- | --- | | Язык | C | C | Rust | | Аутентификация | PAM (Linux) | BSD auth (OpenBSD), PAM (OpenDoas) | PAM | | Язык политики | sudoers + плагины | doas.conf, встроенный | sudoers | | I/O-логи, `sudoreplay`, logsrvd | есть | нет | нет | | Правила в LDAP | `sudoers.ldap` | нет | нет (LDAP через PAM) | | Memory safety | нет | нет | да | | Апстрим | активный | зависит от форка (см. установку) | активный | Практический подвох при переходе на sudo-rs — другой текст приглашения пароля. Классический sudo печатает `[sudo] password for :`, sudo-rs — `[sudo: authenticate] :`. 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 ```sh 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) ```bash apt install sudo apt install doas ``` На Debian и старых Ubuntu `sudo` — классическая реализация Миллера. На Ubuntu 25.10 и новее `sudo` — это уже `sudo-rs` (см. «Три реализации, а не две»); классический sudo при необходимости ставится из пакета `sudo.ws`. ### Linux (Arch) ```bash pacman -S sudo opendoas ``` --- ## Базовая настройка ### sudo Редактировать конфиг только через `visudo`: ```bash visudo ``` Минимальное правило: ```conf %wheel ALL=(ALL:ALL) ALL ``` или для конкретного пользователя: ```conf username ALL=(ALL:ALL) ALL ``` Добавить пользователя в группу wheel: ```bash usermod -aG wheel username ``` На FreeBSD `usermod` нет, там то же самое делает `pw`: ```sh 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`). Минимальная конфигурация: ```conf permit :wheel ``` С кэшированием пароля: ```conf permit persist :wheel ``` На FreeBSD это правило разберётся без ошибки, но пароль всё равно будет спрашиваться каждый раз, если стоит `security/doas`, — см. «Кэш аутентификации». Права на файл: ```bash 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: ```conf username ALL=(root) NOPASSWD: /usr/sbin/service nginx restart ``` ### doas — разрешить только одну команду ```conf permit username as root cmd service args nginx restart ``` ### doas — запрет shell root ```conf deny username cmd sh deny username cmd bash deny username cmd zsh ``` Порядок правил важен: действие определяет последнее совпавшее правило, а не первое, поэтому `deny` имеет смысл только после разрешающего `permit`. Если не совпало ни одно правило, доступ запрещён. ### doas — разрешить только пакетный менеджер ```conf 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. Проверяется и переключается это одной строкой: ```bash 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)](https://man7.org/linux/man-pages/man2/execve.2.html) — обработка бита setuid при exec: effective UID поднимается до владельца файла, копируется в saved set-user-ID; игнорируется при `nosuid`, `no_new_privs`, ptrace - [sudoers_timestamp(5)](https://man7.org/linux/man-pages/man5/sudoers_timestamp.5.html) — кэш аутентификации в `/run/sudo/ts`, типы записи `TS_TTY` (умолчание), `TS_GLOBAL`, `TS_PPID` - [Релизы sudo](https://github.com/sudo-project/sudo/releases) — стабильная ветка 1.9.x, состав 1.9.17, 1.9.17p1 и 1.9.17p2 - [sudoers(5)](https://www.sudo.ws/docs/man/sudoers.man/) — синтаксис правил, теги `NOPASSWD` и `CHROOT`, флаг `env_reset` и его список переменных, `secure_path` («disabled by default») - [sudoers.in из исходников sudo](https://github.com/sudo-project/sudo/blob/main/plugins/sudoers/sudoers.in) — правило `%wheel` в апстримном образце закомментировано - [sudoers из пакета sudo в Fedora](https://src.fedoraproject.org/rpms/sudo/blob/rawhide/f/sudoers) — там же `%wheel ALL=(ALL) ALL` раскомментировано и задан `Defaults secure_path=...` (в апстриме оба выключены); в `sudo.spec` — патч `0001-cve-2026-35535.patch` - [doas.conf(5), OpenBSD](https://man.openbsd.org/doas.conf.5) — язык политики: `permit`/`deny`, `persist`, `nopass`, `nolog`, `keepenv`, `setenv`, `as`, `cmd`, `args`, правило последнего совпадения и deny по умолчанию - [doas Джесси Смита](https://codeberg.org/thejessesmith/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](https://github.com/Duncaen/OpenDoas/blob/master/doas.1) — состав окружения по умолчанию: `HOME`, `LOGNAME`, `PATH`, `SHELL`, `USER`, `DOAS_USER`, наследуемые `DISPLAY` и `TERM` - [CVE-2025-32462: sudo local privilege escalation via host option](https://www.openwall.com/lists/oss-security/2025/06/30/2) — затронуты 1.8.8–1.9.17, исправлено в 1.9.17p1 - [CVE-2025-32463: sudo local privilege escalation via chroot option](https://www.openwall.com/lists/oss-security/2025/06/30/3) — затронуты 1.9.14–1.9.17, исправлено в 1.9.17p1, chroot объявлен устаревшим - [CVE-2026-35535](https://github.com/advisories/GHSA-g5fc-f834-rcr2) — сброс привилегий перед mailer'ом, sudo вплоть до 1.9.17p2, исправление — коммит `3e474c2` - [Стабильный релиз sudo](https://www.sudo.ws/releases/stable/) — текущий выпуск 1.9.17p2, релиза с исправлением CVE-2026-35535 пока нет - [CVE-2026-35535 в Ubuntu](https://ubuntu.com/security/CVE-2026-35535) — закрыто пакетами `1.9.17p2-1ubuntu1.1`, `1.9.15p5-3ubuntu5.24.04.2`, `1.9.9-1ubuntu2.6` - [CVE-2023-28339 в трекере безопасности Debian](https://security-tracker.debian.org/tracker/CVE-2023-28339) — 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](https://github.com/torvalds/linux/blob/master/drivers/tty/Kconfig) — опция появилась в 6.2, умолчание `y`, рантайм-переключатель `dev.tty.legacy_tiocsti` - [OpenBSD 6.2 changelog](https://www.openbsd.org/62.html) — «The TIOCSTI tty ioctl has been removed»; в csh(1) и mail(1) I/O-циклы переписаны под удаление - [sudo-rs — Trifecta Tech Foundation](https://trifectatech.org/projects/sudo-rs/) и [Prossimo: memory-safe sudo/su](https://www.memorysafety.org/initiative/sudo-su/) — переписывание на Rust ради устранения memory-safety-ошибок, финансирование с декабря 2022, первый стабильный релиз (август 2023), переход в Trifecta Tech Foundation - [Ubuntu 25.10 — release notes](https://documentation.ubuntu.com/release-notes/25.10/) — `sudo-rs` становится поставщиком `sudo` по умолчанию начиная с 25.10; классический sudo остаётся доступен отдельно - [Ubuntu 26.04 LTS — release notes](https://documentation.ubuntu.com/release-notes/26.04/summary-for-lts-users/) — `sudo-rs` как штатное умолчание, переименование классического sudo в `sudo.ws` - [sudo-rs — Ubuntu Server documentation](https://ubuntu.com/server/docs/reference/other-tools/sudo-rs/) — что не реализовано (I/O-логи, `sudoreplay`, `sudo_logsrvd`, `sudoers.ldap`); формат приглашения `[sudo: authenticate] :` против `[sudo] password for ` и обход через `--prompt ""` - [OpenDoas](https://github.com/Duncaen/OpenDoas) — портативный форк, релиз 6.8.2 и состояние апстрима - [run0, systemd](https://www.freedesktop.org/software/systemd/man/latest/run0.html) — запуск от root без setuid: команду порождает PID 1 (`systemd-run`) с авторизацией через polkit - [PwnKit: CVE-2021-4034 в pkexec (Qualys)](https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt) — локальная эскалация в setuid-хелпере polkit - FreeBSD ports: [security/doas](https://github.com/freebsd/freebsd-ports/tree/main/security/doas) и [security/opendoas](https://github.com/freebsd/freebsd-ports/tree/main/security/opendoas) — версии портов, конфликт между ними, `MASTER_SITES` на Codeberg у первого, `--with-timestamp` и патч FreeBSD-timestamp у второго, `GLOBAL_PATH` целевого пользователя --- ## Связанные заметки - [FreeBSD — безопасность](./freebsd-security-hardening.md) — повышение привилегий в общей модели hardening FreeBSD - [Linux — безопасность: hardening, SELinux/AppArmor](./linux-security-hardening.md) — права, capabilities и аудит в Linux - [FreeBSD — архитектура и философия](./freebsd.md) — doas родом из OpenBSD, актуально для BSD-систем - [Linux — пользователи, группы, PAM и systemd-logind](./linux-users-pam.md) — стек PAM, через который проходят sudo, sudo-rs и OpenDoas