Авторизация

Базовая часть BSD ядра OS X обеспечивает модель обеспечения безопасности пользователя и владельца. Каждый объект файловой системы, такой как файл или каталог, имеет владельца и ряд полномочий или атрибутов, указывая то, что владелец, одна группа и все другие в состоянии сделать с объектом.

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

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

В этих случаях основанная на политике модель обеспечения безопасности, используемая в дополнение к полномочиям BSD, обеспечивает дополнительные важные функции Вашего приложения. В основанной на политике системе пользователь запрашивает авторизацию — действие предоставления права или полномочия — выполнить привилегированную работу. Авторизация выполняется через агент, таким образом, пользователь не должен доверять приложению пароль. Агент является пользовательским интерфейсом — работающий от имени Сервера безопасности — раньше получал пароль пользователя или другую форму идентификации, также гарантирующей непротиворечивость между приложениями. Сервер безопасности — демон Core Services в OS X, имеющем дело с авторизацией и аутентификацией — определяет, не могут ли никто, все, или только определенные пользователи выполнить привилегированную работу.

Авторизация предлагает Вам тонкозернистое управление предоставлением пользовательских полномочий выполнить задачи администрирования и другие привилегированные операции. Using Authorization Services позволяет Вам ограничивать части своего приложения, добавлять меры предосторожности дополнительного обеспечения, и все еще удовлетворять модель обеспечения безопасности BSD. Необходимо избежать обходить модель обеспечения безопасности BSD — например, не выполняйте процессы как корень — если у Вас нет альтернативы, когда необходимо ограничить включенный объем кода.

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

Рисунок 1-2 показывает окно, пользователь присматривает за успешной предварительной авторизацией. Однако приложение Установок системы все еще сразу выполняет авторизацию перед выполнением любой привилегированной работы.

Аутентификация

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

Рисунок 1-3 показывает пример аутентификации в приложении Установок системы.

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

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

Сервер безопасности

Сервер безопасности обрабатывает запросы авторизации способом, аналогичным тому, как чиновник иммиграционной службы обрабатывает визы. Таблица 1-1 сравнивает два процесса.

Для инициирования сеанса авторизации между приложением и Сервером безопасности Вы создаете ссылку авторизации. Сервер безопасности использует ссылку авторизации для доступа к сеансу авторизации. Вы передаете ссылку авторизации на почти каждую функцию Authorization Services.

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

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

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

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

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

Права

Когда Ваша авторизация запросов приложения, Вы передаете требуемые права (набор прав авторизации) к Серверу безопасности. Сервер безопасности сравнивает права, которые Вы передаете ключам в базе данных правил управления. Когда соответствие найдено, Сервер безопасности использует правила, связанные с ключом для определения авторизации. Для получения дополнительной информации о базе данных правил управления посмотрите Базу данных правил управления.

Необходимо создать права использование приложения. Права используют иерархическое пространство имен. Право должно начаться с обратного доменного имени Вашей организации. Право должно тогда указать имя Вашего приложения и стать более определенным — например, com.myOrganization.myProduct.myRight. Права, которые являются определенными для OS X, имеют начинающиеся правильные имена system.

Ваше право должно представлять отдельное действие с одним или группой целей. Например, право могло бы представлять отдельное действие перезапуска демона, такой как com.myOrganization.myProduct.inetd.restart перезапускать интернет-демона, или com.myOrganization.myProduct.daemons.restart перезапускать группу демонов.

Поскольку можно запросить многократные права на того же пользователя, нет никакой потребности создать права, представляющие комбинации действий. Например, в приложении классов-и-копий, если Вы называете право com.myOrganization.myProduct.transcripts.create и другое право com.myOrganization.myProduct.grades.edit, нет никакой потребности в отдельном праве com.myOrganization.myProduct.createTranscriptsAndEditGrades.

Имя, которое Вы выбираете для права, должно быть целесообразным пользователю. Например, system.finder.trash.empty с большей готовностью понят, чем system.finder.trashDirectory.deleteFiles.

База данных правил управления

База данных правил управления содержит ряд правил использование Сервера безопасности для авторизации прав для пользователя. Каждое правило состоит из ряда атрибутов. Правила предварительно сконфигурированы, когда OS X установлен, но приложение может изменить их в любое время. Поскольку любое приложение может изменить права в базе данных, Ваше приложение должно принять во внимание все возможные сценарии. Таблица 1-2 описывает атрибуты, определенные для правил.

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

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

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

Как пример того, как Сервер безопасности соответствует право правилу в базе данных правил управления, рассмотрите заявление классов-и-копий. Запросы приложения право com.myOrganization.myProduct.transcripts.create. Сервер безопасности ищет право в базе данных правил управления. Не находя точное совпадение, Сервер безопасности ищет правило с подстановочным набором ключей к com.myOrganization.myProduct.transcripts., com.myOrganization.myProduct., com.myOrganization., или com.— в том порядке — проверяющий на самое долгое соответствие. Если никакой подстановочный ключ не соответствует, то Сервер безопасности использует универсальное правило. Сервер безопасности запрашивает аутентификацию от пользователя. Пользователь обеспечивает имя пользователя и пароль для аутентификации как элемент группы admin. Сервер безопасности создает учетные данные на основе аутентификации пользователя и права, которое требуют. Учетные данные указывают, что другие приложения могут использовать их, и Сервер безопасности устанавливает истечение срока в пять минут.

Три минуты спустя дочерний процесс приложения запускает. Дочерний процесс запрашивает право com.myOrganization.myProduct.transcripts.create. Сервер безопасности находит учетные данные, видит, что это позволяет совместно использовать и использует право. Две с половиной минуты спустя тот же дочерний процесс запрашивает право com.myOrganization.myProduct.transcripts.create снова, но право истекло. Сервер безопасности начинает процесс создания новых учетных данных путем консалтинга с базой данных правил управления и запроса аутентификации пользователя.

Кэш учетных данных и диалог аутентификации

Когда Вы вызываете, Вы могли бы заметить это AuthorizationCreate функционируйте или AuthorizationCopyRights функция для получения прав для пользователя иногда диалог аутентификации появляется, и в других случаях диалоговое окно не появляется. Причина этого поведения связана с настройками в базе данных правил управления и путем в который удостоверения пользователя кэшей Сервера безопасности.

Учетные данные - что-то, что Сервер безопасности знает об определенном пользователе, таком как факт, что определенный пользователь ввел имя и пароль действительного пользователя.

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

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

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

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

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

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

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

Следовательно, ли вызов к AuthorizationCopyRights результаты в диалоге аутентификации зависят от того, кэшировал ли Сервер безопасности уже требуемые учетные данные.

Единственный способ гарантировать, что учетные данные, полученные, когда Вы запрашиваете право, не совместно используются с другими экземплярами авторизации, состоит в том, чтобы уничтожить учетные данные. Для этого вызовите AuthorizationFree функция с флагом kAuthorizationFlagDestroyRights.

Сценарии

Существует три основных сценария, вовлекающие Authorization Services: простые самоограниченные приложения, factored приложения и установщики.

Простые, самоограниченные приложения

Самоограниченное приложение требует, чтобы определенные функции были доступны только определенной группой пользователей. В простом самоограниченном приложении это разделение функций сделано в главном приложении. Вы используете Authorization Services в этой ситуации, потому что этим видом мелкозернистого ограничения не могут управлять полномочия BSD.

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

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

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

Можно выполнить авторизацию, не создавая ссылку авторизации, если необходимо авторизовать только один раз — например, когда приложение сначала запускает. Чтобы сделать так, Вы используете результат вызова авторизации непосредственно. Поскольку в этом случае Вы не создавали ссылку авторизации, Вы не должны выпускать ее. Однократная авторизация описана более подробно в разделе Authorizing.

Приложения Factored

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

Работа, которую выполняет Ваше приложение, могла бы быть ограничена моделью обеспечения безопасности BSD. Такое приложение является системным ограниченным приложением. Например, приложение, требующее перезапуска интернет-демона (inetd) должен иметь полномочия пользователя root, но это работает с полномочиями пользователя, запустившего его.

Рекомендуется что Вы факторные и самоограниченные приложения и системные ограниченные приложения. Факторинг Ваше приложение предоставляет два преимущества. Прежде всего, проще контролировать factored приложение, потому что привилегированная работа выполняется в отдельном процессе инструментом помощника. Второе - то, что factored приложение обеспечивает больше безопасности. В nonfactored приложении не только необходимо положить, что нет никаких дыр в системе безопасности в коде, но также и никаких дыр во всем коде, с которым Вы соединяетесь.

В то время как блок-схема для инструмента помощника показана на рисунке 1-6, рисунок 1-5 показывает блок-схему для части приложения factored приложения.

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

Приложение должно передать ссылку авторизации на инструмент помощника. Поскольку Вы не можете передать саму ссылку авторизации между двумя процессами, приложение использует Authorization Services для создания внешней, формы переводимой ссылки авторизации для отправки к ее инструменту помощника.

Инструмент помощника использует Authorization Services для создания ссылки авторизации из внешней ссылки авторизации. Инструмент помощника запрашивает авторизацию и использует результаты решить, продолжить ли привилегированную работу.

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

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

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

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

• Сделайте выполнение приложения как корень путем вызова себя со специальной функцией Authorization Services.

• Установите setuid бит приложения и измените его владельца, чтобы базироваться, и затем использовать специальную функцию Authorization Services.

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

И первые и вторые опции являются нарушением защиты, ожидающим для случая. Когда привилегированное выполнение приложения, это вызывает специальную функцию, которую Authorization Services обеспечивает —AuthorizationExecuteWithPrivileges (см. Вызов Инструмента Помощника, как Поддерживают больше подробных данных). Вызывание этой функции выполняет любое приложение или инструмент с полномочиями пользователя root, независимо от владельца приложения или инструмента. Это очень опасно, так как могут быть легко заменены части приложения.

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

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

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

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

Самовосстановление setuid инструмент тогда проверяет, работает ли это как корень. Если это работает как корень, то авторизация выполняется и, на основе результата, привилегированная работа выполняется. Если самовосстановление setuid инструмент не работает как корень, то это вызывает себя с AuthorizationExecuteWithPrivileges функционируйте и передает себя флаг самовосстановления.

Когда новое самовосстановление setuid процесс инструмента запускается, это проверяет, был ли передан флаг самовосстановления. Если флаг самовосстановления был передан, то самовосстановление setuid инструмент восстанавливает ссылку авторизации и восстанавливает бит setuid. После того, как самовосстановление setuid инструмент работает как корень, это выполняет авторизацию и продолжается как нормальный инструмент помощника.

Установщики

Не все установщики требуют авторизации — только те, которым нужны специальные полномочия скопировать файлы в ограниченные каталоги, внести изменения в ограниченные файлы или установить setuid биты.

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

Рисунок 1-8 показывает блок-схему использования приложения Authorization Services для вызова установщика. В этом случае приложение создает ссылку авторизации и выполняет предварительную авторизацию. Если пользователь успешно предварительно авторизовывает, то Вы вызываете AuthorizationExecuteWithPrivileges функция для выполнения установщика с полномочиями пользователя root.

Рисунок 1-9 показывает блок-схему для вызовов Authorization Services, выполняемых в самом установщике. Авторизация должна быть выполнена перед любой привилегированной работой.