3OS

Разделение доступа к конкретным методам объекта

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

Драйвер устройства (как объект) предоставляет некоторое API (методы), которое может использоваться ядром, другими драйверами, системным приложением, пользовательским приложением. При этом некоторые методы могут использоваться только ядром и другими драйверами, но быть недоступными другим приложениям:

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

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

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

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

Эта схема надежна только в том случае, если в пользовательском процессе работает “объект-тень”, а реально код объекта лежит за пределами адресного пространства процесса. В случае же если пользовательский процесс явно включает в себя код объекта, то ничего не мешает пользователю произвести его модификацию “на лету” и исключить проверку. Отсюда следует вывод: все системные объекты должны предоставляться пользователю “тенями”.