Обстоятельства, требующие поднятых полномочий

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

• управляя полномочиями файла, владением

• создание, читая, обновляя или удаляя систему и пользовательские файлы

• открытие привилегированных портов (те с номерами портов меньше чем 1 024) для соединений TCP и соединений UDP

• открытие неструктурированных сокетов

• управление процессами

• чтение содержания виртуальной памяти

• изменение параметров настройки системы

• загрузка расширений ядра

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

Враждебное окружение и принцип наименьшего количества полномочия

Любая программа может подвергнуться нападению, и вероятно будет. По умолчанию каждый процесс работает с полномочиями пользователя или процесса, запустившего его. В результате, если атакующий использует переполнение буфера или другую уязвимость системы обеспечения безопасности (см. Типы Уязвимостей системы обеспечения безопасности) для выполнения кода чьего-либо компьютера они могут обычно выполнять свой код с любыми полномочиями, которые имеет зарегистрированный пользователь.

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

Если атакующий может получить права администратора, они могут поднять к полномочиям пользователя root и получить доступ к любым данным по компьютеру пользователя. Поэтому это - хорошая практика безопасности для входа в систему как администратор только при выполнении редких задач, требующих административных привилегий. Поскольку настройка по умолчанию для OS X должна сделать владельца компьютера администратором, необходимо призвать пользователей создавать отдельный неадминистраторский вход в систему и использовать это для их повседневной работы. Кроме того, если это возможно, Вы не должны требовать административных привилегий установить Ваше программное обеспечение.

Идея ограничить риск путем ограничения доступа возвращается к “потребности знать” политику, сопровождаемую правительственными управлениями безопасности (независимо от того, что уровень защиты, Вам не предоставляют доступ к информации, если у Вас нет определенной потребности знать ту информацию). В безопасности программного обеспечения эту политику часто вызывают принципом наименьшего количества полномочия.

Принцип наименьшего количества состояний полномочия:

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

— Saltzer, J.H. AND Шредер, Доктор медицины, “Защита информации в Компьютерных системах”, Продолжения IEEE, издания 63, № 9, сентябрь 1975.

На практике принцип наименьшего количества полномочия означает, что необходимо избежать работать как корень, или — если абсолютно необходимо работать как корень для выполнения некоторой задачи — необходимо выполнить отдельное вспомогательное приложение для выполнения привилегированной задачи (см. Запись Привилегированного Помощника). Кроме того, по мере возможности Ваше программное обеспечение (или части этого) должно работать в песочнице, ограничивающей ее полномочия еще больше, как описано в Разработке Безопасных Помощников и Демонов.

Путем выполнения с наименьшим количеством возможного полномочия, Вы:

• Предельный ущерб от несчастных случаев и ошибок, включая злонамеренно представленные несчастные случаи и ошибки

• Сократите взаимодействия привилегированных компонентов, и поэтому сократите неумышленное, нежелательное, и неправильное использование полномочия (побочные эффекты)

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

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

Предотвращение поднятых полномочий

Во многих случаях можно выполнить задачу, не нуждаясь в поднятых полномочиях. Например, предположите, что необходимо сконфигурировать среду (добавьте конфигурационный файл к корневому каталогу пользователя или измените конфигурационный файл в корневом каталоге пользователя) для приложения. Можно сделать это от установщика, работающего как корень ( installer команда требует административных привилегий; посмотрите installer страница руководства). Однако, если у Вас есть приложение, конфигурируют себя или проверяют, необходима ли конфигурация, когда это запускает, тогда Вы не должны работать как корень вообще.

Пример использования альтернативного проекта во избежание выполнения с поднятыми полномочиями дан BSD ps команда, выводящая на экран информацию о процессах, имеющих терминалы управления. Первоначально, BSD использовал setgid бит для выполнения ps команда с группой ID kmem, который дал ему полномочия считать память ядра. Более свежие реализации ps использование команды sysctl утилита для чтения информаций этому нужно, удаляя требование это ps выполненный с любыми специальными полномочиями.

Выполнение с поднятыми полномочиями

Если действительно необходимо выполнить код с поднятыми полномочиями, существует несколько подходов, которые можно проявить:

• Можно выполнить демона с поднятыми полномочиями, к которым Вы обращаетесь, когда необходимо выполнить привилегированную задачу. Предпочтительный метод запуска демона состоит в том, чтобы использовать launchd демон (см. launchd). Проще использовать launchd запустить демона и проще связаться с демоном, чем он означает разветвить Ваш собственный привилегированный процесс.

• Можно использовать authopen команда для чтения создайте или обновите файл (см. authopen).

• Можно использовать системный вызов BSD для изменения уровня полномочий (см. Вызовы для Изменения Уровня полномочий). Эти команды имеют запутывающую семантику. Необходимо стараться использовать их правильно, и очень важно проверить возвращаемые значения этих вызовов, чтобы удостовериться, что они успешно выполнились.

  Обратите внимание на то, что в целом, если Ваш процесс первоначально не работал как корень, он не может поднять свое полномочие с этими вызовами или взять полномочия любого другого пользователя. Однако процесс, работающий как корень, может отбросить (временно или постоянно) те полномочия. Любой процесс может измениться от действия от имени одной группы другому (в наборе групп, которым это принадлежит).

Однако, Вы решаете выполнить свой привилегированный код, необходимо заставить его сделать как можно меньше и гарантировать, что код отбрасывает любое дополнительное полномочие, как только он выполнил свою задачу (см. Запись Привилегированного Помощника). Несмотря на то, что архитектурно это часто - лучшее решение, очень трудно сделать правильно, особенно в первый раз, когда Вы пробуете. Если у Вас нет большого опыта с разветвлением от привилегированных процессов, Вы могли бы хотеть попробовать одно из других решений сначала.

Вызовы для изменения уровня полномочий

Существует несколько команд, которые можно использовать для изменения уровня полномочий программы. Семантика этих команд хитра, и варьируется в зависимости от операционной системы, в которой они используются.

Вот некоторые примечания по обычно используемым системным вызовам изменения уровня полномочий:

• setuid функционируйте устанавливает реальные и эффективные идентификаторы пользователей и сохраненного пользователя ID текущего процесса к указанному значению. setuid функция больше всего сбивает с толку устанавливающих UID системных вызовов. Не только делает разрешение, требуемое использовать этот вызов, отличаются среди различных основанных на UNIX систем, но действие вызова отличается среди различных операционных систем и даже между привилегированными и непривилегированными процессами. При попытке установить эффективный UID, необходимо использовать seteuid функция вместо этого.

• setreuid функция изменяет реальный UID и эффективный UID, и в некоторых случаях, сохраненный UID. Разрешение, требуемое использовать этот вызов, отличается среди различных основанных на UNIX систем, и правило, по которому изменяется сохраненный UID, является сложным. Для этой функции также, если Ваше намерение состоит в том, чтобы установить эффективный UID, необходимо использовать seteuid функция вместо этого.

• seteuid функционируйте устанавливает эффективный UID, оставляя реальный UID без изменений и сохранил UID. В OS X эффективный идентификатор пользователя может быть установлен в значение реального пользователя ID или сохраненного идентификатора пользователя набора. (В некоторых основанных на UNIX системах эта функция позволяет Вам устанавливать EUID в любой реальный UID, сохранил UID или EUID.) Функций, доступных на OS X, которые устанавливают эффективный UID, seteuid функция меньше всего сбивает с толку и маловероятно, чтобы неправильно использоваться.

• setgid функционируйте действует так же к setuid функция, за исключением того, что это устанавливает группу IDs, а не идентификаторы пользователей. Это страдает от тех же недостатков как setuid функция; используйте setegid функция вместо этого.

• setregid функционируйте действует так же к setreuid функция, с теми же недостатками; используйте setegid функция вместо этого.

• setegid функционируйте устанавливает эффективный GID. Если Вы хотите установить EGID, эта функция является предпочтительным вызовом, чтобы использовать.

Для получения дополнительной информации о полномочиях см. главу Полномочий Понимания в Аутентификации, Авторизацию и Руководство по Полномочиям. Для получения информации о setuid и связанные команды, см. Setuid, Демистифицированный Ченом, Вагнером и Дином (Продолжения 11-го Симпозиума Безопасности USENIX, 2002), доступный в http://www .usenix.org/publications/library/proceedings/sec02/full_papers/chen/chen.pdf и страницы руководства для setuid, setreuid, setregid, и setgroups. setuid(2) страница руководства включает информацию о seteuid, setgid, и setegid также.

Предотвращение разветвляющийся от привилегированного процесса

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

Ограничения и риски других механизмов

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

• setuid

  Если исполнимая программа setuid бит установлен, выполнения программы как, независимо от того, что пользователю принадлежит исполнимая программа, независимо от которой процесс запускает его. Существует два подхода к использованию setuid получить корень (или другой пользователь) полномочия при минимизации риска:

  • Запустите свою программу с полномочиями пользователя root, выполните любые привилегированные операции, сразу необходимы, и затем постоянно отбрасывают полномочия.

  • Запуск a setuid инструмент помощника, работающий только настолько же долго по мере необходимости и затем выходящий.

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

  Важно отметить, что, если Вы работаете и с группой ID (GID) и с идентификатором пользователя (UID), отличающийся от тех из пользователя, необходимо отбросить GID прежде, чем отбросить UID. Как только Вы изменили UID, Вы больше не можете изменять GID. Как с каждой связанной с безопасностью работой, необходимо проверить возвращаемые значения вызовов к setuid, setgid, и связанные подпрограммы для проверки они успешно выполнились.

  Для получения дополнительной информации об использовании setuid бит и связанные подпрограммы, посмотрите Подъемные Полномочия Безопасно.

• SystemStarter

  Когда Вы вставляете исполнимую программу /Library/StartupItems каталог, это запускается SystemStarter программа во время начальной загрузки. Поскольку SystemStarter выполнения с полномочиями пользователя root, можно запустить программу с любым уровнем полномочия, которого Вы желаете. Обязательно используйте самый низкий уровень полномочий, который можно использовать, чтобы выполнить задачу и отбросить полномочие как можно скорее.

  Элементы запуска выполняют демонов с полномочием пользователя root в единственном глобальном сеансе; эти процессы служат всем пользователям.

  Для OS X v10.4 и позже, осуждается использование элементов запуска; используйте launchd демон вместо этого. Для получения дополнительной информации об элементах запуска и полномочиях элемента запуска, посмотрите Элементы Запуска в Руководстве по программированию Демонов и Служб.

• AuthorizationExecWithPrivilege

  Authorization Services API обеспечивает AuthorizationExecuteWithPrivileges функция, запускающая привилегированного помощника как пользователя root.

  Несмотря на то, что эта функция может выполнить любой процесс временно с полномочиями пользователя root, это не рекомендуется за исключением установщиков, которые должны быть в состоянии работать от CDs и самовосстановления setuid инструменты. См. Руководство по программированию Authorization Services для получения дополнительной информации.

• xinetd

  В более ранних версиях OS X, xinetd демон был запущен с полномочиями пользователя root при системном запуске и впоследствии запущенных демонах интернет-сервисов, когда они были необходимы. xinetd.conf конфигурационный файл указал UID, и GID каждого демона запустился и порт, который будет использоваться каждой службой.

  Начиная с OS X v10.4, необходимо использовать launchd выполнять услуги, раньше предоставленные xinetd. См. Руководство по программированию Демонов и Служб для получения информации о преобразовании из xinetd к launchd. См. страницы руководства для xinetd(8) и xinetd.conf(5) для получения дополнительной информации о xinetd.

• Прочее.

  При использовании некоторого другого метода для получения поднятого полномочия для процесса, необходимо переключиться на один из методов, описанных здесь, и следовать за предостережениями, описанными в этой главе и в Подъемных Полномочиях Безопасно.

Запись привилегированного помощника

Если Вы читали настолько далеко, и Вы все еще убеждены, что часть Ваших потребностей приложения подняла полномочия, этот раздел обеспечивает некоторые подсказки и пример кода. Кроме того, см. Руководство по программированию Authorization Services для большего уведомления относительно использования Authorization Services и надлежащего пути к фактору приложение.

Как объяснено в документации Authorization Services, очень важно, чтобы Вы проверили права пользователя выполнить привилегированную работу, и прежде и после запуска Вашего привилегированного инструмента помощника. Ваш инструмент помощника, принадлежавший корню и с setuid набор битов, имеет необходимые полномочия для выполнения безотносительно задачи, которую он должен сделать. Однако, если пользователь не имеет прав выполнить эту задачу, Вы не должны запускать инструмент и — если инструмент запускается так или иначе — инструмент должен выйти, не выполняя задачу. Ваш непривилегированный процесс должен сначала использовать Authorization Services, чтобы определить, авторизовывается ли пользователь и аутентифицировать пользователя, если необходимый (это вызывают, предварительно авторизовывая; см. Перечисление 5-1). Тогда запустите свой привилегированный процесс. Привилегированный процесс тогда должен авторизовать пользователя снова, прежде, чем выполнить задачу, требующую поднятых полномочий; см. Перечисление 5-2. Как только задача завершена, привилегированный процесс должен завершиться.

В определении, есть ли у пользователя необходимые полномочия для выполнения задачи, необходимо использовать права, которые Вы определили и поместили в базу данных правил управления сами. Если Вы используете право, предоставленное системой или некоторым другим разработчиком, пользователю мог бы предоставить авторизацию для того права некоторый другой процесс, таким образом получив полномочия к Вашему приложению или доступ к данным, которые Вы не авторизовывали или предназначали. Для получения дополнительной информации о политиках и базе данных правил управления, (см. раздел «The Policy Database» в главе Понятий Авторизации Руководства по программированию Authorization Services).

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

if (ownerUID == _my_uid && ![[contextInfo processName]

    isEqualToString:@"WindowServer"] && ![[contextInfo processName]

    isEqualToString:@"loginwindow"]) {

        [self killPid:pid withSignal:signal];                                      // 1

} else {

    SFAuthorization *auth = [SFAuthorization authorization];

    if (![auth permitWithRight:"com.apple.proccesskiller.kill" flags:

          kAuthorizationFlagDefaults|kAuthorizationFlagInteractionAllowed|

          kAuthorizationFlagExtendRights|kAuthorizationFlagPreAuthorize])    // 2

    {

            AuthorizationRef authRef = [auth authorizationRef];                        // 3

            AuthorizationExternalForm authExtForm;

            OSStatus status = AuthorizationMakeExternalForm(authRef, &authExtForm);    // 4

            if (errAuthorizationSuccess == status) {

                NSData *authData = [NSData dataWithBytes: authExtForm.bytes

                                    length: kAuthorizationExternalFormLength];    // 5

                [_agent killProcess:pid signal:signal authData: authData];                 // 6

            }

    }

}

AuthorizationRef authRef = NULL;

OSStatus status = AuthorizationCreateFromExternalForm(

  (AuthorizationExternalForm *)[authData bytes], &authRef);              // 1

if ((errAuthorizationSuccess == status) && (NULL != authRef)) {

AuthorizationItem right = {"com.apple.proccesskiller.kill",

                                                0L, NULL, 0L};           // 2

AuthorizationItemSet rights = {1, &right};                               // 3

status = AuthorizationCopyRights(authRef, &rights, NULL,

        kAuthorizationFlagDefaults | kAuthorizationFlagInteractionAllowed |

        kAuthorizationFlagExtendRights,    NULL);                        // 4

if (errAuthorizationSuccess == status)

kill(pid, signal);                                                       // 5

else

NSLog(@"Unauthorized attempt to signal process %d with %d",

            pid, signal);                                                // 6

AuthorizationFree(authRef, kAuthorizationFlagDefaults);                  // 7

}

Авторизация и доверительные политики

В дополнение к основным полномочиям, предоставленным BSD, OS X Authorization Services, API позволяет Вам использовать базу данных правил управления, чтобы определить, должен ли объект иметь доступ к определенным функциям или данным в Вашем приложении. Authorization Services включает функции, чтобы считать, добавить, отредактировать и удалить элементы базы данных правил управления.

Необходимо определить собственные доверительные политики и поместить их в базу данных правил управления. Если Вы используете политику, предоставленную системой или некоторым другим разработчиком, пользователю мог бы предоставить авторизацию для права некоторый другой процесс, таким образом получив полномочия к Вашему приложению или доступ к данным, которые Вы не авторизовывали или предназначали. Определите различную политику для каждой работы, чтобы избежать иметь необходимость дать широкие полномочия пользователям, которым нужны только узкие полномочия. Для получения дополнительной информации о политиках и базе данных правил управления, посмотрите раздел «The Policy Database» в главе Понятий Авторизации Руководства по программированию Authorization Services.

Authorization Services не осуществляет средства управления доступом; скорее это аутентифицирует пользователей и сообщает, есть ли у них разрешение выполнить действие, которое они хотят выполнить. Это до Вашей программы, чтобы или отклонить действие или выполнить его.

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

Поскольку расширения ядра не имеют никакого пользовательского интерфейса, Вы не можете вызвать Authorization Services для получения полномочий, которые Вы уже не имеете. Однако в частях Вашего кода, обрабатывающих запросы от пространства пользователя, можно определить, какие полномочия обработка вызовов имеет, и можно оценить списки управления доступом (ACLs; посмотрите раздел «ACLs» в разделе OS X File System Security в Подробной главе Файловой системы Руководства по программированию Файловой системы).

В OS X v10.4 и позже, можно также использовать Авторизацию Ядра (Kauth) подсистема для управления авторизацией. Для получения дополнительной информации о Kauth посмотрите Техническое примечание TN2127, Авторизация Ядра (http://developer .apple.com/technotes/tn2005/tn2127.html).