Содержание

Синтаксис языка PSL

Синтаксис языка PSL

Базовые правила

Декларации могут располагаться в файле в любом порядке.
Одна декларация может быть записана в одну или несколько строк. Вторая и последующие строки декларации должны быть записаны с отступами относительно первой строки. Закрывающая фигурная скобка, которая завершает декларацию, может быть записана на уровне первой строки.
В многострочной декларации используются отступы разных размеров, чтобы отразить вложенность конструкций, составляющих эту декларацию. Строки многострочной конструкции, заключенные в фигурные скобки, и открывающая фигурная скобка должны быть записаны с отступом относительно первой строки этой конструкции. Закрывающая фигурная скобка многострочной конструкции может быть записана с отступом или на уровне первой строки конструкции.
Поддерживаются однострочные и многострочные комментарии:
/* Это комментарий

И это тоже */

// Ещё один комментарий

Типы деклараций

В языке PSL есть следующие типы деклараций:

описание глобальных параметров политики безопасности решения;
включение PSL-файлов;
включение EDL-файлов;
создание объектов моделей безопасности;
привязка методов моделей безопасности к событиям безопасности;
описание профилей аудита безопасности.

В этом разделе

Описание глобальных параметров политики безопасности решения

Включение PSL-файлов

Включение EDL-файлов

Создание объектов моделей безопасности

Привязка методов моделей безопасности к событиям безопасности

Описание профилей аудита безопасности

Типы данных в языке PSL

Пример простейшей политики безопасности решения

В начало

Описание глобальных параметров политики безопасности решения

Глобальными являются следующие параметры политики безопасности решения:

Execute-интерфейс, через который ядро KasperskyOS обращается к модулю безопасности Kaspersky Security Module, чтобы сообщить о запуске ядра или об инициации запуска сущностей ядром или другими сущностями. Чтобы задать этот интерфейс, нужно использовать декларацию:
execute: kl.core.Execute

В настоящее время в KasperskyOS поддерживается только один execute-интерфейс Execute, определенный в файле kl/core/Execute.idl. (Этот интерфейс состоит из одного метода main, который не имеет параметров и не выполняет никаких действий. Метод main зарезервирован для возможного использования в будущем.)
[Опционально] Глобальный профиль аудита безопасности и начальный уровень аудита безопасности. Чтобы задать эти параметры, нужно использовать декларацию:
audit default = <имя профиля аудита безопасности> <уровень аудита безопасности>

Пример:

audit default = global 0

По умолчанию в качестве глобального используется пустой профиль аудита безопасности empty, описанный в файле toolchain/include/nk/base.psl из состава KasperskyOS SDK, и уровень аудита безопасности 0.

В начало

Включение PSL-файлов

Для включения PSL-файла нужно использовать декларацию:

use <ссылка на PSL-файл._>

Ссылка на PSL-файл представляет собой путь к PSL-файлу (без расширения и точки перед ним) относительно директории, которая включена в набор директорий, где компилятор nk-psl-gen-c ищет PSL-, IDL-, CDL-, EDL-файлы. (Этот набор директорий задается параметрами скрипта makekss вида "-I <путь к файлам>".) В качестве разделителя в описании пути используется точка. Декларация завершается последовательностью символов ._.

Пример:

use policy_parts.flow_part._

Эта декларация включает файл flow_part.psl, который находится в директории policy_parts. Директория policy_parts должна находиться в одной из директорий, где компилятор nk-psl-gen-c выполняет поиск PSL-, IDL-, CDL-, EDL-файлов. Например, директория policy_parts может располагаться в одной директории с PSL-файлом, содержащим эту декларацию.

Включение PSL-файла с формальным представлением модели безопасности

Чтобы использовать методы требуемой модели безопасности, нужно включить PSL-файл с формальным представлением этой модели. PSL-файлы с формальными представлениями моделей безопасности находятся в <KOS_KASPERSKY> SDK по пути:

toolchain/include/nk

Пример:

/* Включение файла base.psl с формальным представлением модели

* безопасности Base */

use nk.base._

/* Включение файла flow.psl с формальным представлением модели

* безопасности Flow */

use nk.flow._

/* Компилятор nk-psl-gen-c должен быть настроен на поиск

* PSL-, IDL-, CDL-, EDL-файлов в директории toolchain/include. */

В начало

Включение EDL-файлов

Чтобы включить EDL-файл для ядра KasperskyOS, нужно использовать декларацию:

use EDL kl.core.Core

Чтобы включить EDL-файл для прикладной или системной программы (или для драйвера), нужно использовать декларацию:

use EDL <ссылка на EDL-файл>

Ссылка на EDL-файл представляет собой путь к EDL-файлу (без расширения и точки перед ним) относительно директории, которая включена в набор директорий, где компилятор nk-psl-gen-c ищет PSL-, IDL-, CDL-, EDL-файлы. (Этот набор директорий задается параметрами скрипта makekss вида "-I <путь к файлам>".) В качестве разделителя в описании пути используется точка.

Пример:

/* Включение файла UART.edl, который находится

* в KasperskyOS SDK по пути sysroot-*-kos/include/kl/drivers. */

use EDL kl.drivers.UART

/* Компилятор nk-psl-gen-c должен быть настроен на поиск

* PSL-, IDL-, CDL-, EDL-файлов в директории sysroot-*-kos/include. */

Компилятор nk-psl-gen-c находит IDL-, CDL-файлы через EDL-файлы, так как EDL-файлы содержат ссылки на соответствующие CDL-файлы, а CDL-файлы содержат ссылки на соответствующие CDL-, IDL-файлы.

В начало

Создание объектов моделей безопасности

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

Чтобы создать объект модели безопасности, нужно использовать декларацию:

policy object <имя объекта модели безопасности : название модели безопасности> {

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

}

Параметры объекта модели безопасности специфичны для модели безопасности. Описание параметров и примеры создания объектов разных моделей безопасности приведены в разделе "Модели безопасности".

В начало

Привязка методов моделей безопасности к событиям безопасности

Чтобы выполнить привязку методов моделей безопасности к событию безопасности, нужно использовать декларацию:

<вид события безопасности> [селекторы события безопасности] {

[профиль аудита безопасности]

<вызываемые правила моделей безопасности>

}

Вид события безопасности

Чтобы задать вид события безопасности, используются следующие спецификаторы:

request – отправка IPC-запросов;
response – отправка IPC-ответов;
error – отправка IPC-ответов, содержащих сведения об ошибках;
security – попытки обращений сущностей к модулю безопасности Kaspersky Security Module через интерфейс безопасности;
execute – инициация запусков сущностей или запуск ядра KasperskyOS.

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

Для запуска сущностей не используется механизм IPC. Но когда инициируется запуск сущности, ядро обращается к модулю безопасности, сообщая сведения об инициаторе запуска и запускаемой сущности. Поэтому с точки зрения автора политики безопасности решения можно считать, что запуск сущности – это передача IPC-сообщения от инициатора запуска к запускаемой сущности. Также при запуске ядра можно считать, что ядро отправляет IPC-сообщение самому себе.

Селекторы события безопасности

Селекторы события безопасности позволяют уточнить описание события безопасности заданного вида. Используются следующие селекторы:

src=<имя класса сущностей/ядро> – сущности заданного класса или ядро KasperskyOS являются источниками IPC-сообщений;
dst=<имя класса сущностей/ядро> – сущности заданного класса или ядро являются приемниками IPC-сообщений;
interface=<имя интерфейса> – описывает следующие события безопасности:
- клиенты пытаются обратиться к серверам или ядру через интерфейс с заданным именем;
- сущности обращаются к модулю безопасности Kaspersky Security Module через интерфейс безопасности с заданным именем;
- серверы или ядро отправляют клиентам результаты обработки обращений через интерфейс с заданным именем;
endpoint=<квалифицированное имя службы> – описывает следующие события безопасности:
- клиенты пытаются использовать службу серверов или ядра с заданным именем;
- серверы или ядро отправляют клиентам результаты использования службы с заданным именем;
method=<имя метода> – описывает следующие события безопасности:
- клиенты пытаются обратиться к серверам или ядру, вызывая метод службы с заданным именем;
- сущности обращаются к модулю безопасности, вызывая метод интерфейса безопасности с заданным именем;
- серверы или ядро отправляют клиентам результаты вызова метода службы с заданным именем;
- ядро сообщает о своем запуске модулю безопасности, вызывая метод execute-интерфейса с заданным именем;
- ядро инициирует запуски сущностей, вызывая метод execute-интерфейса с заданным именем;
- сущности инициируют запуски других сущностей, в результате чего ядро вызывает метод execute-интерфейса с заданным именем.

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

Классы сущностей, интерфейсы, службы, методы должны называться так, как они называются в IDL-, CDL-, EDL-описаниях. Ядро должно называться kl.core.Core.

Если селекторы не указаны, участниками события безопасности считаются все сущности и ядро (кроме событий вида security, где ядро не участвует).

Можно использовать комбинации селекторов. При этом селекторы можно разделять запятыми.

На использование селекторов есть ограничения. Для событий безопасности вида execute нельзя использовать селекторы interface и endpoint. Для событий безопасности вида security нельзя использовать селекторы dst и endpoint.

Также есть ограничения на комбинации селекторов. Для событий безопасности видов request, response и error селектор method можно использовать только совместно с одним или обоими селекторами endpoint и interface. (Селекторы method, endpoint и interface должны быть согласованы, то есть метод должен соответствовать службе или интерфейсу, служба должна соответствовать интерфейсу.) Для событий безопасности вида request селектор endpoint можно использовать только совместно с селектором dst. Для событий безопасности видов response и error селектор endpoint можно использовать только совместно с селектором src.

Профиль аудита безопасности

Профиль аудита безопасности задается конструкцией audit <имя профиля аудита безопасности>. Если профиль аудита безопасности не задан, используется глобальный профиль аудита безопасности.

Вызываемые правила моделей безопасности

Вызываемые правила моделей безопасности задаются списком из конструкций следующего вида:

[имя объекта модели безопасности.]<имя правила модели безопасности> <параметр>

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

[имя объекта модели безопасности.]<имя выражения модели безопасности> <параметр>

Также в качестве входных данных для методов моделей безопасности (правил и выражений) могут использоваться параметры интерфейсных методов. (О получении доступа к параметрам интерфейсных методов см. "Модель безопасности Struct"). Кроме этого, входными данными для методов моделей безопасности могут быть значения SID сущностей и ядра KasperskyOS, которые задаются ключевыми словами src_sid и dst_sid. Первое означает SID сущности (или ядра), которая является источником IPC-сообщения. Второе означает SID сущности (или ядра), которая является приемником IPC-сообщения (при обращениях к модулю безопасности Kaspersky Security Module dst_sid использовать нельзя).

Для вызовов некоторых правил и выражений моделей безопасности можно не указывать имя объекта модели безопасности или использовать операторы. Подробнее о методах моделей безопасности см. "Модели безопасности".

Вложенные конструкции для привязки методов моделей безопасности к событиям безопасности

В одной декларации можно выполнить привязку методов моделей безопасности к разным события безопасности одного вида. Для этого нужно использовать match-секции, которые представляют собой конструкции вида:

match <селекторы события безопасности> {

[профиль аудита безопасности]

<вызываемые правила моделей безопасности>

}

Match-секции могут быть вложены в другую match-секцию. Match-секция использует одновременно свои селекторы события безопасности и селекторы события безопасности уровня декларации и всех match-секций, которые "оборачивают" эту match-секцию. Также match-секция применяет по умолчанию профиль аудита безопасности своего контейнера (match-секции предыдущего уровня или уровня декларации), но можно задать отдельный профиль аудита безопасности для match-секции.

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

choice <вызов выражения модели безопасности, проверяющего выполнение условий> {

"<условие 1>" : [{] // Условная секция 1

[профиль аудита безопасности]

<вызываемые правила моделей безопасности>

[}]

"<условие 2>" : ... // Условная секция 2

...

_ : ... // Условная секция, если ни одно условие не выполняется.

}

Конструкцию choice можно использовать внутри match-секции. Условная секция использует селекторы события безопасности и профиль аудита безопасности своего контейнера, но можно задать отдельный профиль аудита безопасности для условной секции.

Если при обработке события безопасности выполняется сразу несколько условий, описанных в конструкции choice, то срабатывает только одна условная секция, соответствующая первому в списке подходящему условию.

В качестве выражения, проверяющего выполнение условий в конструкции choice, можно использовать только те выражения, которые предназначены специально для этого. Некоторые модели безопасности содержат такие выражения (подробнее см. "Модели безопасности").

В начало

Описание профилей аудита безопасности

Для выполнения аудита безопасности нужно ассоциировать объекты моделей безопасности с профилем (профилями) аудита безопасности. Профиль аудита безопасности (далее также профиль аудита) объединяет в себе конфигурации аудита безопасности (далее также конфигурации аудита), каждая из которых задает объекты моделей безопасности, покрываемые аудитом, а также условия выполнения аудита. Можно задать глобальный профиль аудита (подробнее см. "Описание глобальных параметров политики безопасности решения") и/или назначить профиль (профили) аудита на уровне деклараций привязки методов моделей безопасности к событиям безопасности, и/или назначить профиль (профили) аудита на уровне match-секций или choice-секций (подробнее см. "Привязка методов моделей безопасности к событиям безопасности").

Независимо от того, используются профили аудита или нет, данные аудита содержат сведения о решениях "запрещено", которые приняты модулем безопасности Kaspersky Security Module при некорректности IPC-сообщений и обработке событий безопасности, не связанных ни с одним правилом моделей безопасности.

Чтобы описать профиль аудита безопасности, нужно использовать декларацию:

audit profile <имя профиля аудита безопасности> =

{ <уровень аудита безопасности>:

// Описание конфигурации аудита безопасности

{ <имя объекта модели безопасности>:

{ kss : <условия выполнения аудита безопасности, связанные с результатами

вызовов правил модели безопасности>

[, условия выполнения аудита безопасности, специфичные для модели безопасности]

}

[,]...

...

}

[,]...

...

}

Уровень аудита безопасности

Уровень аудита безопасности (далее уровень аудита) является глобальным параметром политики безопасности решения и представляет собой беззнаковое целое число, которое задает активную конфигурацию аудита безопасности. (Слово "уровень" здесь означает вариант конфигурации и не предполагает обязательной иерархии.) Уровень аудита можно изменять в процессе работы модуля безопасности Kaspersky Security Module. Для этого используется специальный метод модели безопасности Base, вызываемый при обращении сущностей к модулю безопасности через интерфейс безопасности (подробнее см. "Модель безопасности Base"). Начальный уровень аудита задается совместно с назначением глобального профиля аудита (подробнее см. "Описание глобальных параметров политики безопасности решения"). В качестве глобального можно явно назначить пустой профиль аудита empty.

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

Уровни аудита можно использовать, например, чтобы регулировать детализацию аудита. Чем выше уровень аудита, тем выше детализация. Чем выше детализация, тем больше объектов моделей безопасности покрывается аудитом и/или меньше ограничений применяется в условиях выполнения аудита.

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

Имя объекта модели безопасности

Имя объекта модели безопасности указывается, чтобы методы, которые предоставляются этим объектом, могли быть покрыты аудитом. Эти методы будут покрыты аудитом при их вызовах, если условия выполнения аудита будут соблюдены.

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

Имена объектов моделей безопасности, как и имена методов, предоставляемых этими объектами, попадают в данные аудита.

Условия выполнения аудита безопасности

Условия выполнения аудита безопасности задаются отдельно для каждого объекта модели безопасности.

Чтобы задать условия выполнения аудита, связанные с результатами вызовов правил моделей безопасности, нужно использовать следующие конструкции:

["granted"] – аудит выполняется, если вызванное правило вернуло результат "разрешено";
["denied"] – аудит выполняется, если вызванное правило вернуло результат "запрещено";
["granted", "denied"] – аудит выполняется, если вызванное правило вернуло результат "разрешено" или "запрещено";
[] – аудит не выполняется независимо от того, какой результат вернуло вызванное правило.

Условия выполнения аудита, связанные с результатами вызовов правил, не применяются к выражениям. Эти условия должны быть заданы (любой возможной конструкцией), даже если модель безопасности содержит только выражения, поскольку этого требует синтаксис языка PSL.

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

Профиль аудита безопасности для тракта аудита безопасности

Тракт аудита безопасности включает ядро, а также сущности Klog и KlogStorage, которые соединены IPC-каналами по схеме "ядро – Klog – KlogStorage". Методы моделей безопасности, которые связаны с передачей данных аудита через этот тракт, не должны покрываться аудитом. В противном случае это приведет к лавинообразному росту данных аудита, так как передача данных будет порождать новые данные.

Чтобы "подавить" аудит, заданный профилем более широкой области действия (например, глобальным или профилем на уровне декларации привязки методов моделей безопасности к события безопасности), нужно назначить пустой профиль аудита empty на уровне декларации привязки методов моделей безопасности к событиям безопасности или на уровне match-секции либо choice-секции.

В начало

Типы данных в языке PSL

Типы данных, поддерживаемые в языке PSL, приведены в таблице ниже.

Типы данных в языке PSL

Обозначения типов	Описание типов
`UInt8`, `UInt16`, `UInt32`, `UInt64`	Беззнаковое целое число
`SInt8`, `SInt16`, `SInt32`, `SInt64`	Знаковое целое число
`Boolean`	Логический тип Логический тип включает два значения: `true` и `false`.
`Text`	Текстовый тип
`()`	Тип `Unit` Тип `Unit` включает одно неизменяемое значение. Используется как заглушка в случаях, когда синтаксис языка PSL требует указать какие-либо данные, но фактически эти данные не требуются. Например, тип Unit можно использовать, чтобы объявить метод, который не имеет параметров (аналогично тому, как тип `void` используется в C/C++).
`"`<`тип>"`	Текстовый литерал Текстовый литерал включает одно неизменяемое текстовое значение. Примеры определений текстовых литералов: `""` `"granted"`
`<тип>`	Целочисленный литерал Целочисленный литерал включает одно неизменяемое целочисленное значение. Примеры определений числовых литералов: `12` `-5` `0xFFFF`
<`тип 1 \| тип 2`> [`\|`]`...`	Вариантный тип Вариантный тип объединяет два и более типов и может выступать в роли любого из них. Примеры определений вариантных типов: `Boolean \| ()` `UInt8 \| UInt16 \| UInt32 \| UInt64` `"granted" \| "denied"`
`{` [`имя поля : тип поля`] [`,`] `...` `...` `}`	Словарь Словарь состоит из полей одного или нескольких типов. Словарь может быть пустым. Примеры определений словарей: `{}` `{ handle : Handle` `, rights : UInt32` `}`
`[`[`тип`] [`,`] `...]`	Кортеж Кортеж состоит из полей одного или нескольких типов, расположенных в порядке перечисления типов. Кортеж может быть пустым. Примеры определений кортежей: `[]` `["granted"]` `[Boolean, Boolean]`
`Set<`<`тип элементов`>`>`	Множество Множество включает ноль и более уникальных элементов одного типа. Примеры определений множеств: `Set<"granted" \| "denied">` `Set<Text>`
`List<`<`тип элементов`>`>`	Список Список включает ноль и более элементов одного типа. Примеры определений списков: `List<Boolean>` `List<Text \| ()>`
`Map<`<`тип ключа, тип значения`>`>`	Ассоциативный массив Ассоциативный массив включает ноль и более записей типа "ключ-значение" с уникальными ключами. Пример определения ассоциативного массива: `Map<UInt32, UInt32>`
`Array<`<`тип элементов, число элементов`>`>`	Массив Массив включает заданное число элементов одного типа. Пример определения массива: `Array<UInt8, 42>`
`Sequence<`<`тип элементов, число элементов`>`>`	Последовательность Последовательность включает от ноля до заданного числа элементов одного типа. Пример определения последовательности: `Sequence<SInt64, 58>`

Псевдонимы некоторых типов PSL

В файле nk/base.psl из состава KasperskyOS SDK определены типы данных, которые используются как типы параметров (или структурных элементов параметров) и возвращаемых значений для методов разных моделей безопасности. Псевдонимы и определения этих типов приведены в таблице ниже.

Псевдонимы и определения некоторых типов данных в языке PSL

Псевдоним типа	Определение типа
`Unsigned`	Беззнаковое целое число `UInt8 \| UInt16 \| UInt32 \| UInt64`
`Signed`	Знаковое целое число `SInt8 \| SInt16 \| SInt32 \| SInt64`
`Number`	Целое число `Unsigned \| Signed`
`ScalarLiteral`	Скалярный литерал `() \| Boolean \| Number`
`Literal`	Литерал `ScalarLiteral \| Text`
`Sid`	Тип идентификатора безопасности SID `UInt32`
`Handle`	Тип идентификатора безопасности SID `Sid`
`HandleDesc`	Словарь, содержащий поля для SID и маски прав дескриптора `{ handle : Handle` `, rights : UInt32` `}`
`Cases`	Тип данных, принимаемых выражениями моделей безопасности, вызываемыми в конструкции `choice` для проверки выполнения условий `List<Text \| ()>`
`KSSAudit`	Тип данных, задающих условия выполнения аудита безопасности `Set<"granted" \| "denied">`

Отображение типов IDL на типы PSL

Для описания параметров интерфейсных методов используются типы данных языка IDL. Входные данные для методов моделей безопасности имеют типы из языка PSL. Набор типов данных в языке IDL отличается от набора типов данных в языке PSL. Поскольку параметры интерфейсных методов, передаваемые в IPC-сообщениях, могут использоваться как входные данные для методов моделей безопасности, автору политики безопасности решения нужно понимать, как типы IDL отображаются на типы PSL.

Целочисленные типы IDL отображаются на целочисленные типы PSL, а также на вариантные типы PSL, объединяющие эти целочисленные типы (в том числе с другими типами). Например, знаковые целочисленные типы IDL отображаются на тип Signed в PSL, целочисленные типы IDL отображаются на тип ScalarLiteral в PSL.

Тип Handle в IDL отображается на тип HandleDesc в PSL.

Объединения и структуры IDL отображаются на словари PSL.

Массивы и последовательности IDL отображаются на массивы и последовательности PSL соответственно.

Строковые буферы в IDL отображаются на текстовый тип PSL.

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

В начало

Пример простейшей политики безопасности решения

Ниже приведена простейшая политика безопасности решения вида "все разрешено" для решения, состоящего из пользовательских сущностей Client и Server, а также сущности Einit и ядра KasperskyOS, представленного сущностью kl.core.Core.

Эта политика разрешает:

все взаимодействия сущностей (отправку любых запросов и ответов);
запуск всех сущностей;

Использование такой политики безопасности недопустимо в реальных решениях. Более сложная политика безопасности решения показана в примере ping.

security.psl

execute: kl.core.Execute

use nk.base._

use EDL Einit

use EDL kl.core.Core

use EDL Client

use EDL Server

/* Запуск сущностей разрешен */

execute {

grant ()

}

/* Отправка и получение запросов, ответов и ошибок разрешены.

Это означает, что любая сущность может вызывать методы других сущностей и ядра. */

request {

grant ()

}

response {

grant ()

}

error {

grant ()

}

/* При обращения к модулю безопасности Kaspersky Security Module всегда

* будет получено решение "разрешено". */

security {

grant ()

}

В начало