The most important part of a solution security policy is binding events to security policies (hereinafter also referred to as "event configuration").
The following type of declaration is used for event configuration:
<event type> <event selectors> {<utilized audit profile> <list of called policies> [embedded match declarations]}
In this case:
request, response, error, security, or execute.Please note that the kernel is provided as a separate entity named kl.core.Core for Kaspersky Security System.
audit <profile name> declaration.<class object name>.<policy name> <policy argument>
Policies that do not indicate an object are assumed to belong to the base object.
Each policy always has one argument that is an expression in the PSL language. PSL expressions have a syntax similar to the JSON syntax.
Detailed descriptions of expressions of arguments for each policy of different classes are provided in the section titled "Security policy classes".
Policies can receive the values of arguments of interface methods in the format message.<name>, where <name> is the argument name according to the IDL description of the method.
In addition to arguments of the called method, the src_sid and dst_sid values denoting the handles of entities can be passed to a policy. The entities indicated by the src_sid and dst_sid values depend on the event type (see below).
A list of called policies is not required if there is at least one embedded match declaration.
Match declarations let you create "embedded bindings" that inherit selectors of the parent declaration.The same event can be bound to multiple declarations of the same type. When this kind of event occurs, the policies of all declarations matching this event will be called. Policies are called sequentially in the order in which they are encountered in the description file for the solution security policy.
An event that is not bound to any declaration is always denied.
Entity startup event (execute declaration)
An entity startup event is configured using the execute declaration. You can also indicate the src selector (name of the entity initiating the startup) and dst selector (name of the started entity). For example:
/* Two policies will be called when the "Server" entity is started: request_state.allow and request_state.enter.
The first policy returns an "allowed" decision only if the "request_state" object has the "ready_to_start" state.
The second policy switches the request_state object to the "not_ready" state and returns the "allowed" decision. */
execute dst=Server {
request_state.allow {sid: dst_sid, states: ["ready_to_start"]}
request_state.enter {sid: dst_sid, state: "not_ready"}
}
If at least one of the policies bound to an event returned the "deny" decision, the states of objects will not be changed.
In the example above, if the request_state object has a state other than ready_to_start, startup of the Server entity will be denied, and the state of the request_state object will not be changed even if the request_state.enter policy is called.
If the src and dst selectors are not indicated, the execute declaration configures the startup of all entities by all entities in the solution:
/* Configure startup of all entities (any entity can start any other entity). */
execute {
grant ()
}
In subsequent configuration examples, the list of policies contains a single grant () policy for simplicity.
Request forwarding event (request declaration)
A request forwarding event is configured by using the request declaration. For example:
/* Configuration of all requests. */
request {
grant ()
}
The src and dst selectors are used to configure a request from a specific client to a specific server:
/* Configuration of all requests from the Client entity. */
request src=Client {
grant ()
}
/* Configuration of all requests to the Server entity. */
request dst=Server {
grant ()
}
The src and dst selectors can be used together:
/* Configuration of requests from the Client entity to the Server entity. */
request src=Client, dst=Server {
grant ()
}
If you need to define a called method of a specific interface implementation, use the method selector together with the endpoint selector:
/* Configuration of requests for calling the Ping method of the "pingImpl" interface implementation of the "pingComp" component instance. */
request endpoint=pingComp.pingImpl, method=Ping {
grant ()
}
To configure queries to all implementations of a specific interface, use the interface selector (only together with the method selector):
/* Configuration of requests for calling the Ping method of any Ping interface implementations. */
request interface=Ping, method=Ping {
grant ()
}
Response forwarding event (response declaration)
A response forwarding event is configured similarly to a request forwarding event.
The response declaration is used. The dst selector designates the client entity and the src selector designates the server entity. For example:
/* Configuration of responses from the "Server" entity to the "Client" entity when calling the "Ping" method of the "pingImpl" interface implementation of the "pingComp" component instance. */
response src=Server, dst=Client, endpoint=pingComp.pingImpl, method=Ping {
grant ()
}
Error forwarding event (error declaration)
An error forwarding event occurs when the server entity sets the error flag in a response message before sending it. For more details, see Managing errors in IDL.
An error forwarding event is configured similarly to a response forwarding event.
The error declaration is used. The dst selector designates the client entity and the src selector designates the server entity. For example:
/* Configuration of error forwarding from the "Server" entity to the "Client" entity when calling the "Ping" method of the "pingImpl" interface implementation of the "pingComp" component instance. */
error src=Server, dst=Client, endpoint=pingComp.pingImpl, method=Ping {
grant ()
}
Security interface query event (security declaration)
A query via the security interface is configured using the security declaration. The src selector must contain the name of the entity that calls the method, and the method selector must contain the name of the security interface method:
/* When the "Sdcard" entity calls the "Register" method of the security interface, an "allowed" decision is always returned. */
security src=Sdcard, method=Register {
grant ()
}
If you need to specify a method of a security interface implemented in an embedded component, use the method selector together with the endpoint selector:
/* When the "Sdcard" entity calls the "Register" method of the "pingSec" security interface of the "pingComp" component instance, an "allowed" decision is always returned. */
security src=Sdcard, endpoint=pingComp.pingSec, method=Register {
grant ()
}
A security interface method call differs from other types of configured events in that the entity queries the Kaspersky Security System instead of the kernel. For this reason, the entity receives the "grant" or "deny" decision.
Embedded bindings (match declaration)
Match declarations let you create "embedded bindings" that inherit the event type and selectors of the parent declaration.
Embedded match declarations specify the parent declarations and combine with them via the AND conjunction, but must not conflict with them.
For example:
/* Configuration of requests from the "Client" entity to the "Server" entity. */
request src=Client, dst=Server {
/* Configuration of requests from the "Client" entity to specific methods of the "Server" entity. */
match endpoint=pingComp.pingImpl, method=Ping { grant () }
match endpoint=pingComp.pingImpl, method=Pong { grant () }
}
Page top