Важнейшая часть политики безопасности решения – связывание событий с политиками безопасности (далее также "конфигурирование событий").
Для конфигурирования событий используются декларации следующего вида:
<вид события> <селекторы события> {<используемый профиль аудита> <список вызываемых политик> [вложенные декларации match]}
Здесь:
request, response, error, security или execute.Обратите внимание: для Kaspersky Security System ядро представлено отдельной сущностью kl.core.Core.
audit <имя профиля>.<имя объекта класса>.<имя политики> <аргумент политики>
Политики без указания объекта считаются принадлежащими объекту base.
У каждой политики всегда имеется один аргумент, являющийся выражением на языке PSL. PSL-выражения имеют синтаксис, схожий с синтаксисом JSON.
Подробные описания выражений аргументов для каждой из политик различных классов содержатся в разделе "Классы политик безопасности".
Политики могут получать значения аргументов интерфейсных методов в формате message.<name>, где <name> – имя аргумента в соответствии с IDL-описанием метода.
Помимо аргументов вызываемого метода, в политику можно передавать значения src_sid и dst_sid, обозначающие дескрипторы сущностей. На какие сущности указывают значения src_sid и dst_sid, зависит от типа события (см. ниже).
Список вызываемых политик необязателен, если присутствует хотя бы одна вложенная декларация match.
match позволяют создавать "вложенные связывания", наследующие селекторы родительской декларации.Одно и то же событие может быть связано с несколькими декларациями одного типа. При наступлении такого события будут вызваны политики из всех деклараций, подходящих под это событие. Политики вызываются последовательно, в том же порядке, в котором они встречаются в файле описания политики безопасности решения.
Событие, которое не связано ни одной декларацией, всегда запрещено.
Событие запуска сущности (декларация execute)
Событие запуска сущности конфигурируется с помощью декларации execute. При этом можно указать селекторы src (имя сущности, инициирующей запуск) и dst (имя запускаемой сущности), например:
/* При запуске сущности "Server" будут вызваны две политики: request_state.allow и request_state.enter.
Первая политика возвращает решение "разрешено" только если объект "request_state" находится в состоянии "ready_to_start".
Вторая политика переводит объект request_state в состояние "not_ready" и возвращает решение "разрешено". */
execute dst=Server {
request_state.allow {sid: dst_sid, states: ["ready_to_start"]}
request_state.enter {sid: dst_sid, state: "not_ready"}
}
Если хотя бы одна из политик, связанных с событием, вернула решение "запретить", то состояния объектов изменены не будут.
В примере выше, если объект request_state находится в состоянии, отличном от ready_to_start, то запуск сущности Server будет запрещен, а состояние объекта request_state не изменится, несмотря на вызов политики request_state.enter.
Если селекторы src и dst не указаны, то декларация execute конфигурирует запуск всех сущностей всеми сущностями в решении:
/* Конфигурирование запуска всех сущностей (любая сущность может запускать любую другую сущность). */
execute {
grant ()
}
В дальнейших примерах конфигурирования список политик для простоты содержит единственную политику grant ().
Событие отправки запроса (декларация request)
Событие отправки запроса конфигурируется с помощью декларации request. Например:
/* Конфигурирование всех запросов. */
request {
grant ()
}
Чтобы сконфигурировать запрос от конкретного клиента к конкретному серверу, используются селекторы src и dst:
/* Конфигурирование всех запросов от сущности Client. */
request src=Client {
grant ()
}
/* Конфигурирование всех запросов к сущности Server. */
request dst=Server {
grant ()
}
Селекторы src и dst можно использовать совместно:
/* Конфигурирование запросов от сущности Client к сущности Server. */
request src=Client, dst=Server {
grant ()
}
Если необходимо задать вызываемый метод конкретной реализации интерфейса, используется селектор method совместно с селектором endpoint:
/* Конфигурирование запросов для вызова метода Ping реализации интерфейса "pingImpl" экземпляра компонента "pingComp". */
request endpoint=pingComp.pingImpl, method=Ping {
grant ()
}
Чтобы сконфигурировать обращения ко всем реализациям конкретного интерфейса, используйте селектор interface (только совместно с селектором method):
/* Конфигурирование запросов для вызова метода Ping любых реализаций интерфейса Ping. */
request interface=Ping, method=Ping {
grant ()
}
Событие отправки ответа (декларация response)
Событие отправки ответа конфигурируется аналогично событию отправки запроса.
Используется декларация response. Селектор dst обозначает сущность-клиент, селектор src – сущность-сервер. Например:
/* Конфигурирование ответов от сущности "Server" к сущности "Client" при вызове метода "Ping" реализации интерфейса "pingImpl" экземпляра компонента "pingComp". */
response src=Server, dst=Client, endpoint=pingComp.pingImpl, method=Ping {
grant ()
}
Событие отправки ошибки (декларация error)
Событие отправки ошибки возникает когда сущность-сервер выставляет флаг ошибки в сообщении-ответе перед его отправкой. Подробнее см. Работа с ошибками в IDL.
Событие отправки ошибки конфигурируется аналогично событию отправки ответа.
Используется декларация error. Селектор dst обозначает сущность-клиент, селектор src – сущность-сервер. Например:
/* Конфигурирование отправки ошибок от сущности "Server" к сущности "Client" при вызове метода "Ping" реализации интерфейса "pingImpl" экземпляра компонента "pingComp". */
error src=Server, dst=Client, endpoint=pingComp.pingImpl, method=Ping {
grant ()
}
Событие обращения по интерфейсу безопасности (декларация security)
Обращение по интерфейсу безопасности конфигурируется с помощью декларации security. В селекторе src должно быть имя сущности, вызывающей метод, в селекторе method – имя метода интерфейса безопасности:
/* При вызове сущностью "Sdcard" метода "Register" интерфейса безопасности всегда возвращается решение "разрешено". */
security src=Sdcard, method=Register {
grant ()
}
Если необходимо указать метод интерфейса безопасности, реализованный во вложенном компоненте, используется селектор method совместно с селектором endpoint:
/* При вызове сущностью "Sdcard" метода "Register" интерфейса безопасности "pingSec" экземпляра компонента "pingComp" всегда возвращается решение "разрешено". */
security src=Sdcard, endpoint=pingComp.pingSec, method=Register {
grant ()
}
Вызов метода интерфейса безопасности отличается от других типов конфигурируемых событий тем, что к Kaspersky Security System обращается сущность, а не ядро. Поэтому именно сущность получает решение "разрешить" или "запретить".
Вложенные связывания (декларация match)
Декларации match позволяют создавать "вложенные связывания", наследующие тип события и селекторы родительской декларации.
Вложенные match-декларации уточняют родительские декларации, объединяются с ними через конъюнкцию (AND) и не должны противоречить им.
Например:
/* Конфигурирование запросов от сущности "Client" к сущности "Server". */
request src=Client, dst=Server {
/* Конфигурирование запросов от сущности "Client" к конкретным методам сущности "Server". */
match endpoint=pingComp.pingImpl, method=Ping { grant () }
match endpoint=pingComp.pingImpl, method=Pong { grant () }
}
В начало