В ряде компьютерных операционных систем используются функции безопасности, которые помогают предотвратить получение вредоносными программами достаточных прав для компрометации компьютерной системы. В операционных системах без таких функций, таких как DOS , реализации Windows до Windows NT (и ее потомков), CP / M-80 и всех операционных систем Mac до Mac OS X, была только одна категория пользователей, которым разрешалось делать что-нибудь. Благодаря раздельным контекстам выполнения несколько пользователей могут хранить личные файлы, несколько пользователей могут использовать компьютер одновременно, защищать систему от злонамеренных пользователей и защищать систему от вредоносных программ. Первой многопользовательской защищенной системой была Multics., начавшая разработку в 1960-х годах; только в UNIX , BSD , Linux и NT в конце 80-х - начале 90-х годов контексты многозадачной безопасности были перенесены на потребительские машины x86 .
Введение в реализации
- Майкрософт Виндоус
Диалоговое окно запроса контроля учетных записей пользователей | Контроль учетных записей пользователей ( UAC ). Включенный в Windows Vista и более поздние версии операционных систем Microsoft Windows , UAC запрашивает у пользователя авторизацию, когда приложение пытается выполнить задачу администратора. [1] |
Runas : инструмент командной строки и команда контекстного меню, представленные в Windows 2000, которые позволяют запускать программу, апплет панели управления или оснастку MMC от имени другого пользователя. [2] Runas использует службу Windows «Вторичный вход», также представленную в Windows 2000. [3] Эта служба позволяет приложениям, работающим как отдельный пользователь, взаимодействовать с рабочим столом вошедшего в систему пользователя. Это необходимо для поддержки перетаскивания, совместного использования буфера обмена и других функций интерактивного входа в систему. |
- Mac OS
Mac OS X включает диалоговое окно « Аутентификация », в котором пользователю предлагается ввести пароль для выполнения задач администратора. По сути, это графический интерфейс sudo команды. |
- Unix и Unix-подобные
PolicyKit / pkexec : функция авторизации привилегий, разработанная для независимости от используемой среды рабочего стола и уже принятая GNOME [4] В отличие от более ранних систем, приложения, использующие PolicyKit, никогда не запускаются с привилегиями выше, чем у текущего пользователя. Вместо этого они косвенно запрашивают демон PolicyKit, который является единственной программой, работающей от имени пользователя root. | |
Sudo, запущенный в окне терминала в Ubuntu | su : инструмент командной строки для Unix . su (замещающий пользователь) позволяет пользователям переключать терминал на другую учетную запись, вводя имя пользователя и пароль этой учетной записи. Если имя пользователя не указано, используетсяучетная запись суперпользователя операционной системы(известная как «root»), что обеспечивает быстрый способ получения оболочки входас полными привилегиями в системе. Выполнениекоманды выхода возвращает пользователя к его собственной учетной записи. |
sudo : Созданный примерно в 1980 году [5] sudo - это инструмент командной строки Unix с широкими возможностями настройки, похожий на su , но он позволяет некоторым пользователям запускать программы с привилегиями root, не создавая оболочку root и не требуя пароля root. [6] | |
GKSu и GKsudo : GTK + Графический интерфейс для su и sudo . [7] GKsu запускается автоматически, когда поддерживаемое приложение должно выполнить действие, требующее привилегий root. Замена, « gksu PolicyKit », которая использует PolicyKit, а не su / sudo , разрабатывается как часть GNOME . [8] | |
kdesu : Qt графический интерфейс к су команды для KDE . [9] | |
kdesudo : графический интерфейс Qt для sudo , который заменил kdesu в Kubuntu , начиная с Kubuntu 7.10. [10] | |
ktsuss : ktsuss означает « К EEP т он Су сек реали, S tupid», и это графическая версия су . Идея проекта - оставаться простым и свободным от ошибок. | |
beesu : графический интерфейс для команды su , которая заменила gksu в операционных системах на базе Red Hat . Он был разработан в основном для RHEL и Fedora . [11] | |
doas : замена sudo начиная с OpenBSD 5.8 (октябрь 2015 г.) |
Соображения безопасности
Фальсифицированный / перехваченный пользовательский ввод
Основным фактором безопасности является способность вредоносных приложений имитировать нажатия клавиш или щелчки мыши, таким образом обманывая или подменяя функцию безопасности, чтобы предоставить вредоносным приложениям более высокие привилегии.
- Использование клиента на основе терминала (автономного или в пределах рабочего стола / графического интерфейса пользователя): su и sudo запускаются в терминале, где они уязвимы для подделки ввода. Конечно, если бы пользователь не запускал многозадачную среду (т.е. только один пользователь в оболочке), это не было бы проблемой. Терминальные окна обычно отображаются для пользователя как обычные окна, поэтому на интеллектуальном клиенте или настольной системе, используемой в качестве клиента, пользователь должен взять на себя ответственность за предотвращение манипулирования, имитации или захвата ввода другими вредоносными программами на своем рабочем столе.
- Использование графического интерфейса пользователя / рабочего стола, тесно интегрированного с операционной системой: обычно настольная система блокирует или защищает все распространенные средства ввода перед запросом паролей или другой аутентификации, чтобы их нельзя было перехватить, обработать или смоделировать:
- PolicyKit ( GNOME - предписывает X- серверу захватывать весь ввод с клавиатуры и мыши. Другие среды рабочего стола, использующие PolicyKit, могут использовать свои собственные механизмы.
- gksudo - по умолчанию «блокирует» клавиатуру, мышь и фокус окна, [12] предотвращая ввод пароля кем-либо, кроме фактического пользователя, или иным образом вмешиваясь в диалог подтверждения .
- UAC (Windows) - по умолчанию запускается на защищенном рабочем столе , предотвращая имитацию вредоносными приложениями нажатия кнопки «Разрешить» или иного вмешательства в диалоговое окно подтверждения. [13] В этом режиме рабочий стол пользователя затемнен, и с ним невозможно взаимодействовать.
- Если функция блокировки gksudo или Secure Desktop UAC были скомпрометированы или отключены, вредоносные приложения могли получить права администратора, используя регистрацию нажатия клавиш для записи пароля администратора; или, в случае UAC, если вы работаете от имени администратора, подделав щелчок мыши на кнопке «Разрешить». По этой причине распознаванию голоса также запрещено взаимодействовать с диалогом. [ необходима цитата ] Обратите внимание, что, поскольку запрос пароля gksu запускается без особых привилегий, вредоносные приложения по-прежнему могут вести журнал нажатий клавиш, например, с помощью инструмента strace . [14] (ptrace был ограничен в более поздних версиях ядра) [15]
Поддельные диалоги аутентификации
Еще одним соображением безопасности является способность вредоносного ПО подделывать диалоги, которые выглядят как законные запросы подтверждения безопасности. Если бы пользователь ввел учетные данные в поддельный диалог, считая диалог законным, вредоносное ПО узнало бы пароль пользователя. Если бы Secure Desktop или аналогичная функция были отключены, вредоносное ПО могло использовать этот пароль для получения более высоких привилегий.
- Хотя это не является поведением по умолчанию из соображений удобства использования, 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 требует, чтобы пользователь повторно ввел свой пароль или предоставил другие средства аутентификации (например, отпечаток пальца).
Сохранение учетных данных
- UAC запрашивает авторизацию каждый раз, когда вызывается для повышения уровня программы.
- sudo , [6] gksudo и kdesu не просят пользователя повторно вводить пароль каждый раз, когда он вызывается для повышения уровня программы. Скорее всего, пользователя запрашивают пароль один раз при запуске. Если пользователь не использовал свои административные привилегии в течение определенного периода времени (sudo по умолчанию - 5 минут [6] ), пользователь снова ограничен привилегиями стандартного пользователя до тех пор, пока он снова не введет свой пароль.
- Подход sudo - это компромисс между безопасностью и удобством использования. С одной стороны, пользователю нужно только один раз ввести свой пароль для выполнения ряда административных задач, вместо того, чтобы вводить свой пароль для каждой задачи. Но в то же время поверхность для атаки больше, потому что все программы, которые запускаются на этом tty (для sudo) или все программы, не работающие в терминале (для gksudo и kdesu), имеют префикс любой из этих команд до истечения времени ожидания администратора привилегии. Безопасность сознательных пользователей могут удалить привилегии временного администратора при выполнении задач , требующих их с помощью
sudo -k
команды , когда из каждого TTY или PTS , в котором было использовано Судо (в случае PTS - х, закрывая эмулятор терминала является не достаточным). Эквивалентная команда для kdesu -kdesu -s
. В gksudo нет возможности сделать то же самое; однако выполнениеsudo -k
не в экземпляре терминала (например, через диалоговое окно Alt + F2 «Запуск приложения», снятие флажка «Запуск в терминале») даст желаемый эффект.
- Authenticate не сохраняет пароли. Если пользователь является стандартным пользователем, он должен ввести имя пользователя и пароль. Если пользователь является администратором, имя текущего пользователя уже введено, и нужно только ввести его пароль. Имя все еще можно изменить для запуска от имени другого пользователя.
- Приложение требует аутентификации только один раз и запрашивается в то время, когда приложению требуются привилегии. После «повышения» приложение не нуждается в повторной аутентификации до тех пор, пока приложение не будет завершено и перезапущено.
- Однако существуют различные уровни аутентификации, известные как права. Требуемое право можно отобразить, развернув треугольник рядом с «подробностями» под паролем. Обычно приложения используют system.privilege.admin, но можно использовать другой, например, нижний правый для безопасности или более высокий правый, если требуется более высокий доступ. Если права, которыми обладает приложение, не подходят для задачи, приложению может потребоваться повторная аутентификация для повышения уровня привилегий.
- PolicyKit можно настроить для принятия любого из этих подходов.
Определение того, когда необходимы права администратора
Чтобы операционная система знала, когда запрашивать у пользователя авторизацию, приложение или действие должны идентифицировать себя как требующие повышенных привилегий. Хотя технически возможно, чтобы пользователь получил подсказку в тот момент, когда выполняется операция, требующая таких привилегий, часто не идеально запрашивать привилегии на полпути к выполнению задачи. Если бы пользователь не смог предоставить надлежащие учетные данные, работу, выполненную до того, как потребовались права администратора, пришлось бы отменить, потому что задача не могла быть видна до конца.
В случае пользовательских интерфейсов, таких как панель управления в Microsoft Windows и панели настроек в Mac OS X, точные требования к привилегиям жестко запрограммированы в системе, так что пользователю в подходящее время предоставляется диалоговое окно авторизации ( например, перед отображением информации, которую должны видеть только администраторы). Различные операционные системы предлагают приложениям разные методы определения их требований к безопасности:
- sudo централизует всю информацию об авторизации привилегий в одном файле конфигурации
/etc/sudoers
, который содержит список пользователей, а также привилегированные приложения и действия, которые этим пользователям разрешено использовать. Грамматика файла sudoers должна быть достаточно гибкой, чтобы охватить множество различных сценариев, таких как наложение ограничений на параметры командной строки. Например, пользователю может быть предоставлен доступ для изменения любого пароля, кроме учетной записи root, следующим образом:
pete ALL = / usr / bin / passwd [Az] *,! / usr / bin / passwd root
- Контроль учетных записей пользователей использует комбинацию эвристического сканирования и «манифестов приложений», чтобы определить, требуются ли приложению права администратора. [19] Файлы манифеста ( .manifest ), впервые представленные в Windows XP, представляют собой файлы XML с тем же именем, что и приложение, и суффиксом «.manifest», например
Notepad.exe.manifest
. Когда приложение запускается, манифест просматривается для получения информации о том, какие требования безопасности предъявляются к приложению. Например, этот фрагмент XML будет указывать, что приложению потребуется доступ администратора, но не потребуется неограниченный доступ к другим частям рабочего стола пользователя вне приложения:
< requestExecutionLevel level = "requireAdministrator" uiAccess = "false" />
- Файлы манифеста также могут быть скомпилированы в исполняемый файл приложения как встроенный ресурс . Также используется эвристическое сканирование, в первую очередь для обеспечения обратной совместимости. Одним из примеров этого является просмотр имени исполняемого файла; если он содержит слово «Setup», предполагается, что исполняемый файл является установщиком, и перед запуском приложения отображается запрос UAC. [20]
- UAC также делает различие между запросами на повышение прав от подписанного исполняемого файла и неподписанного исполняемого файла; а если первое, то является ли издатель «Windows Vista». Цвет, значок и формулировка подсказок различаются в каждом случае: например, попытка передать большее чувство предупреждения, если исполняемый файл без подписи, чем в противном случае. [21]
- Приложения, использующие PolicyKit, запрашивают определенные привилегии при запросе аутентификации, и PolicyKit выполняет эти действия от имени приложения. Перед аутентификацией пользователи могут видеть, какое приложение запросило действие и какое действие было запрошено.
Смотрите также
- Повышение привилегий , разновидность эксплойта безопасности
- Принцип наименьших привилегий , шаблон проектирования безопасности
- Privileged Identity Management , методология управления привилегированными учетными записями
- Управление привилегированными паролями , аналогичная концепции управления привилегированными идентификационными данными:
- т.е. периодически шифровать пароли с привилегиями; а также
- хранить значения паролей в безопасном высокодоступном хранилище; а также
- применять политику относительно того, когда, как и кому могут быть раскрыты эти пароли.
Рекомендации
- ^ «Обзор управления учетными записями пользователей» . Microsoft . 2006-10-02. Архивировано из оригинала на 2011-08-23 . Проверено 12 марта 2007 .
- ^ «Рунас» . Документация по продукту Windows XP . Microsoft . Проверено 13 марта 2007 .
- ^ « » RunAs «основные (и промежуточные) темы» . WebLog Аарона Маргозиса . Блоги MSDN. 2004-06-23 . Проверено 13 марта 2007 .
- ^ «О PolicyKit» . Справочное руководство по языку PolicyKit . 2007. Архивировано из оригинала на 2012-02-18 . Проверено 3 ноября 2017 .
- ^ Миллер, Тодд К. "Краткая история судо" . Архивировано из оригинала на 2007-02-22 . Проверено 12 марта 2007 .
- ^ а б в Миллер, Тодд С. «Судо в двух словах» . Проверено 1 июля 2007 .
- ^ «Домашняя страница ГКСу» .
- ^ «gksu PolicyKit на вики-сайте Gnome» .
- ^ Bellevue Linux (20 ноября 2004 г.). «Команда KDE su» . Архивировано из оригинала на 2007-02-02 . Проверено 12 марта 2007 .
- ^ Canonical Ltd. (25 августа 2007 г.). "GutsyGibbon / Tribe5 / Kubuntu" . Проверено 18 сентября 2007 .
- ^ Вы можете прочитать больше о пчелах, заархивированных 25 июля 2011 г., на Wayback Machine и загрузить их с Koji
- ^ "gksu - страница руководства Linux для Gtk + su" . Архивировано из оригинала на 2011-07-15 . Проверено 14 августа 2007 .
- ^ «Запросы контроля учетных записей пользователей на безопасном рабочем столе» . UACBlog . Microsoft . 2006-05-03 . Проверено 4 марта 2007 .
- ^ «gksu: блокировки мыши / клавиатуры недостаточно для защиты от кейлоггеров» .
- ^ «Защита ptrace» .
- ^ а б Олчин, Джим ( 23 января 2007 г.). «Функции безопасности против удобства» . Блог группы разработчиков Windows Vista . Microsoft . Проверено 12 марта 2007 .
- ^ «Агент аутентификации» . 2007. Архивировано из оригинала на 2012-02-18 . Проверено 15 ноября 2017 .
- ^ Миллер, Тодд К. "Руководство Судоэра" . Проверено 12 марта 2007 .
- ^ «Рекомендации и рекомендации для разработчиков для приложений в наименее привилегированной среде» . MSDN . Microsoft . Проверено 15 марта 2007 .
- ^ «Понимание и настройка контроля учетных записей пользователей в Windows Vista» . TechNet . Microsoft . Проверено 15 марта 2007 .
- ^ «Доступные подсказки UAC» . Блог Windows Vista . Microsoft. Архивировано из оригинала на 2008-01-27 . Проверено 13 февраля 2008 .