Using the KasperskyOS operating system as an illustration
There are generally accepted principles that inventors of secure operating systems strive to adhere to, but the approaches to enforcing these principles can be entirely different. In particular, a secure operating system can be built on the basis of an operating system in progress by perfecting some characteristics that are the cause (or consequence) of the insecure feat of this operating system, or it can be developed from scratch.
The first approach has the undoubted advantage of lower development costs and a large amount of OS-compatible software. Let us consider this approach in the context of critical infrastructure systems for which two factors are important:
The ability to implement specific security requirements, which may consist not only in preserving some general properties of information (such as confidentiality) but also, for example, in tracking certain commands and data streams, not affecting the execution of processes in the system, etc.
Warranties provided that the system will operate in a secure manner and will not be compromised.
Often, to build a secure system based on a common OS, additional access control mechanisms (for example, based on the mandatory model), strong authentication, data encryption, security event auditing, and application execution control are introduced into this system. As a rule, these are typical protection measures – and the specific needs of the system are met at the application level. Thus, special (and often general) security measures rely on the implementation of many components, each of which can be compromised. Examples of such OS: SELinux, RSBAC, AppArmor, TrustedBSD, MSVS, Astra Linux and others.
To improve security, tools can also be introduced into the system that makes it difficult to exploit some vulnerabilities, including those inherent in the system due to its inherently insecure design. Examples: Grsecurity, AppArmor, Hardened Gentoo, Atlix, YANUKS, Astra Linux, etc.
Just a few years ago, an approach to providing a “security” guarantee was widespread, based on checking program code for errors and vulnerabilities, checking software integrity by comparing checksums. This approach was used in Openwall Linux and some Russian operating systems.
While the measures described generally improve the performance of general-purpose systems, they cannot meet the special needs of critical infrastructure systems and ensure security with a high degree of certainty.
However, the OS, originally designed as secure, also cannot always give guarantees regarding the implementation of a particular security policy. Objective reasons for this lie in the difficulty of formulating clear security objectives for such a relatively universal IT product as an operating system, and in the large number and variety of threats from the environment.
If the operating system is intended for targeted use on more or less fixed hardware, and under its control, within the described operating scenarios, quite specific software is executed, then security objectives can be clearly defined and a threat model built. Based on this model, in order to achieve security goals, a specific list of security requirements and assurance requirements is formulated. Satisfying these requirements is sufficient to guarantee the safe behavior of the system. An example of such operating systems is specialized embedded solutions from LynuxWorks, Wind River, Green Hills.
It is more difficult for a general-purpose operating system to achieve the same guarantees because of the broader definition of security objectives (so that the system can support more secure execution scenarios). Usually, it is required to support a whole class of policies for a certain type of access control (discretionary, mandatory, role-based), familiar authentication mechanisms, and other security tools that do not require special knowledge to manage. This requires the implementation of relatively universal security mechanisms. Sometimes, provided the operating system is executed on a fixed hardware platform (as a rule, from the same manufacturer), it can be guaranteed with a sufficient degree of certainty that the requirements of a certain standard, or protection profile, to these mechanisms are met. Examples: Oracle Solaris with Trusted Extensions, XTS-400, OpenVMS, AS / 400.
Finally, for a general-purpose operating system running on an arbitrary hardware platform, it is even more difficult to achieve high-security guarantees because of the prohibitive threat model.
This problem can be solved by an approach to building a system on a modular basis based on trusted small components that implement standardized interfaces. The architecture of a secure system built in this way allows portability to various hardware platforms and verification of a relatively small amount of program code, while saving top-level modules for reuse. This potentially allows security guarantees to be provided for every OS application.
The first step towards modularizing the operating system is to use a microkernel architecture. The microkernel provides the only way to interact and exchange data in the system, thereby providing complete access control.
However, within the framework of microkernel access control, it is impossible to provide system properties related to the support of specific security policies. KasperskyOS implements the principle of separate access decisions based on a specified policy and control of this access at the microkernel level. Access decisions based on the calculation of security policies are made by a specialized component – the security server. The most famous architecture based on this principle is the Flask architecture.
It should be noted that a number of general-purpose OS security enhancements (SELinux, SEBSD) are built on the basis of the Flask architecture, but these systems are built on the basis of a large monolithic kernel. Indeed, Flask does not require a microkernel, but it works best with it.
KasperskyOS does not reproduce the Flask architecture exactly but develops its ideas for better security and flexibility in target use. The original Flask architecture describes the interfaces and requirements of two main components involved in applying security policies to communications — a security server that computes security verdicts, and an object manager that accesses those verdicts. During the development of KasperskyOS, great attention is paid to maintaining trust not only in the mechanisms for calculating and applying verdicts but also in the configuration according to which this calculation occurs. Basic security policies are combined using a configuration language into more complex rules. These rules are then compiled into an intermediate component code between the security server and the microkernel,
Thus, the general settings of security policies (system-wide configuration at the security server level) and the rules for applying policies to each action of each entity in the system (via the configuration for calculating verdicts) can be configured in KasperskyOS.
The trusted code obtained during the compilation of configurations links the application software and the security model in the system, indicating which actions of the programs should be regulated by which security policies. At the same time, this code does not have any other information about actions and policies, except for links to them.
Of course, a microkernel system based on Flask-like architecture is not a unique idea of the KasperskyOS developers. There is an experience of successful development of microkernels (seL4, PikeOS, Phoenix / Febos), including those with formally verified security properties. On the basis of these developments, an OS can be implemented that allows for guaranteed separation of security domains (to provide “security through isolation”). This architecture is known as MILS ( Multiple Independent Domains of Safety / Security ).
However, in this case, we are talking about the development of not only a microkernel but also a full-fledged OS, which will allow not only to separate security domains and isolate incompatible information processing environments but also to control the implementation of security policies within these domains. At the same time, the implementation of the microkernel, the infrastructure of the operating system based on it, and security policies are carried out by one manufacturer. The use of third-party developments, even if they are of good quality, always imposes limitations.
The most significant drawback of operating systems developed from scratch is the lack of support for existing software. This disadvantage can be partially offset by maintaining compatibility with common programming interfaces, the most famous of which is POSIX.
Also, this disadvantage is successfully overcome with the use of virtualization. A secure operating system in which a general-purpose OS virtualization hypervisor can run will be able to run software for that OS. KasperskyOS together with Kaspersky Secure Hypervisor provides just such an opportunity. Under certain conditions, an unsafe general-purpose operating system is capable of inheriting the security properties of the underlying operating system.
Thus, the secure operating system KasperskyOS is not a revision or improvement of existing operating systems, and this does not harm the range of its applications. The system can be used as a basis for developing solutions with specific security requirements. The prerequisites for ensuring flexible and efficient control over application execution are laid down in the architecture of the KasperskyOS operating system. The development is carried out in accordance with the best principles for the implementation of safety products and is accompanied by scientific and practical research.
Feel free to leave us your comment. It helps us understand what you like or don’t like.