Основанная на полномочиях безопасность

Основанная на полномочиях безопасность (Capability-based security, буквально — Основанная на возможностях безопасность, иногда переводится как модель безопасности на основе мандатных ссылок^[1]) — это концепция в проектировании защищенных вычислительных систем, одна из существующих моделей безопасности. Полномочие (в некоторых системах известная как key) представляет собой передаваемый, неизменяемый токен полномочий. Она относится к значению, которое ссылается на объект вместе с соответствующим набором прав доступа. Пользовательская программа в основанной на полномочиях операционной системе^[англ.] должна использовать полномочия для доступа к объекту. Модель на основе полномочий относится к принципу проектирования пользовательских программ таким образом, чтобы они напрямую обменивались полномочиями друг с другом в соответствии с принципом минимальных привилегий, а также к инфраструктуре операционной системы, необходимой для эффективного и безопасного осуществления таких транзакций. Безопасность, основанная на полномочиях, следует противопоставлять подходу, использующему традиционные традиционные разрешения UNIX и списки контроля доступа .

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

Введение

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

Полномочия обычно реализуются как привилегированная структура данных, состоящая из раздела, определяющего права доступа, и раздела, однозначно идентифицирующего объект, к которому осуществляется доступ. Пользователь получает доступ к структуре данных или объекту не напрямую, а через дескриптор.На практике это используется подобно файлововому дескриптору в традиционных операционных системах (традиционный дескриптор), но для доступа ко всем объектам в системе. Полномочия обычно хранятся операционной системой в списке с определённым механизмом, предотвращающим прямое изменение содержимого полномочий программой (чтобы подделать права доступа или изменить объект, на который она указывает). Некоторые системы также были основаны на адресации на основе мандатной адресации^{[англ.][2]} (аппаратная поддержка полномочий), например, Plessey System 250^[англ.].

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

Полномочия, обсуждаемые в данной статье, не следует путать с 1e/2c «полномочиями» Portable Operating System Interface (POSIX) . Последние представляют собой привилегии общего характера, которые нельзя передавать между процессами.

Примеры

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

Предположим, что в адресном пространстве пользовательского процесса существует следующая строка:

/etc/passwd

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

/etc/passwd
O_RDWR

Эта пара определяет объект вместе с набором прав доступа. Однако пара все еще не является полномочиями, поскольку владение этими значениями процессом пользователя ничего не говорит о том, будет ли этот доступ действительно законным.

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

int fd = open("/etc/passwd", O_RDWR);

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

Совместное использование процессами

В традиционных операционных системах программы часто взаимодействуют друг с другом и с хранилищем, используя ссылки, подобные тем, что приведены в первых двух примерах. Имена путей часто передаются как параметры командной строки, отправляются через сокеты и хранятся на диске. Эти ссылки не являются полномочиями и должны быть проверены перед использованием. В таких системах ключевым вопросом становится: «под чьей властью должна быть оценена данная ссылка?» Это приобретает особую важность для процессов, которые должны действовать от имени двух различных сущностей, обладающих полномочиями. Такие процессы становятся уязвимы для программной ошибки, известной как проблема обманутого посредника^[3][4], что очень часто приводит к бреши в защите.

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

Один из новых подходов к решению этой проблемы заключается в использовании ортогонально персистеной^[5][6] операционной системы. В такой системе нет необходимости удалять сущности и аннулировать их полномочия, а затем использовать механизм, подобный списку контроля доступа (ACL), для их восстановления в дальнейшем. Операционная система постоянно поддерживает целостность и безопасность полномочий, содержащихся во всех хранилищах, как временных, так и постоянных. Частично это достигается за счёт того, что все задачи сериализации выполняет сама система, а не пользовательские программы, как это происходит в большинстве операционных систем. Поскольку пользовательские программы освобождены от этой ответственности, нет необходимости доверять им воспроизведение только легальных полномочий или проверять запросы на доступ с помощью механизма контроля доступа. Примером такой реализации является Flex machine^[англ.] начала 1980-х годов.

Полномочия POSIX

Черновик 1003.1e стандарта Portable Operating System Interface (POSIX) определяет концепцию разрешений, называемых «полномочиями». Однако полномочия POSIX отличаются от полномочий, описанных в данной статье. Полномочия POSIX не связаны с каким-либо объектом. Процесс, обладающий полномочием CAP_NET_BIND_SERVICE может прослушивать любой TCP порт с номером ниже 1024. Эта система реализована в Linux.^[7]

В отличие от этого, Capsicum Unix сочетает истинную модель системы полномочий с дизайном Unix и API POSIX. Полномочия Capsicum представляют собой усовершенствованную форму файлового дескриптора, передаваемого между процессами права, и позволяют ссылаться на дополнительные типы объектов, помимо классических POSIX, такие как процессы. В режиме полномочий Capsicum процессы не могут использовать глобальные пространства имен (например, пространство имен файловой системы) для поиска объектов, а должны наследовать их или получать их по делегированию. Эта система нативно присутствует во FreeBSD, но существуют патчи для других систем^[8].

Реализации

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

• Tahoe-LAFS^[англ.], файловая система на основе полномочий
• FreeBSD Capsicum^[9][10]
• Genode^[11]
• Fuchsia^[12]
• HarmonyOS (OpenHarmony^[англ.])^[13][14][15]
• Phantom OS^[16]
• RedoxOS
• семейство микроядер L4:
  • OKL4 от Open Kernel Labs
  • SeL4 от NICTA
  • Fiasco.OC и NOVA от TU Dresden
• WebAssembly System Interface (WASI)

Поддержка прекращена

• Amoeba распределенная операционная система
• GNOSIS^[англ.], операционная система, разработанная в Tymshare^[англ.]
  • KeyKOS^[англ.], преемник GNOSIS
    • EROS, Extremely Reliable Operating System, преемник KeyKOS
• Cambridge CAP computer^[англ.]
• Hydra (операционная система)^[англ.], часть проекта C.mmp^[англ.] в Университете Карнеги — Меллона
• IBM System/38 и AS/400
• Intel iAPX 432
• Plessey System 250^[англ.]
• Flex^[англ.]