A security configuration consists of the following sections:
Definition of the execute interface.
A security configuration begins with the following statement:
execute = execute.execute;
This statement means that the execute interface declared in the execute package (execute.idl) is used for starting entities. This interface contains a single start variant: the main method without parameters. The execute.execute interface is used in all examples in this Guide.
Connecting family files
To use family policies, you must connect the CFG file of this family.
Family files are located in the folder /opt/KasperskyOS-StarterKit-<version>/sysroot-x86_64-pc-kos/include/kss/server/:
/* Connect basic security policies: grant and deny. */
#include <kss/server/base.cfg>
/* Connect "flow" family policies. */
#include <kss/server/flow.cfg>
Creation of family instances
To refer to family policies, you need to first create an instance of this family by using the use family statement.
When creating a family instance, you need to indicate its JSON configuration. For example, a flow family instance configuration (implementation of a finite-state machine) describes possible states and transitions between them:
/* Create instance of "flow" family. New instance name: request_state. */
use family request_state = flow {
states : [ping_next, pong_next], /* multiple states */
initial : ping_next, /* initial state */
transitions : { /* table of permissible transitions between states */
ping_next : [pong_next],
pong_next : [ping_next]
}
};
For certain families, the configuration is always indicated in a separate file:
/* The configuration of the "request_state" instance of the "era" family is contained in the ping.era file.*/
use family request_state = era "ping.era";
Each family instance is an implementation of a security model with an internal state of its own. This state can be global or linked to a specific security domain. Policies can change this state and define the rights to access a resource based on the current state. You can create instances of the same family with different configurations.
Linking events to policies
To bind an event to one or more policies, specify the following:
request, response, security or execute.For example, the following statement is used to allow the startup of all entities:
/* Event type: execute (start entities).
No attributes.
Bound policy: grant. This policy always returns an "allow" decision. */
execute { grant; }
Another example: configuration of a call of the Ping method of the server entity. The method call will be allowed or denied depending on the state of the request_state instance created above:
/* Event type: request.
Attributes: recipient-entity: server, component instance and interface implementation: ping_comp.ping_impl, called method: Ping.
Bound policy: request_state.allow [ping_next]. This policy returns an "allow" decision only if the "request_state" instance has a "ping_next" state. */
request dst=server, endpoint=ping_comp.ping_impl, method=Ping {
request_state.allow [ping_next];
}
For more details, refer to "Linking events to policies".
Page top