Безопасность на основе возможностей — это концепция в разработке безопасных вычислительных систем, одна из существующих моделей безопасности . Возможность (известная в некоторых системах как ключ ) — это передаваемый, неподдельный токен полномочий. Она относится к значению, которое ссылается на объект вместе с соответствующим набором прав доступа . Пользовательская программа в операционной системе на основе возможностей должна использовать возможность для доступа к объекту. Безопасность на основе возможностей относится к принципу проектирования пользовательских программ таким образом, чтобы они напрямую делились возможностями друг с другом в соответствии с принципом наименьших привилегий , и к инфраструктуре операционной системы, необходимой для того, чтобы сделать такие транзакции эффективными и безопасными. Безопасность на основе возможностей следует противопоставлять подходу, который использует традиционные разрешения UNIX и списки контроля доступа .
Хотя большинство операционных систем реализуют средство, напоминающее возможности, они, как правило, не обеспечивают достаточной поддержки, чтобы позволить обмену возможностями между, возможно, взаимно недоверяющими субъектами быть основным средством предоставления и распределения прав доступа по всей системе. Система, основанная на возможностях, напротив, разработана с учетом этой цели.
Возможности достигают своей цели по улучшению безопасности системы, будучи использованными вместо поддельных ссылок . Поддельная ссылка (например, имя пути ) идентифицирует объект, но не указывает, какие права доступа подходят для этого объекта и пользовательской программы, которая содержит эту ссылку. Следовательно, любая попытка доступа к указанному объекту должна быть проверена операционной системой на основе внешних полномочий запрашивающей программы, как правило, с помощью использования списка контроля доступа (ACL). Вместо этого в системе с возможностями сам факт того, что пользовательская программа обладает этой возможностью, дает ей право использовать указанный объект в соответствии с правами, которые указаны этой возможностью. Теоретически система с возможностями устраняет необходимость в любом списке контроля доступа или аналогичном механизме, предоставляя всем сущностям все и только те возможности, которые им действительно понадобятся.
Возможности обычно реализуются как привилегированная структура данных , которая состоит из раздела, который определяет права доступа, и раздела, который однозначно идентифицирует объект, к которому осуществляется доступ. Пользователь не получает доступ к структуре данных или объекту напрямую, а вместо этого через дескриптор . На практике он используется во многом как дескриптор файла в традиционной операционной системе (традиционный дескриптор), но для доступа к каждому объекту в системе. Возможности обычно хранятся операционной системой в списке, с некоторым механизмом, предотвращающим прямое изменение программой содержимого возможности (чтобы подделать права доступа или изменить объект, на который она указывает). Некоторые системы также были основаны на адресации на основе возможностей (аппаратная поддержка возможностей), например Plessey System 250 .
Программы, обладающие возможностями, могут выполнять над ними функции, такие как передача их другим программам, преобразование их в менее привилегированную версию или удаление их. Операционная система должна гарантировать, что только определенные операции могут происходить с возможностями в системе, чтобы поддерживать целостность политики безопасности.
Возможности, обсуждаемые в этой статье, не следует путать с "возможностями" Portable Operating System Interface ( POSIX ) 1e/2c. Последние представляют собой привилегии общего назначения, которые не могут передаваться между процессами.
Возможность определяется как защищенная ссылка на объект , которая в силу своего владения пользовательским процессом предоставляет этому процессу возможность (отсюда и название) взаимодействовать с объектом определенными способами. Эти способы могут включать чтение данных, связанных с объектом, изменение объекта, выполнение данных в объекте как процесса и другие возможные права доступа. Возможность логически состоит из ссылки, которая уникально идентифицирует конкретный объект, и набора из одного или нескольких таких прав.
Предположим, что в пространстве памяти пользовательского процесса существует следующая строка:
/etc/пароль
Хотя это идентифицирует уникальный объект в системе, оно не определяет права доступа и, следовательно, не является возможностью. Предположим, что вместо этого есть следующая пара значений:
/etc/парольО_РДВР
Эта пара идентифицирует объект вместе с набором прав доступа. Однако эта пара все еще не является возможностью, поскольку обладание пользовательским процессом этими значениями ничего не говорит о том, будет ли этот доступ фактически законным.
Теперь предположим, что пользовательская программа успешно выполняет следующий оператор:
int fd = open ( "/etc/passwd" , O_RDWR ); Переменная fdтеперь содержит индекс дескриптора файла в таблице дескрипторов файлов процесса. Этот дескриптор файла является возможностью. Его существование в таблице дескрипторов файлов процесса достаточно, чтобы показать, что процесс действительно имеет законный доступ к объекту. Ключевой особенностью этой договоренности является то, что таблица дескрипторов файлов находится в памяти ядра и не может напрямую управляться пользовательской программой.
В традиционных операционных системах программы часто взаимодействуют друг с другом и с хранилищем, используя ссылки, подобные тем, что приведены в первых двух примерах. Имена путей часто передаются как параметры командной строки, отправляются через сокеты и сохраняются на диске. Эти ссылки не являются возможностями и должны быть проверены перед использованием. В этих системах центральным вопросом является «на чьем основании будет оцениваться данная ссылка?» Это становится критической проблемой, особенно для процессов, которые должны действовать от имени двух различных субъектов, имеющих полномочия. Они становятся восприимчивыми к ошибке программирования, известной как проблема перепутанного заместителя , которая очень часто приводит к дыре в безопасности .
В системе, основанной на возможностях, сами возможности передаются между процессами и хранилищем с использованием механизма, известного операционной системе для поддержания целостности этих возможностей.
Один из новых подходов к решению этой проблемы предполагает использование ортогонально персистентной операционной системы. В такой системе нет необходимости отбрасывать сущности и делать их возможности недействительными, и, следовательно, требовать ACL-подобный механизм для восстановления этих возможностей в более позднее время. Операционная система поддерживает целостность и безопасность возможностей, содержащихся во всех хранилищах, как энергозависимых, так и энергонезависимых, в любое время; отчасти выполняя все задачи сериализации самостоятельно, а не требуя этого от пользовательских программ, как это происходит в большинстве операционных систем. Поскольку пользовательские программы освобождены от этой ответственности, нет необходимости доверять им воспроизведение только законных возможностей или проверку запросов на доступ с использованием механизма контроля доступа . Примером реализации является машина Flex начала 1980-х годов.
Проект 1003.1e интерфейса портативной операционной системы (POSIX) определяет концепцию разрешений, называемых «возможностями». Однако возможности POSIX отличаются от возможностей в этой статье. Возможность POSIX не связана ни с одним объектом; процесс, имеющий возможность CAP_NET_BIND_SERVICE, может прослушивать любой порт TCP ниже 1024. Эта система есть в Linux. [1]
Напротив, Capsicum Unix гибридизирует настоящую модель системы возможностей с дизайном Unix и API POSIX. Возможности Capsicum — это усовершенствованная форма файлового дескриптора, делегируемое право между процессами и дополнительными типами объектов за пределами классического POSIX, такими как процессы, на которые можно ссылаться через возможности. В режиме возможностей Capsicum процессы не могут использовать глобальные пространства имен (например, пространство имен файловой системы) для поиска объектов и должны вместо этого наследовать или быть делегированными им. Эта система изначально присутствует в FreeBSD, но исправления доступны для других систем. [2]
Известные исследовательские и коммерческие системы, использующие безопасность на основе возможностей, включают в себя следующее:
«Возможности» POSIX в Linux: