Основанная на полномочиях безопасность
Основанная на полномочиях безопасность (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
- KeyKOS[англ.], преемник GNOSIS
- Cambridge CAP computer[англ.]
- Hydra (операционная система)[англ.], часть проекта C.mmp[англ.] в Университете Карнеги — Меллона
- IBM System/38[англ.]* и AS/400
- Intel iAPX 432
- Plessey System 250[англ.]
- Flex[англ.]
Примечания
[править | править код]- ↑ kjam. Введение в безопасность на основе мандатных ссылок (англ. Capability-based security). PVSM (30 июля 2012). Дата обращения: 10 ноября 2025.
- ↑
capability-based addressing = мандатная адресация.
Статья: Patterson, David A.; Hennessy,, John L. Новый золотой век для компьютерной архитектуры (18 февраля 2019). Дата обращения: 10 ноября 2025. - ↑ Turner-Trauring, Itamar. Never use the word “User” in your code (21 сентября 2018). Дата обращения: 10 ноября 2025.
- ↑ What is cross-site request forgery? CLOUDFLARE. Дата обращения: 10 ноября 2025.
- ↑ Дмитрий Викторович Дагаев. Ареальные типы данных в инструментальном подходе к программированию // Программные системы и вычислительные методы. — 2025. — Вып. 2. — doi:10.7256/2454-0714.2025.2.73776.
Описание ортогональной персистентности - ↑ Юный ОС-Ризёчер №0x0d // «Хакер». — 2004.
Объяснение ортогональной персистентности - ↑
capabilities(7)— страница справки man для разработчика Linux — обзоры, стандарты, другая информация (англ.) - ↑
capsicum(4)— страница справки man по интерфейсам ядра FreeBSD (англ.) - ↑ Capsicum(4).
- ↑ Capsicum: practical capabilities for UNIX. Дата обращения: 9 июля 2024.
- ↑ Genode OS: a breath of fresh air in operating system and software security (англ.). Rudd-O.com. Дата обращения: 21 декабря 2023.
- ↑ Google's Fuchsia operating system runs on virtually anything (амер. англ.). Engadget (14 августа 2016). Дата обращения: 21 декабря 2023.
- ↑ Děcký, Martin. Microkernel-based and Capability-based Operating Systems. D3S. Дата обращения: 23 декабря 2023.
- ↑ docs/en/application-dev/security/accesstoken-overview.md at master · openharmony/docs (англ.). GitHub. Дата обращения: 4 мая 2024.
- ↑ DARKNAVY. AVSS Report: System Security Adversarial Capability Preliminary Evaluation of iOS, Android, and HarmonyOS - Kernel (англ.). DARKNAVY (11 июня 2024). Дата обращения: 4 июля 2024.
- ↑ Dziuba, Ted. Russian rides Phantom to OS immortality. The Register. Дата обращения: 31 декабря 2023.
Литература
[править | править код]- Henry M. Levy. Capability-Based Computer Systems. — Digital Equipment Corporation, 1984. — ISBN 0-932376-22-3. Доступна электронная версия http://www.cs.washington.edu/homes/levy/capabook/
- The EROS Project.
- Mark S. Miller, Ka-Ping Yee, Jonathan Shapiro. Capability Myths Demolished // Technical Report. — Systems Research Laboratory, Johns Hopkins University. — Вып. SRL2003-02.
- Levy. The Cambridge CAP Computer (1988).
- E, a programming language based around capability security (ERights.org)
Литература для дальнейшего чтения
[править | править код]- Capability-based addressing: Theodore A. Linden (Декабрь 1976). Operating System Structures to Support Security and Reliable Software. ACM Computing Surveys. 8 (4): 409—445. doi:10.1145/356678.356682. hdl:2027/mdp.39015086560037. ISSN 0360-0300. S2CID 16720589.
- Li Gong, A Secure Identity-Based Capability System, sp, p. 56, 1989 IEEE Symposium on Security and Privacy, 1989
- Capability-based addressing
- A hardware implementation of capability-based addressing
- An implementation of capabilities on the PDP-11/45
- IBM System/38 support for capability-based addressing
- EROS: a fast capability system
POSIX «полномочия» в Linux:
- POSIX Capabilities & Files
- POSIX file capabilities: Parceling the power of root
- Making Root Unprivileged
- Security issues and new risks linked to POSIX file capabilities
- Linux manual page for "capabilities(7)"
- Working with Linux capabilities