АссистентНовый вопросИсторияОбласти знаний
Партнёрские проектыСпецпроектыСтать автором
Сменить язык
О РУВИКИ

Сравнение функций авторизации привилегий

Экспертиза РАН

Logo-ran.pngLogo-ran-black.png
Проводится экспертиза
Российской академией наук
Подробнее
Times2.svg

Экспертиза РАН

Arrow-Right.png
Logo-ran.png
Проводится экспертиза
Российской академией наук
Подробнее

Сравнение функций авторизации привилегий — это обзор различных способов, с помощью которых современные компьютерные операционные системы реализуют контроль и подтверждение действий, выполняемых с повышенными полномочиями. Данные функции препятствуют работе вредоносного программного обеспечения, не допускают несанкционированного повышения привилегий и позволяют гарантировать безопасность системы[1]. В операционных системах, изначально не оснащённых такими мерами безопасности, например, в DOS, Windows до серии Windows NT, CP/M-80, а также в старых версиях Mac OS до Mac OS X, существовал только один уровень пользователя, обладавший всеми возможностями без каких-либо ограничений.

История

С появлением разделения контекстов выполнения стало возможным: хранить приватные файлы для разных пользователей, обеспечивать одновременную работу нескольких человек за одним компьютером, защищать систему как от вредоносных программ, так и от действий недоброжелательных пользователей. Первая мультипользовательская защищённая система — Multics, разработка которой началась в 1960-х годах; однако только с появлением UNIX, BSD, Linux и Windows NT в конце 1980-х — начале 1990-х годов многозадачные системы с безопасностью процессов стали доступны на ПК архитектуры x86.

Введение в реализации

Microsoft Windows

Окно запроса контроля учётных записей Контроль учётных записей пользователей (англ. User Account Control, UAC):
Система, входящая в состав Windows Vista и всех последующих версий Microsoft Windows, UAC предлагает пользователю подтвердить повышение прав при попытке выполнить действие администратора[2].
Команда runas (англ. Runas):
Инструмент командной строки и элемент контекстного меню, появившийся в Windows 2000, который позволяет запускать программу, апплет панели управления или оснастку Microsoft Management Console от имени другого пользователя[3]. Runas использует службу Windows "Вторичный вход" (Secondary Login), представленную в Windows 2000[4], которая обеспечивает возможность приложений, запущенных от имени другого пользователя, взаимодействовать с рабочим столом вошедшего в систему пользователя. Это необходимо для поддержки перетаскивания, буфера обмена и других функций интерактивного сеанса.
sudo:
В версии Windows 11, начиная с версии 24H2, доступно средство sudo для Windows, реализующее аналогичные механизмы повышения прав. По умолчанию не включено, возможно включение через окно настроек разработчика[5].

macOS

Окно аутентификации В macOS реализовано диалоговое окно Authenticate, в котором пользователю необходимо ввести свой пароль для подтверждения административных действий. Является по сути графическим интерфейсом к команде sudo.

Unix и Unix-подобные системы

PolicyKit в GNOME PolicyKit (pkexec):
Механизм авторизации привилегий, не зависящий от используемой графической среды, внедрённый, в частности, в GNOME[6]. В отличие от ранних систем приложения, использующие PolicyKit, не исполняются с правами выше текущего пользователя, а лишь отправляют запрос демону PolicyKit — единственному процессу, работающему с полномочиями суперпользователя.
su su:
Классическая консольная команда для Unix — позволяет переключить текущий терминал на другой аккаунт, введя имя пользователя и его пароль. Если имя пользователя не указано, по умолчанию используется суперпользователь ("root"), что обеспечивает быстрый доступ к административной оболочке. По завершении работы командой exit пользователь возвращается в свой сеанс.
sudo sudo:
Появилась около 1980 года[7]. По сравнению с su, sudo — более гибкая консольная утилита: позволяет запускать отдельные команды с правами root согласно заданной политике, не требуя ввода пароля самого root[8].
gksudo GKSu и GKsudo:
Gtk/GTK+ графические интерфейсы к командам su и sudo[9]. GKsu автоматически вызывается, если приложению необходимы повышенные привилегии. Разрабатывается замена — "gksu PolicyKit", работающая на базе PolicyKit и ориентированная на среды GNOME[10].
kdesu kdesu:
Qt-графический интерфейс к команде su для среды KDE[11].
kdesudo kdesudo:
Qt-графическая оболочка к sudo, пришедшая на замену kdesu в Kubuntu, начиная с версии 7.10[12].
Ktsuss ktsuss:
Название образовано от англ. "keep the su simple, stupid" — "оставь su простым". Проект с акцентом на простоту и уверенность в корректной работе; реализует графическую версию su.
beesu beesu:
Графическая оболочка к su, заменившая gksu в дистрибутивах на базе Red Hat (прежде всего RHEL и Fedora)[13].
doas:
Утилита, пришедшая на замену sudo в OpenBSD начиная с версии 5.8 (октябрь 2015 года).

Вопросы безопасности

Подделка/перехват пользовательского ввода

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

  • Использование терминальных клиентов (отдельных или внутри графической среды): и su, и sudo работают в терминале, где уязвимы для атак, основанных на поддельном вводе. В случае работы вне многозадачной среды (только одна консоль на одного пользователя) эта угроза неактуальна. Однако под графическим окружением пользователь должен сам предотвращать манипуляции или перехват вводимых данных со стороны вредоносных программ.
  • Использование графической среды, глубоко интегрированной с ОС: Обычно рабочий стол блокирует все каналы ввода до появления окна аутентификации, чтобы невозможно было перехватить, изменить или подделать ввод:
  • PolicyKit (GNOME) — перенаправляет весь ввод с клавиатуры и мыши напрямую в X-сервер; другие среды могут использовать собственные методы.
  • gksudo — по умолчанию "блокирует" клавиатуру, мышь и фокус окна[14], не позволяя ничего кроме реального ввода пользователя.
  • UAC (Windows) — по умолчанию работает в режиме "Безопасного рабочего стола", не позволяя программам имитировать клик по кнопке "Разрешить" или вмешиваться в диалог подтверждения[15]. Рабочий стол при этом тускнеет и остаётся недоступным для взаимодействия.
Если работа gksudo в режиме блокировки или UAC с включённым безопасным режимом будет скомпрометирована, вредоносная программа сможет получить пароль администратора посредством кейлоггера или сымитировать клик мыши (в случае UAC с правами администратора). Поэтому голосовое управление запрещено во время появления подобных диалогов. Кроме того, если запуск gksu осуществляется без специальных привилегий, злоумышленник может записывать ввод с помощью, например, утилиты strace[16] (в последующих версиях ядра ptrace был ограничен[17]).

Поддельные окна аутентификации

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

undefined
  • UAC может быть настроен так, чтобы требовать от пользователя нажатия Ctrl+Alt+Del (так называемая "безопасная последовательность внимания") перед вводом данных. Только сама система Windows может корректно обработать эту комбинацию, и подобная мера защищает от подделки диалоговых окон[18]. Если диалог поддельный, при попытке воспользоваться Ctrl+Alt+Del пользователь попадёт на стандартный служебный экран, тем самым разоблачая попытку фишинга пароля.
  • В GNOME PolicyKit генерирует разные диалоговые окна в зависимости от конфигурации, например, для систем с поддержкой отпечатков пальцев или без неё. Приложения не знают, какой конкретно диалог будет показан, и не могут его качественно подделать[19].

Вопросы удобства использования

Разделение учётных записей администратора

  • su требует от пользователя знания пароля как обычной учётной записи, так и отдельной — с административными привилегиями (root).
  • sudo, kdesu и gksudo — используют иной подход: пользователи заранее наделяются набором прав для выполнения определённых задач, но каждый запуск таких приложений требует явного подтверждения (ввода своего пароля).
  • UAC и Authenticate комбинируют оба подхода: администраторы подтверждают повышение прав программ, обычные пользователи вынуждены вводить логин и пароль администратора.
  • PolicyKit может быть настроен под любую из этих моделей — настройку задаёт дистрибутив.

Простота диалога подтверждения

  • Для повышения привилегий sudo[20], gksudo и Authenticate требуют повторного ввода пароля администратора.
  • В UAC, если пользователь вошёл под обычной учётной записью — каждый раз для повышения прав надо ввести имя и пароль администратора; если же использована учётная запись из группы "Администраторы", то обычно достаточно лишь подтвердить действие (без повторного ввода пароля — хотя опция для его запроса существует). Такой вариант проще, но менее безопасен[18]: если пользователь отлучится, не заблокировав компьютер, другой человек сможет получить административные права.
  • PolicyKit требует повторного ввода пароля или альтернативной аутентификации.

Сохранение учётных данных

  • UAC запрашивает подтверждение каждый раз при необходимости повышения прав для программы.
  • sudo[8] и его графические аналоги (gksudo, kdesu) не требуют повторного ввода пароля на каждый запрос: достаточно один раз ввести пароль, после чего в течение определённого времени (по умолчанию 5 минут[8]) пользователь сохраняет возможность повышать привилегии без нового ввода пароля.
Таким образом, sudo реализует компромисс — удобство со снижением безопасности: если сессия не защищена, то в течение "открытого" окна времени любое приложение в том же терминале или вне его (для gksudo/kdesu) будет обладать повышенными правами. Безопасность усилится, если вручную завершить действие временного привилегирования — командой sudo -k в каждом терминале; для kdesu аналогично — kdesu -s. У gksudo специальной команды нет, однако запуск sudo -k не в терминале (через “Выполнить” (Alt+F2) с опцией "Без терминала") приведёт к ожидаемому эффекту.
  • В Authenticate пароли не сохраняются: обычные пользователи вводят имя и пароль; для администратора — только пароль, потому что имя уже заполнено, но его можно изменить для запуска от другого пользователя.
Аутентификация запрашивается только тогда, когда приложению требуется новое разрешение. После “повышения” программа работает с новыми правами до завершения работы.
При этом есть понятие "прав". Какое именно разрешение требуется, может быть видно в деталях окна (например, system.privilege.admin — административный доступ, либо уровнем ниже/выше). Если необходимых прав не хватает, потребуется новое прохождение аутентификации.
  • PolicyKit гибко настраивается и поддерживает любые из указанных подходов.

Определение необходимости административных прав

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

В интерфейсах типа панели управления Windows или системных настроек Mac OS X требования к доступу жёстко прописаны — пользователь видит диалог авторизации до выполнения действий, требующих привилегий. В разных ОС реализованы разные методы указания необходимого уровня безопасности:

  • sudo использует централизованный конфигурационный файл /etc/sudoers, где задаётся, какие пользователи могут выполнять какие команды. Синтаксис гибок — можно ограничивать права по параметрам команд. Например:
 pete    ALL = /usr/bin/passwd [A-z]*, !/usr/bin/passwd root

(разрешает менять все пароли кроме root).

  • Контроль учётных записей пользователей (UAC) основывается на сочетании эвристического анализа и специальных XML-файлов "манифестов" (англ. application manifests). Манифесты впервые появились в Windows XP и имеют вид файлов ИмяПрограммы.exe.manifest:
<security>
    <requestedPrivileges>
        <requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
    </requestedPrivileges>
</security>
Манифесты могут быть встроены внутрь исполняемого файла. Эвристика применяется для обратной совместимости — например, если в имени файла программы встречается "Setup", Windows предполагает, что это установщик, и заранее выводит UAC-диалог[21].
UAC изменяет оформление запроса (иконка, цвет рамки, текст) в зависимости от наличия подписи у программы и издателя: если исполняемый файл подписан известным издателем, окно выглядит менее "предостерегающим", если нет — более настораживающим[22].
  • В случае PolicyKit приложения запрашивают конкретные права, а PolicyKit сам выполняет действие от имени приложения. При этом пользователь всегда видит, какая программа и для какой задачи требует авторизации.

Примечания

  1. ↑ Обзор контроля учетных записей пользователей (UAC). Microsoft (2 октября 2006). Дата обращения: 30 июня 2024. Архивировано 22 августа 2011 года.
  2. ↑ User Account Control Overview (англ.). Microsoft (2 октября 2006). Дата обращения: 12 марта 2007. Архивировано 22 августа 2011 года.
  3. ↑ Runas. Документация по Windows XP. Microsoft. Дата обращения: 13 марта 2007.
  4. ↑ Основы команды RunAs. Блог Аарона Маргозиса. MSDN Blogs (23 июня 2004). Дата обращения: 13 марта 2007.
  5. ↑ Sudo for Windows (англ.) (22 июля 2025). Дата обращения: 23 июля 2025.
  6. ↑ About PolicyKit (англ.). PolicyKit Language Reference Manual (2007). Дата обращения: 3 ноября 2017. Архивировано 18 февраля 2012 года.
  7. ↑ Miller, Todd C. Краткая история sudo (англ.). Дата обращения: 12 марта 2007. Архивировано 22 февраля 2007 года.
  8. ↑ 1 2 3 Miller, Todd C. Sudo in a Nutshell (англ.). Дата обращения: 1 июля 2007.
  9. ↑ GKSu home page (англ.).
  10. ↑ gksu PolicyKit на Gnome wiki (англ.).
  11. ↑ Bellevue Linux. Команда KDE su (20 ноября 2004). Дата обращения: 12 марта 2007. Архивировано 2 февраля 2007 года.
  12. ↑ Canonical Ltd. GutsyGibbon/Tribe5/Kubuntu (25 августа 2007). Дата обращения: 18 сентября 2007.
  13. ↑ О beesu (англ.). Дата обращения: 30 июня 2024. Архивировано 25 июля 2011 года.
  14. ↑ gksu — страница man в Linux (англ.). Дата обращения: 14 августа 2007. Архивировано 15 июля 2011 года.
  15. ↑ User Account Control Prompts on the Secure Desktop (англ.). UACBlog. Microsoft (3 мая 2006). Дата обращения: 4 марта 2007.
  16. ↑ gksu: блокировка мыши/клавиатуры недостаточна для защиты от кейлоггинга (англ.).
  17. ↑ ptrace Protection (англ.).
  18. ↑ 1 2 Allchin, Jim Security Features vs. Convenience (англ.). Windows Vista Team Blog. Microsoft (23 января 2007). Дата обращения: 12 марта 2007.
  19. ↑ Authentication Agent (англ.) (2007). Дата обращения: 15 ноября 2017. Архивировано 18 февраля 2012 года.
  20. ↑ Miller, Todd C. Руководство по sudoers (англ.). Дата обращения: 12 марта 2007.
  21. ↑ Understanding and Configuring User Account Control in Windows Vista (англ.). TechNet. Microsoft. Дата обращения: 15 марта 2007.
  22. ↑ Accessible UAC Prompts (англ.). Windows Vista Blog. Microsoft. Дата обращения: 13 февраля 2008. Архивировано 27 января 2008 года.

Категории