Binding methods of security models to security events
To bind methods of security models to a security event, use the following declaration:
<security event type> [security event selectors] {
[security audit profile]
<called security model rules>
}
Security event type
The following specifiers are used to define the security event type:
request– sending IPC requests.response–sending IPC responses.error– sending IPC responses containing information about errors.security– entities attempting to query the Kaspersky Security Module via the security interface.execute– initializing the startups of entities or the startup of the KasperskyOS kernel.
When entities interact with the security module, they use a mechanism that is different from IPC. However, when developing a solution security policy, queries sent by entities to the security module can be viewed as the transfer of IPC messages because entities actually transmit messages to the security module (the recipient is not indicated in these messages).
The IPC mechanism is not used to start entities. However, when the startup of an entity is initiated, the kernel queries the security module and provides information about the initiator of the startup and the started entity. For this reason, the author of a solution security policy can consider the startup of an entity to be analogous to sending an IPC message from the startup initiator to the started entity. 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. The following selectors are used:
src=<kernel/entity class name> – entities of the defined class or the KasperskyOS kernel are the sources of IPC messages.dst=<kernel/entity class name> – entities of the defined class or the kernel are the recipients of IPC messages.interface=<interface name>- Clients attempt to query servers or the kernel via the interface with the defined name.
- Entities query the Kaspersky Security Module via the security interface with the defined name.
- The kernel or servers send clients the results from processing queries via the interface with the defined name.
endpoint=<qualified service name> – describes the following security events:- Clients attempt to use the service of servers or the kernel with the defined name.
- The kernel or servers send clients the results from using the service with the defined name.
method=<method name> – describes the following security events:- Clients attempt to query servers or the kernel by calling the method of the service with the defined name.
- Entities query the security module by calling the method of the security interface with the defined name.
- The kernel or servers send clients the results from calling the method of the service with the defined name.
- The kernel notifies the security module about its startup by calling the method of the execute interface with the defined name.
- The kernel initiates the startup of entities by calling the method of the execute interface with the defined name.
- Entities initiate the startup of other entities, which results in the kernel calling the method of the execute interface with the defined name.
The qualified name of the service has the format <path to service.service name>. The path to the service is a sequence of component instance names (from the formal specification of the solution component) separated by dots. Among these component instances, each subsequent component instance is embedded into the previous one, and the last one provides the service with the defined name.
Entity classes, interfaces, services, 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.
If selectors are not specified, the participants of a security event are considered to be all events and the kernel (except security events in which the kernel is not involved).
You can use combinations of selectors. Selectors can be separated by commas.
There are restrictions on the use of selectors. The interface and endpoint selectors cannot be used for security events of the execute type. The dst 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 or both of the endpoint and interface selectors. (The method, endpoint and interface selectors must be consistent, which means that the method must correspond to the service or interface, and the service must correspond to the interface.) 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.
Security audit profile
A security audit profile is defined by the construct audit <security audit profile name>. If a security audit profile is not defined, the global security audit profile is used.
Called rules of security models
Called rules of security models are defined by a list from the following type of constructs:
[security model object name.]<security model rule name> <parameter>
Input data for security model rules may be values returned by expressions of security models. The following construct is used to call a security model expression:
[security model object name.]<security model expression name> <parameter>
Parameters of interface methods can also be used as input data for methods of security models (rules and expressions). (For details about obtaining access to parameters of interface methods, see "Struct security model"). In addition, input data for methods of security models can also be the SID values of entities and the KasperskyOS kernel that are defined by the src_sid and dst_sid reserved words. The first reserved word refers to the SID of the entity (or kernel) that is the source of the IPC message. The second reserved word refers to the SID of the entity (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 or use operators for calls of some rules and expressions of security models. For details about the methods of security models, see "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 rules>
}
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
[security audit profile]
<called security model rules>
[}]
"<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, but you can define a separate security audit profile for a conditional section.
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 matching 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 "Security models").