A common problem for those getting acquainted with KasperskyOS is understanding process classes, instances and executable files. Here we talk about this in more detail.
In my opinion, the cause of the “confusion” in students’ heads was a notational simplification introduced in the init.yaml.in file related to the process instance definition. The relevant documentation can be found here. Let’s take another look at it.
Each section in the init.yaml.in file that starts with a dash defines a separate process to be started. The only mandatory parameter is name, which defines a reference to the class from which the individual instance (process) will be created at startup.
It is the class name that will be referenced by the security policy described in the PSL files. Note that more than one instance of the class can be launched – in this case the same policy will be applied to each of them.
A process class can be quite complex in terms of source file structure, consisting of more than one file and/or procedure, containing linked libraries (see the example from the training course regarding the VFS client library).
The second (optional) parameter is task, which specifies the name of this particular instance. If no parameter is specified, the full class name will be used. Obviously, the instance name must be unique within a single project. You can therefore omit this parameter unless you need to start more than one instance of the class.
When initializing a connection, the target is the task, because the client must connect to a specific server.
If necessary, processes that are not exactly identical (in operation) can be started from one class. This can be done using one of two mechanisms – passing arguments directly or setting environment variables. You can read more about the first mechanism here, with examples provided here. Or you can view net_with_separate_vfs from the SDK.
It should be noted that from the point of view of Kaspersky OS architecture, the security domain boundaries coincide with the process instance. This means that the system controls only the external communication of the process, but not its internal communication. This feature should be exploited to reduce the load on the security system, since the resources required for its operation represent a significant overhead in comparison with traditional systems.
The third parameter (also optional) is path, which defines the executable file name. By default, it is the part of the class name from the last dot to the end.
This parameter does not hold much meaning, but it is the contents of this parameter (set explicitly or not) that can be seen in the console during the process of loading the operating system image.
If necessary, it is permissible to run the same executable file several times to create process instances, which can also function differently using various mechanisms. Using this mechanism (as opposed to explicitly defining a separate task in init.yaml) is not recommended due to the inconvenience of visual control, but in the case of dynamic startup of processes (not in init.yaml, but using EntityInit() ) it may be the only option.
A common problem for those getting acquainted with KasperskyOS is understanding process classes, instances and executable files. Here we talk about this in more detail.
In my opinion, the cause of the “confusion” in students’ heads was a notational simplification introduced in the init.yaml.in file related to the process instance definition. The relevant documentation can be found here. Let’s take another look at it.
Each section in the init.yaml.in file that starts with a dash defines a separate process to be started. The only mandatory parameter is name, which defines a reference to the class from which the individual instance (process) will be created at startup.
It is the class name that will be referenced by the security policy described in the PSL files. Note that more than one instance of the class can be launched – in this case the same policy will be applied to each of them.
A process class can be quite complex in terms of source file structure, consisting of more than one file and/or procedure, containing linked libraries (see the example from the training course regarding the VFS client library).
The second (optional) parameter is task, which specifies the name of this particular instance. If no parameter is specified, the full class name will be used. Obviously, the instance name must be unique within a single project. You can therefore omit this parameter unless you need to start more than one instance of the class.
When initializing a connection, the target is the task, because the client must connect to a specific server.
If necessary, processes that are not exactly identical (in operation) can be started from one class. This can be done using one of two mechanisms – passing arguments directly or setting environment variables. You can read more about the first mechanism here, with examples provided here. Or you can view net_with_separate_vfs from the SDK.
It should be noted that from the point of view of Kaspersky OS architecture, the security domain boundaries coincide with the process instance. This means that the system controls only the external communication of the process, but not its internal communication. This feature should be exploited to reduce the load on the security system, since the resources required for its operation represent a significant overhead in comparison with traditional systems.
The third parameter (also optional) is path, which defines the executable file name. By default, it is the part of the class name from the last dot to the end.
This parameter does not hold much meaning, but it is the contents of this parameter (set explicitly or not) that can be seen in the console during the process of loading the operating system image.
If necessary, it is permissible to run the same executable file several times to create process instances, which can also function differently using various mechanisms. Using this mechanism (as opposed to explicitly defining a separate task in init.yaml) is not recommended due to the inconvenience of visual control, but in the case of dynamic startup of processes (not in init.yaml, but using EntityInit() ) it may be the only option.
