Сравнение функций авторизации привилегий
В этой статье отсутствует информация о диалоговом окне «Аутентификация» Mac. ( сентябрь 2021 г. ) |
В ряде компьютерных операционных систем используются функции безопасности, которые помогают предотвратить получение вредоносным программным обеспечением достаточных привилегий для компрометации компьютерной системы. Операционные системы, в которых отсутствуют такие функции, такие как DOS , реализации Windows до Windows NT (и ее потомков), CP/M-80 и все операционные системы Mac до Mac OS X, имели только одну категорию пользователей, которым было разрешено делать что-либо. Благодаря отдельным контекстам выполнения несколько пользователей могут хранить личные файлы, несколько пользователей могут использовать компьютер одновременно, чтобы защитить систему от злонамеренных пользователей и защитить систему от вредоносных программ. Первой многопользовательской защищенной системой была Multics , разработка которой началась в 1960-х годах; только в UNIX , BSD , Linux и NT в конце 80-х и начале 90-х годов многозадачные контексты безопасности были перенесены на x86 потребительские машины .
Введение в реализации
[ редактировать ]- Microsoft Windows
![]() |
Контроль учетных записей пользователей ( UAC ): входящий в состав Windows Vista и более поздних Microsoft Windows операционных систем UAC, , запрашивает у пользователя авторизацию, когда приложение пытается выполнить задачу администратора. [1] |
Выступления : Инструмент командной строки и команда контекстного меню, представленные в Windows 2000 , которые позволяют запускать программу, апплет панели управления или оснастку MMC от имени другого пользователя. [2] Runas использует службу Windows «Вторичный вход» , также представленную в Windows 2000. [3] Эта служба предоставляет возможность приложениям, работающим от имени отдельного пользователя, взаимодействовать с рабочим столом вошедшего в систему пользователя. Это необходимо для поддержки перетаскивания, совместного использования буфера обмена и других функций интерактивного входа. |
- macOS
![]() |
macOS включает диалоговое окно «Аутентификация» , в котором пользователю предлагается ввести пароль для выполнения задач администратора. По сути, это графический интерфейс sudo команда.
|
- Unix и Unix-подобные
![]() |
PolicyKit/pkexec : Функция авторизации привилегий, разработанная так, чтобы быть независимой от используемой среды рабочего стола и уже принятая в GNOME. [4] В отличие от более ранних систем, приложения, использующие PolicyKit, никогда не запускаются с привилегиями, превышающими права текущего пользователя. PolicyKit Вместо этого они косвенно отправляют запросы к демону , который является единственной программой, работающей от имени пользователя root. |
![]() |
являются : Инструмент командной строки для Unix . su (замещающий пользователь) позволяет пользователям переключать терминал на другую учетную запись, введя имя пользователя и пароль этой учетной записи. Если имя пользователя не указано, суперпользователя используется учетная запись операционной системы (известная как «root»), что обеспечивает быстрый способ получения оболочки входа в систему с полными привилегиями для системы. Выдача команды выхода возвращает пользователя в его собственную учетную запись. |
![]() |
судо : Создан примерно в 1980 году. [5] sudo — это широко настраиваемый инструмент командной строки Unix, похожий на su , но он позволяет определенным пользователям запускать программы с привилегиями root, не создавая оболочку root и не требуя пароля root. [6] |
![]() |
ГКСу и ГКсудо : GTK+ Графический интерфейс для su и sudo . [7] GKsu появляется автоматически, когда поддерживаемому приложению необходимо выполнить действие, требующее привилегий root. Замена « gksu PolicyKit », которая использует PolicyKit вместо su / sudo , разрабатывается как часть GNOME . [8] |
![]() |
где-то : для Графический интерфейс Qt команды su для KDE . [9] |
![]() |
где : Графический интерфейс Qt для sudo , который заменил kdesu в Kubuntu , начиная с Kubuntu 7.10. [10] |
![]() |
кссс : ktsuss означает « su является простым , и глупым сохраняйте » графической версией su . Идея проекта — оставаться простым и свободным от ошибок. |
![]() |
Бису : Графический интерфейс команды su , который заменил gksu в операционных системах на базе Red Hat . Он был разработан в основном для RHEL и Fedora . [11] |
пожертвовать : замена sudo начиная с OpenBSD 5.8 (октябрь 2015 г.) |
Соображения безопасности
[ редактировать ]![]() | Этот раздел нуждается в дополнении : Информация для диалогового окна «Аутентификация» Mac. Вы можете помочь, добавив к нему . ( декабрь 2009 г. ) |
Фальсифицированный/перехваченный пользовательский ввод
[ редактировать ]Важным фактором безопасности является способность вредоносных приложений имитировать нажатия клавиш или щелчки мыши, таким образом обманывая или имитируя функцию безопасности, предоставляя вредоносным приложениям более высокие привилегии.
- Использование клиента на основе терминала (автономного или в составе рабочего стола/графического пользовательского интерфейса): su и sudo запускаются в терминале, где они уязвимы для поддельного ввода. Конечно, если бы у пользователя не была многозадачная среда (т. е. только один пользователь в оболочке), это не было бы проблемой. Окна терминала обычно отображаются для пользователя как обычные окна, поэтому в интеллектуальном клиенте или настольной системе, используемой в качестве клиента, пользователь должен взять на себя ответственность за предотвращение манипулирования, моделирования или перехвата ввода другими вредоносными программами на своем рабочем столе.
- Использование графического пользовательского интерфейса/рабочего стола, тесно интегрированного с операционной системой. Обычно настольная система блокирует или защищает все распространенные средства ввода перед запросом паролей или другой аутентификации, чтобы их нельзя было перехватить, манипулировать или моделировать:
- PolicyKit ( GNOME — предписывает X- серверу перехватывать весь ввод с клавиатуры и мыши. Другие среды рабочего стола, использующие PolicyKit, могут использовать свои собственные механизмы.
- gksudo — по умолчанию «блокирует» клавиатуру, мышь и фокус окна, [12] запрещая кому-либо, кроме фактического пользователя, вводить пароль или иным образом вмешиваться в диалоговое окно подтверждения .
- UAC (Windows) — по умолчанию запускается в Secure Desktop , не позволяя вредоносным приложениям имитировать нажатие кнопки «Разрешить» или иным образом вмешиваться в диалог подтверждения. [13] В этом режиме рабочий стол пользователя затемнен и с ним невозможно взаимодействовать.
- Если функция «блокировки» gksudo или Secure Desktop UAC были скомпрометированы или отключены, вредоносные приложения могли получить права администратора, используя регистрацию нажатий клавиш для записи пароля администратора; или, в случае UAC, если он работает от имени администратора, подделать щелчок мышью по кнопке «Разрешить». По этой причине распознаванию голоса также запрещено взаимодействовать с диалогом. [ нужна ссылка ] Обратите внимание: поскольку запрос пароля gksu запускается без специальных привилегий, вредоносные приложения все равно могут вести журнал нажатий клавиш, например, с помощью инструмента strace . [14] (ptrace был ограничен в более поздних версиях ядра) [15]
Ложные диалоги аутентификации
[ редактировать ]Еще одним фактором безопасности является способность вредоносного программного обеспечения подделывать диалоговые окна, которые выглядят как законные запросы подтверждения безопасности. Если бы пользователь ввел учетные данные в поддельное диалоговое окно, думая, что диалоговое окно является законным, вредоносное программное обеспечение узнало бы пароль пользователя. Если функция «Безопасный рабочий стол» или подобная функция отключена, вредоносное программное обеспечение может использовать этот пароль для получения более высоких привилегий.

- Хотя это не поведение по умолчанию из соображений удобства использования, UAC можно настроить так, чтобы пользователь нажимал Ctrl+Alt+Del (известный как безопасная последовательность действий ) в рамках процесса аутентификации. Поскольку только Windows может обнаружить эту комбинацию клавиш, требование этой дополнительной меры безопасности не позволит поддельным диалогам вести себя так же, как законный диалог. [16] Например, поддельный диалог может не просить пользователя нажать Ctrl+Alt+Del, и пользователь может понять, что диалог был поддельным. Или, когда пользователь нажал Ctrl+Alt+Del, пользователь будет переведен на экран, который обычно приводит к экрану Ctrl+Alt+Del, а не к диалоговому окну подтверждения UAC. Таким образом, пользователь мог определить, был ли этот диалог попыткой обманом заставить его предоставить свой пароль вредоносному программному обеспечению.
- В GNOME PolicyKit использует разные диалоговые окна, в зависимости от конфигурации системы. Например, диалоговое окно аутентификации для системы, оснащенной устройством считывания отпечатков пальцев, может отличаться от диалогового окна аутентификации для системы без него. Приложения не имеют доступа к конфигурации PolicyKit, поэтому у них нет возможности узнать, какой диалог появится и, следовательно, как его подделать. [17]
Вопросы юзабилити
[ редактировать ]Еще одним соображением, которое учитывалось в этих реализациях, является удобство использования .
Отдельный аккаунт администратора
[ редактировать ]- su требует, чтобы пользователь знал пароль как минимум к двум учетным записям: учетной записи обычного использования и учетной записи с более высокими привилегиями, например root .
- sudo , kdesu и gksudo используют более простой подход. В этих программах пользователю предварительно настраивается доступ к определенным административным задачам, но он должен явно разрешить приложениям запускаться с этими привилегиями. Пользователь вводит свой собственный пароль вместо пароля суперпользователя или какой-либо другой учетной записи.
- UAC и Authenticate объединяют эти две идеи в одну. С помощью этих программ администраторы явно разрешают запуск программ с более высокими привилегиями. Неадминистраторам будет предложено ввести имя пользователя и пароль администратора.
- PolicyKit можно настроить для использования любого из этих подходов. На практике распределение выберет одно.
Простота диалога
[ редактировать ]- Чтобы предоставить приложению административные привилегии, sudo , [18] gksudo и Authenticate предлагают администраторам повторно ввести свой пароль.
- При использовании UAC при входе в систему как обычный пользователь пользователь должен вводить имя и пароль администратора каждый раз, когда ему необходимо предоставить приложению повышенные привилегии; но при входе в систему как член группы «Администраторы» они (по умолчанию) просто подтверждают или отклоняют, вместо того, чтобы каждый раз повторно вводить свой пароль (хотя это вариант). Хотя подход по умолчанию проще, он также менее безопасен. [16] поскольку, если пользователь физически отойдет от компьютера, не заблокировав его, другой человек может подойти и получить права администратора в системе.
- PolicyKit требует от пользователя повторно ввести свой пароль или предоставить другие средства аутентификации (например, отпечаток пальца).
Сохранение учетных данных
[ редактировать ]![]() | Этот раздел нуждается в дополнении : Информация для диалогового окна «Аутентификация» Mac. Вы можете помочь, добавив к нему . ( декабрь 2009 г. ) |
- UAC запрашивает авторизацию каждый раз, когда он вызывается для повышения уровня программы.
- судо , [6] gksudo и kdesu не запрашивают у пользователя повторный ввод пароля каждый раз, когда он вызывается для повышения прав программы. Вместо этого пользователю запрашивается пароль один раз в начале. Если пользователь не использовал свои административные привилегии в течение определенного периода времени (по умолчанию sudo составляет 5 минут). [6] ), пользователю снова будут предоставлены стандартные права пользователя, пока он снова не введет свой пароль.
- Подход sudo — это компромисс между безопасностью и удобством использования. С одной стороны, пользователю нужно ввести свой пароль только один раз для выполнения ряда задач администратора, а не вводить пароль для каждой задачи. Но в то же время зона атаки больше, поскольку все программы, работающие в этом tty (для sudo) или все программы, не работающие в терминале (для gksudo и kdesu), имеющие префикс любой из этих команд до истечения таймаута, получают администратора. привилегии. Пользователи, заботящиеся о безопасности, могут удалить временные права администратора после выполнения требующих их задач, используя
sudo -k
команду if для каждого терминала или точки, в которой использовалось sudo (в случае точек, закрытия эмулятора терминала недостаточно ) . Эквивалентная команда для kdesu:kdesu -s
. Нет возможности gksudo сделать то же самое; однако, бегsudo -k
не внутри экземпляра терминала (например, через диалоговое окно «Запустить приложение» Alt + F2, сняв флажок «Запустить в терминале») даст желаемый эффект.
- Аутентификация не сохраняет пароли. Если пользователь является обычным пользователем, он должен ввести имя пользователя и пароль. Если пользователь является администратором, имя текущего пользователя уже заполнено, и ему нужно только ввести его пароль. Имя по-прежнему можно изменить для запуска от имени другого пользователя.
- Приложению требуется аутентификация только один раз, и она запрашивается в тот момент, когда приложению требуется эта привилегия. После повышения приложению не требуется повторная проверка подлинности до тех пор, пока приложение не будет закрыто и перезапущено.
- Однако существуют различные уровни аутентификации, известные как права. Запрошенное право можно отобразить, развернув треугольник рядом с надписью «Подробности» под паролем. Обычно приложения используют system.privilege.admin, но можно использовать и другое, например, более низкое право для обеспечения безопасности или более высокое право, если требуется более высокий уровень доступа. Если права, которые имеет приложение, не подходят для задачи, приложению может потребоваться повторная аутентификация для повышения уровня привилегий.
- PolicyKit можно настроить для использования любого из этих подходов.
Определение случаев, когда необходимы административные права
[ редактировать ]![]() | Этот раздел нуждается в дополнении : Информация для диалогового окна «Аутентификация» Mac. Вы можете помочь, добавив к нему . ( декабрь 2009 г. ) |
Чтобы операционная система знала, когда запрашивать у пользователя авторизацию, приложение или действие должно идентифицировать себя как требующее повышенных привилегий. Хотя технически возможно, что пользователю будет предложено получить запрос именно в тот момент, когда выполняется операция, требующая таких привилегий, часто не идеально запрашивать привилегии в процессе выполнения задачи. Если бы пользователь не смог предоставить правильные учетные данные, работу, выполненную до того, как ему потребовались права администратора, пришлось бы отменить, поскольку задачу невозможно было довести до конца.
В случае пользовательских интерфейсов, таких как панель управления в Microsoft Windows и панели настроек в Mac OS X, точные требования к привилегиям жестко запрограммированы в системе, так что пользователю в подходящее время отображается диалоговое окно авторизации ( например, перед отображением информации, которую должны видеть только администраторы). Различные операционные системы предлагают приложениям разные методы определения требований безопасности:
- sudo централизует всю информацию об авторизации привилегий в одном файле конфигурации,
/etc/sudoers
, который содержит список пользователей, а также привилегированные приложения и действия, которые этим пользователям разрешено использовать. Грамматика файла sudoers должна быть достаточно гибкой, чтобы охватить множество различных сценариев, таких как наложение ограничений на параметры командной строки. Например, пользователю может быть предоставлен доступ для изменения любого пароля, кроме учетной записи root, следующим образом:
pete ALL = /usr/bin/passwd [A-z]*, !/usr/bin/passwd root
- Контроль учетных записей пользователей использует комбинацию эвристического сканирования и «манифестов приложений», чтобы определить, требуются ли приложению права администратора. [19] Файлы манифеста ( .manifest ), впервые появившиеся в Windows XP, представляют собой XML- файлы с тем же именем, что и приложение, и суффиксом «.manifest», например
Notepad.exe.manifest
. При запуске приложения манифест просматривается на предмет информации о том, какие требования безопасности предъявляет приложение. Например, этот фрагмент XML будет указывать, что приложению потребуется доступ администратора, но не потребуется неограниченный доступ к другим частям рабочего стола пользователя за пределами приложения:
<security>
<requestedPrivileges>
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
</requestedPrivileges>
</security>
- Файлы манифеста также могут быть скомпилированы в исполняемый файл приложения в качестве встроенного ресурса . Также используется эвристическое сканирование, прежде всего для обратной совместимости. Одним из примеров этого является просмотр имени исполняемого файла; если оно содержит слово «Настройка», предполагается, что исполняемый файл является установщиком, и перед запуском приложения отображается приглашение UAC. [20]
- UAC также проводит различие между запросами на повышение прав от подписанного и неподписанного исполняемого файла; и если первое, является ли издателем «Windows Vista». Цвет, значок и формулировка подсказок в каждом случае различны: например, попытка передать большее предупреждение, если исполняемый файл не подписан, чем если бы он не был подписан. [21]
- Приложения, использующие PolicyKit, запрашивают определенные привилегии при запросе аутентификации, и PolicyKit выполняет эти действия от имени приложения. Перед аутентификацией пользователи могут увидеть, какое приложение запросило действие и какое действие было запрошено.
См. также
[ редактировать ]- Повышение привилегий , тип уязвимости безопасности.
- Принцип наименьших привилегий , шаблон проектирования безопасности
- Privileged Identity Management , методология управления привилегированными учетными записями
- Управление привилегированными паролями , концепция, аналогичная управлению привилегированными идентификационными данными:
- т.е. периодически шифровать привилегированные пароли; и
- хранить значения паролей в безопасном и высокодоступном хранилище; и
- применять политику относительно того, когда, как и кому могут быть раскрыты эти пароли.
Ссылки
[ редактировать ]- ^ «Обзор контроля учетных записей пользователей» . Майкрософт . 02.10.2006. Архивировано из оригинала 22 августа 2011 г. Проверено 12 марта 2007 г.
- ^ «Рунас» . Документация по продукту Windows XP . Майкрософт . Проверено 13 марта 2007 г.
- ^ « Базовые (и промежуточные) темы «RunAs»» . Веб-журнал Аарона Маргосиса . Блоги MSDN. 23 июня 2004 г. Проверено 13 марта 2007 г.
- ^ «О ПолисиКите» . Справочное руководство по языку PolicyKit . 2007. Архивировано из оригинала 18 февраля 2012 г. Проверено 3 ноября 2017 г.
- ^ Миллер, Тодд К. «Краткая история судо» . Архивировано из оригинала 22 февраля 2007 г. Проверено 12 марта 2007 г.
- ^ Перейти обратно: а б с Миллер, Тодд К. «Коротко о судо» . Проверено 1 июля 2007 г.
- ^ «Главная страница ГКСУ» .
- ^ «gksu PolicyKit в вики Gnome» .
- ^ Бельвью Linux (20 ноября 2004 г.). «Команда KDE su» . Архивировано из оригинала 2 февраля 2007 г. Проверено 12 марта 2007 г.
- ^ ООО "Каноникал" (25 августа 2007 г.). «GutsyGibbon/Tribe5/Kubuntu» . Проверено 18 сентября 2007 г.
- ^ Вы можете прочитать больше о beesu, заархивировано 25 июля 2011 г., на Wayback Machine и загрузить его с Koji.
- ^ «gksu — справочная страница Gtk+ su для Linux» . Архивировано из оригинала 15 июля 2011 г. Проверено 14 августа 2007 г.
- ^ «Запросы контроля учетных записей пользователей на безопасном рабочем столе» . UACBlog . Майкрософт . 3 мая 2006 г. Проверено 4 марта 2007 г.
- ^ «gksu: блокировки мыши/клавиатуры недостаточно для защиты от кейлоггеров» .
- ^ «Защита от трассировки» .
- ^ Перейти обратно: а б Олчин, Джим (23 января 2007 г.). «Функции безопасности против удобства» . Блог группы разработчиков Windows Vista . Майкрософт . Проверено 12 марта 2007 г.
- ^ «Агент аутентификации» . 2007. Архивировано из оригинала 18 февраля 2012 г. Проверено 15 ноября 2017 г.
- ^ Миллер, Тодд К. «Руководство Sudoers» . Проверено 12 марта 2007 г.
- ^ «Рекомендации и рекомендации для разработчиков для приложений в наименее привилегированной среде» . MSDN . Майкрософт . Проверено 15 марта 2007 г.
- ^ «Понимание и настройка контроля учетных записей пользователей в Windows Vista» . ТехНет . Майкрософт . Проверено 15 марта 2007 г.
- ^ «Доступные подсказки UAC» . Блог Windows Vista . Майкрософт. Архивировано из оригинала 27 января 2008 г. Проверено 13 февраля 2008 г.