Sivelkiria’s security system is based on the principle that every module only has the permissions it needs to complete its task. However, the very concept of a permission is quite narrow and involves executing specific operations on specific data types. This significantly limits the capabilities of malware.
For example, the module responsible for sorting and filtering the list of messenger dialogues obviously has access to the timestamp of the last message in each dialogue as well as to the groups in the contact list. At the same time, even with a link to the dialogue, the module will not be able to extract any random information from it (e.g. message history), since its task does not require it. The module that renders the dialog thumbnail (with the beginning of the last message displayed on it), has access to the last message, but not to the previous one. Even if it had such information, it wouldn’t be able to propagate it any further because it does not have permissions to save it to a file or to transfer it over the network (although the messenger as a whole certainly has access to both the file system and the network). It will not be able to access a module that could do this for it either, since it does not have permission to perform this operation. Thus, there are significantly fewer opportunities for malware to be introduced than in the classic application-based scheme.
This limitation may seem rather strict. For example, it may seem that message filtering module not having information on message source interferes with the ability to perform such filtering at all. However, this is not the case; limiting simple types as much as possible creates the need to develop more complicated types based on simple ones. Instead of an abstract ‘Message Filter’ interface, a more specific ‘Channel-based Message Filter’ interface should be used. The latter implements the former by definition and has the necessary permissions the Message Filter interface lacks. Such a specification makes it possible to use any interface more effectively from other contexts. For example, in a GUI that shows the list of available messaging service connections, an abstract ‘Select Message Filter’ button would look absurd, while the context command ‘Show all Messages From This Source’ that uses the respective filter type would be helpful.
Only a few types of modules have permission to create executable modules. They are assigned to the module types responsible for deploying programs obtained from repositories and to compilers that need to ensure that the programs they build can be debugged. Once installed, components cannot be modified (simply because they are not files on a disk), although they can be replaced. The complete history of creating and replacing executable modules is logged.
For each module running on a Sivelkiria-controlled computer, a hash sum is being calculated which makes it possible to identify it while the data is being transferred to the main repository. If a certain module is distributed that bypasses official channels (repositories), and the number of installations exceeds the number necessary for debugging (e.g. ten machines of more), the module is blocked regardless of the way it is being distributed and information about its origin is collected (with the consent of users). This makes it possible to stop viruses from spreading if a security breach is used to distribute them. Of course, there is a way to perform User Acceptance Testing on a large audience (i.e. distributing test versions of modules via the repositories).
In this regard, network interaction between Sivelkiria instances is less secure because the machine that exposes the objects has no way to confirm that the caller has passed all access rights checks. However, all the usual barriers, such as user account control, network list control, encryption, certificates, etc. are still in place. Sivelkiria can also disable access to specific data types or types of operations. The fact that ‘Network Permission’ is just another interface of the operating system, allows flexible configuration. For example, installing modules when connecting from another computer is likely to be disabled by default.
If a vulnerability is exposed in the existing software, the OS support team should be made aware of this by the users, developers or analysts. Then this information can be distributed to the machines that have compromised versions using the usual software distribution channels. The obvious exception is the situation when there is no immediate solution and publishing information about the vulnerability would do more harm than good, increasing potential damage. The end machine can then propose a solution to the user or, if allowed by security policies, apply it automatically. The solution may require downgrading the module or replacing it with another one. In the case of an isolated corporate environment, such decisions can be made by the system administrator.
Strict rules for the functions performed by each module and the inability of the module to take on other functions allows the replacement of the compromised module with another one without impacting the program that uses it, since the new module performs the same functions.
Cases where the vulnerability appears outside the context of a specific module can be tracked using the same principles (for example, when two specific modules interact).
Finally, security issues arising from interface definitions (for example, overly broad access rights granted to a method) will be addressed at the appropriate level. The OS support team would possess information about the modules that are already using the vulnerable version of the interface and could make exceptions to prevent disruptions of operations in the existing software.