Binding methods of security models to security events

To create an attachment between methods of security models and a security event, use the following declaration:

<security event type> [security event selectors] {

[security audit profile]

<called security model methods>

}

Security event type

To define the security event type, use the following specifiers:

• request – sending IPC requests.
• response – sending IPC responses.
• error – sending IPC responses containing information about errors.
• security – processes querying the Kaspersky Security Module via the security interface.
• execute – initializing the startups of processes or the startup of the KasperskyOS kernel.

When processes interact with the security module, they use a mechanism that is different from IPC. However, when describing a policy, queries sent by processes to the security module can be viewed as the transfer of IPC messages because processes actually transmit messages to the security module (the recipient is not indicated in these messages).

The IPC mechanism is not used to start processes. However, when the startup of a process is initiated, the kernel queries the security module and provides information about the initiator of the startup and the started process. For this reason, the policy description developer can consider the startup of a process to be analogous to sending an IPC message from the startup initiator to the started process. When the kernel is started, this is analogous to the kernel sending an IPC message to itself.

Security event selectors

Security event selectors let you clarify the description of the defined type of security event. You can use the following selectors:

• src=<kernel/process class name> – processes of the defined class or the KasperskyOS kernel are the sources of IPC messages.
• dst=<kernel/process class name> – processes of the defined class or the kernel are the recipients of IPC messages.
• interface=<interface name> – describes the following security events:
  • Clients attempt to use the endpoints of servers or the kernel with the defined interface.
  • Processes query the Kaspersky Security Module via the defined security interface.
  • The kernel or servers send clients the results from using the endpoints with the defined interface.
• component=<component name> – describes the following security events:
  • Clients attempt to use the core or server endpoints provided by the defined component.
  • The kernel or servers send clients the results from using the endpoints provided by the defined component.
• endpoint=<qualified endpoint name> – describes the following security events:
  • Clients attempt to use the defined core or server endpoints.
  • The kernel or servers send clients the results from using the defined endpoint.
• method=<method name> – describes the following security events:
  • Clients attempt to query servers or the kernel by calling the defined method of the endpoint.
  • Processes query the security module by calling the defined method of the security interface.
  • The kernel or servers send clients the results from calling the defined method of the endpoint.
  • The kernel notifies the security module about its startup by calling the defined method of the execute interface.
  • The kernel initiates the startup of processes by calling the defined method of the execute interface.
  • Processes initiate the startup of other processes, which results in the kernel calling the defined method of the execute interface.

Process classes, components, instances of components, interfaces, endpoints, and methods must be named the same as they are in the IDL, CDL, and EDL descriptions. The kernel must be named kl.core.Core.

The qualified name of the endpoint has the format <path to endpoint.endpoint name>. The path to the endpoint is a sequence of component instance names separated by dots. Among these component instances, each subsequent component instance is embedded into the previous one, and the last one provides the endpoint with the defined name.

For security events, specify the qualified name of the security interface method if you need to use the security interface defined in a CDL description. (If you need to use a security interface defined in an EDL description, it is not necessary to specify the qualified name of the method.) The qualified name of a security interface method is a construct in the format <path to security interface.method name>. The path to the security interface is a sequence of component instance names separated by dots. Among these component instances, each subsequent component instance is embedded into the previous one, and the last one supports the security interface that includes the method with the defined name.

If selectors are not specified, the participants of a security event may be any process and the kernel (except security events in which the kernel cannot participate).

You can use combinations of selectors. Selectors can be separated by commas.

There are restrictions on the use of selectors. The interface, component, and endpoint selectors cannot be used for security events of the execute type. The dst, component, and endpoint selectors cannot be used for security events of the security type.

There are also restrictions on combinations of selectors. For security events of the request, response and error types, the method selector can only be used together with one of the endpoint, interface, or component selectors or a combination of them. (The method, endpoint, interface and component selectors must be coordinated. In other words, the method, endpoint, interface, and component must be interconnected.) For security events of the request type, the endpoint selector can be used only together with the dst selector. For security events of the response and error types, the endpoint selector can be used only together with the src selector.

The type and selectors of a security event form the security event description. It is recommended to describe security events with maximum precision to allow only the required interactions between different processes and between processes and the kernel. If IPC messages of the same type are always verified when processing the defined event, the description of this event is maximally precise.

To ensure that IPC messages of the same type correspond to a security event description, one of the following conditions must be fulfilled for this description:

• For events of the request, response and error type, the "interface method-endpoint-server class or kernel" chain is unequivocally defined. For example, the security event description request dst=Server endpoint=net.Net method=Send corresponds to IPC messages of the same type, and the security event description request dst=Server corresponds to any IPC message sent to the Server.
• For security events, the security interface method is specified.
• The execute-interface method is indicated for execute events.

  There is currently support for only one fictitious method of the main execute-interface. This method is used by default, so it does not have to be defined through the method selector. This way, any description of an execute security event corresponds to IPC messages of the same type.

Security audit profile

To define a security audit profile, use the following construct:

audit <security audit profile name>

If a security audit profile is not defined, the global security audit profile is used.

Called security model methods

To call a security model method, use the following construct:

[security model object name.]<security model method name> <parameter>

Data of PSL-supported types can be used as the parameter. However, the following special considerations should be taken into account:

• If a security model method does not actually have a parameter, this method formally has a Unit-type parameter designated as ().
• If a security model method parameter is a dictionary {name of field 1 : value of field 1[, name of field 2 : value of field 2]...}, this parameter does not need to be enclosed in parentheses.
• If the security model method parameter is not a dictionary and does not have the Unit type, this parameter must be enclosed in parentheses.

You can call one or more methods by using the same or different security model objects. Security model rules can use the parameter to receive values returned by expressions of security models.

When a security event is processed by the Kaspersky Security Module, expressions are called before rules. Therefore, expressions do not receive the changes made by rules. For example, if a declaration of attachment between StaticMap security model methods and security events first specifies the set rule and then specifies the get_uncommited expression for the same resource, the get_uncommited expression will return the key value that was defined before the current security event was processed instead of the key value that is defined by the set rule when processing the current security event. The key value defined by the set rule when processing the current security event can be returned by the get_uncommited expression only when processing subsequent security events if the security module returns the "allowed" decision as a result of processing the current security event. If the security module returns a "denied" decision as a result of processing the current security event, all changes made by rules and expressions invoked during processing of the current security event will be discarded.

A security model method (rule or expression) can use the parameter to receive the parameters of interface methods. (For details about obtaining access to parameters of interface methods, see "Struct security model"). A security model method can also use the parameter to receive the SID values of processes and the KasperskyOS kernel that are defined by the reserved words src_sid and dst_sid. The first reserved word refers to the SID of the process (or kernel) that is the source of the IPC message. The second reserved word refers to the SID of the process (or kernel) that is the recipient of the IPC message (dst_sid cannot be used for queries to the Kaspersky Security Module).

You do not have to indicate the security model object name to call certain security model methods. Also, some of the security model methods must be called using operators instead of the call construct. For details about the methods of security models, see KasperskyOS Security models.

Embedded constructs for binding methods of security models to security events

In one declaration, you can bind methods of security models to different security events of the same type. To do so, use the match sections that consist of the following types of constructs:

match <security event selectors> {

[security audit profile]

<called security model methods>

}

Match sections can be embedded into another match section. A match section simultaneously uses its own security event selectors and the security event selectors at the level of the declaration and all match sections in which this match section is "wrapped". By default, a match section applies the security audit profile of its own container (match section of the preceding level or the declaration level), but you can define a separate security audit profile for the match section.

In one declaration, you can define different variants for processing a security event depending on the conditions in which this event occurred (for example, depending on the state of the finite-state machine associated with the resource). To do so, use the conditional sections that are elements of the following construct:

choice <call of the security model expression that verifies fulfillment of conditions> {

"<condition 1>" : [{] // Conditional section 1

<called security model methods>

[}]

"<condition 2>" : ... // Conditional section 2

...

_ : ... // Conditional section, if no condition is fulfilled.

}

The choice construct can be used within a match section. A conditional section uses the security event selectors and security audit profile of its own container.

If multiple conditions described in the choice construct are simultaneously fulfilled when a security event is processed, only the one conditional section corresponding to the first true condition on the list is triggered.

You can verify the fulfillment of conditions in the choice construct only by using the expressions that are specially intended for this purpose. Some security models contain these expressions (for more details, see KasperskyOS Security models).

Only text and integer literals, logical values and the _ character designating an always true condition can be used as conditions.

Examples of binding security model methods to security events

See "Examples of binding security model methods to security events", "Example descriptions of basic security policies for KasperskyOS-based solutions", and "KasperskyOS security models".