The KasperskyOS kernel was internally developed by Kaspersky and is not based on any already existing project (Linux or otherwise).
KasperskyOS is a specialized operating system created from scratch by Kaspersky. Thanks to the principles embedded in its architecture, our OS can serve as the foundation for products that possess Cyber Immunity: built-in security against the majority of cyberattack types. This is critical for digital infrastructures that require a high level of security assurance.
KasperskyOS is the first-ever operating system that can be used to make IT products Cyber Immune. These products are nearly impossible to hack, and only a fraction of attack types launched against a Cyber Immune system can affect its critical functions. Solutions powered by KasperskyOS require no added protection: everything you need is already inside the system.
KasperskyOS provides flexibility in setting security policies: rules that the system will follow throughout its life cycle and that will prevent it from performing potentially dangerous operations.
The components of our OS are separated into isolated security domains and cannot affect one another. All of their interactions go through the microkernel, while Kaspersky Security System passes a security verdict on each. If an interaction fails to match defined policies, it is blocked even before the execution.
Thanks to this, when developing for KasperskyOS, you can use untrusted components that do not have Cyber Immunity. If one of them proves to be vulnerable, and attackers take advantage of this, the OS simply will not allow the component to perform operations that are not authorized by the security policy and that affect the functioning of the product.
The inherent security of KasperskyOS is embedded into its architecture and philosophy.
Thus, nothing can run or function unless explicitly allowed by system administrators and application developers. Security policies that describe each permitted action are defined as early as the design stage of an IT product based on KasperskyOS.
The KasperskyOS microkernel contains only a few hundred thousand lines of code, so the attack surface is minimal. The strict isolation of system components ensures operability in every situation: even if one of them fails, the OS will continue to perform its critical functions.
The KasperskyOS design conforms to the MILS and FLASK architectures, while adding Kaspersky’s own security technology.
The Cyber Immune approach at the heart of KasperskyOS prevents an attacker from affecting system operation even if some of the non-Cyber Immune components get hacked. Our microkernel and flexible security system technologies rule out unauthorized functions.
To make a product based on KasperskyOS Cyber Immune, you must strictly follow the special Kaspersky methodology.
Only IT systems that are intrinsically secure (secure by design) can be considered Cyber Immune. To summarize, creating Cyber Immune applications requires that the following be ensured from the moment development starts:
KasperskyOS does not collect or share data. All drivers, system services, applications, etc. are moved out of the kernel and isolated, and their behavior is strictly limited by security policies.
No component of the system can store or send data unless allowed by applicable policies.
They are positioned differently on the market. Linux is an all-purpose system for servers, desktops, mobile and other devices. It is easy to adapt to various applications. Nevertheless, it has so many system calls, and the modules within the kernel have such a complex link chain that we cannot be certain that the security tools built into the kernel, such as SELinux, are reliably checking all interactions. Every year we see new vulnerabilities or locations where some policies fail to be checked or applied to a specific system call. Most importantly, if someone hacks the monolithic kernel, they get maximum privileges. In contrast, many system services in KasperskyOS have been moved to the user space. Hacking these will not give the attacker any privileges at the OS kernel level.
Yes, it is. First, there is Kaspersky IoT Secure Gateway whose key element is secure gateways for the internet of things, indispensable devices for modern businesses that use IoT sensors and controllers. The commercial development of KISGs and the creation of end-to-end digital services based on them is carried out by Adaptive Production Technologies LLC (Aprotech), Kaspersky’s subsidiary.
Second, there is Kaspersky Thin Client, which includes software for thin clients: computer-like user terminals for connecting to corporate virtual desktop infrastructure.
Also available is Kaspersky Automotive Secure Gateway, specialized software that is designed for high-performance controllers of connected vehicles and combines the functions of a telematic control unit and a secure gateway.
First of all, on the internet of things and in process control, in industries with high cybersecurity standards. Examples include manufacturing, energy, government agencies, transport infrastructure.
Devices already running KasperskyOS include thin clients, a key part of Kaspersky Thin Client, and IoT gateways, which help build secure IoT networks and implement digital transformation in the manufacturing industry. Kaspersky Automotive Secure Gateway solution enables the creation of software for automotive electronic control units.
Our OS is evolving, and the range of supported devices is growing. For example, Kaspersky is investigating the possibility of adapting the OS for mobile platforms.
KasperskyOS is a specialized operating system. At the moment, it can only serve as the basis for designs intended for embedded IT systems with features required by specific clients.
That said, we are confident that Cyber Immunity is an important trend that will grow fast in the segment of personal digital devices, among others. Thanks to Cyber Immunity users won’t have to worry about the security of their devices, as these will be protected from most cyberattacks by default. This is a future worth striving for.
Together with our partners, we are releasing solutions based on a certain type of hardware. If there is ever a need for different hardware platforms, we will port our solutions to those platforms.
Of course, there are operating systems on the market that help to create functional products with a very high level of security. However, no modern operating system can give products Cyber Immunity: inherent protection against cyberattacks. That requires Kaspersky’s special methodology.
KasperskyOS is designed for devices on which an antivirus cannot be installed. Examples include secure gateways, electronic control units inside cars, thin clients.
That is why we designed our OS not to need any additional protection. Its architecture prevents attackers from affecting the functioning of the system even if a component has been compromised.
The native code of KasperskyOS is continually subjected to various kinds of testing, including fuzzing. Some of the more critical components undergo formal verification and validation of security models. Code is subjected to static and dynamic analysis. Penetration tests are regularly conducted. A Bug Bounty program is planned.
Cyber Immunity is foremost an approach aimed at creating a system that is inherently Secure by Design. These types of systems sharply differ from ordinary systems with implemented security because Cyber Immune systems present a minimal attack surface not through the use of applied security tools but instead through a correctly designed architecture. Cyber Immune systems are more resistant to hacking (compromise), and in case of a successful attack they substantially complicate its spread.
In our Cyber Immune approach, we primarily focus on preserving the integrity of the system. After all, if the components implementing access restriction are ever hacked, the security of the entire system will be at risk. Moreover, we all know that bug-free code still doesn’t exist in the wild.
For each specific KasperskyOS-based product, we formulate the appropriate security objectives and constraints. We determine which system security functions must always be performed regardless of whatever happens, while also adhering to a number of constraints.
The solution architect determines which “ilities” must be supported at the solution level, such as confidentiality, availability, and others. For each “ility”, there must be a system component that provides it and is already implemented in KasperskyOS (security pattern) or needs to be implemented.
The solution architecture is designed based on the appropriate security objectives and a clear understanding of the required ilities. The design process breaks down the system into components that are isolated by hardware resources and establishes the set of typified connections between those components. This stage focuses on integrity, especially regarding the specific sort of data that can be transmitted between specific components, the specific level of integrity of this data, the ways that malicious modification of this data can impact the operability of a specific component, and which components have a direct impact on system security functions.
As a result, we get an architecture that significantly hinders the spread of an attack within the system and minimizes the potential for hacking trusted components (those that impact security and implementation of the “ilities”).
The system architecture is reflected in the security policy for the security monitor running in the kernel. It tracks the integrity of architecture invariants. For example, it makes sure that messages are transmitted only via clearly defined communication channels, the structure of messages is not violated, and the fields of messages contain data that is valid according to the system architect.
As you can see, Cyber Immunity implies a certain culture and approach to developing and building an architecture and relies on a specific technological basis, which is the KasperskyOS operating system.
By default, security monitor is considered a trusted component. In other words, it is a component that must be trusted. If it is compromised, this would mean that its isolation mechanism is disrupted and the system can no longer be considered to be secure. Therefore, we apply every possible tool to ensure that the security monitor is operating correctly.
Firstly, the monitor code is written in a declarative language, which means that the monitor is generated and not written manually. This eliminates a certain number of errors.
Secondly, a generated security monitor can be thoroughly tested, especially given that certain models can be created from the intermediate representation language along with monitor code during the generation process. These models let us generate full test coverage where possible and apply model checking wherever full coverage is not possible.
As a result, we intend to use formal verification methods to prove that all of the security models being used are valid. We also have fuzzing. A monitor is therefore sufficiently reliable and will get even better.
Who better to explain the problems with fork than Microsoft employees? In a nutshell, fork is an insecure call that leads to uncontrolled inheritance of parent process resources. Additionally, the architecture and low-level API of our OS prevent any effective implementation of the system call without major modifications at the microkernel level.
We have many code execution controls. An attacker rewriting OS or firmware code is an illegal situation for ordinary operating systems and even more prohibited for ours. We have good protection against this thanks to the architectural approaches that we have already explained numerous times.
OCap can control system resources and resources in the user space. System resources include memory regions, interrupts, and input/output ports. Even tasks and threads in our operating system are represented by system resource objects, which means that they can be securely controlled.
User objects can also be represented by OCap. We have a special system call named KnHandleCreateUserObject that needs to be given user context such as a specific pointer in the address space of the service (resource provider), and this context is saved to a special kernel object.
After that, we can obtain a parent handle for this object and pass it on. When the object handle is transferred back to the resource provider, it recognizes the corresponding pointer and access rights mask that is being used to address it. It can independently verify this mask and grant or deny access to this user object. We can also write a KSS policy that can reach inside a message, check the SID behind the handle and the rights mask, and also grant or deny access. So yes, every object in the system can be made OCap-compatible.
We use a set of well-known security models, and some of these required us to prove that they operate correctly within our system. Vladimir Burenkov published a post on this topic. We may not be able to provide a 100% guarantee everywhere, but we are working on it. Specifically, we are introducing formal methods into the development process. For example, the K framework tool is partially used in the development of the security monitor. It allows a description of both the syntactic and semantic parts of the intermediate representation language. Knowledge of semantics allows us to carry out symbolic execution and prove certain statements about a policy.
There are two possible answers depending on the available hardware.
Hardware support of IOMMU automatically eliminates the isolation issue because our OS isolates process address spaces not only on the CPU side but also on the device side.
If the hardware has no IOMMU support, the solution must be built accordingly. We allocate the part of the driver that manages the device DMA controller as an isolated entity, scan it to make sure that it contains no vulnerabilities, and call it a trusted component. Then we write interaction policies to ensure that only authorized components can access the trusted component, and only in a specifically defined manner. In this case, no process in the system is allowed to directly program the DMA controller in an invalid manner. Instead, only a trusted driver is allowed to do so. This driver has been thoroughly scanned, and we have a certain degree of confidence that it is hard to hack.
The emergence of new kernel objects does not require changes to the security policies. Most security policies deal with the concepts of subjects and objects. Unless prohibited by a policy, a request from a process can result in the creation of a kernel object, such as an allocated memory region, input/output port, or DMA region.
Each of these objects will be assigned a unique identifier, and the security monitor will learn about each new object. The transfer of permissions to manage any such object is visible to the security monitor, and the policy may restrict the transfer of some of the permissions between certain subjects.
The policy does not normally need to be aware of specific objects, only about the interfaces and the class of the objects transmitted within specific messages. Whenever the characteristics of specific objects must be known, policy behavior can be parameterized with the help of security interfaces.
Security policies can limit entities to certain methods. In the case of USB, specific use cases need to be considered. As for RDP clients, we only support the token class. Although we do support USB flash drives, no code is executed at the level of our product (thin client). We pass on all USB-related functions to virtual desktops.
When designing products based on KasperskyOS, we consider only hardware that is trusted. When using our particular system, the potential harm that could be caused by Meltdown, Spectre and similar vulnerabilities is minimal.
Meltdown enables non-privileged code to read data from the privileged space of the kernel. KasperskyOS is a microkernel operating system, and its kernel does not contain much data that could be used by a cybercriminal. Most system services, including those related to encryption, are implemented in the user space.
Successful exploitation of Spectre relies on the existence of memory areas shared between processes. This is what enables the creation of a parasitic communication channel based on timing access to cache lines for indirect memory access. By default, KasperskyOS does not provide for the use of shared memory. The exclusive nature of such cases means that there is a very low likelihood that this hardware vulnerability could be maliciously exploited.
KasperskyOS is not a hard real-time system. We are moving toward soft real-time support. For instance, we have adapted a scheduler, and it has received an appropriate scheduling class. We have a lot of work ahead on refining synchronization primitives, dealing with priority inversion, rewriting certain algorithms and data structures, and achieving constancy of execution time.
This is a tricky question. The performance of microkernel systems has traditionally been evaluated based on IPC performance.
When designing our system, we prioritized security, message inspection, and prevention of TOCTOU attacks. This is why we need the kernel to store a secure copy of the message being transmitted for the security monitor. Naturally, this puts some constraints on IPC optimization.
For the time being, Linux and other popular operating systems certainly beat us when it comes to performance. Nevertheless, thanks to reasonable compromises, KasperskyOS provides an acceptable level of performance that allows us to create truly secure products.
Although it does make sense to pump messages through in packets rather than one by one, this is highly dependent on the specific case. Our typed interactions can be used for transmitting both individual words and unstructured byte arrays. Questions regarding what the interface will look like and how many messages it will have packed inside it will have to be answered by our architect. It is always a compromise between infrequent but long messages and lots of short messages.
If messages are unstructured and the solution architecture allows the use of shared memory, a fast data channel can be established by transferring the permission to use the MDL (Memory Descriptor List) object. In this case, we gain the ability to quickly exchange data between processes but we lose the ability to inspect messages sent through this channel.
Access to kernel services specifically does not result in serialization because IPC to a special kernel endpoint is viewed by the security monitor as regular IPC but is implemented differently in the kernel. In this case, no message transmission occurs. If two threads in different kernels request some service from the kernel at the same time, they will be served just as if they made some kind of system calls in a typical monolithic OS. Yes, threads may sleep on synchronization primitives inside the kernel. However, in most cases, these requests will be processed in parallel.
There is also no general serialization problem when sending a message to another user space service because the kernel uses fine-grained blocking and is ready to operate in multikernel systems. Even the security monitor dropped global blocking some time ago and is capable of inspecting several unrelated processes at the same time.
A typical driver manages a device via read/write operations through I/O ports (MMIO/PIO). It also interacts with a device via DMA. The device notifies the driver about completed requests and events by sending interrupts. This means that the kernel must provide the driver with a service that would allow it to obtain access to I/O ports, allocate DMA buffers, and handle interrupts. All of these capabilities are provided by the IO service of the kernel. A driver waits for interrupts by using something similar to an IPC Call: the interrupt handler thread from the driver makes a Call to the kernel and goes to sleep waiting for an interrupt. When the corresponding interrupt is received by the kernel, the kernel wakes the relevant thread that went to sleep after the Call, thereby allowing the interrupt to be handled. The thread then goes back to sleep. Access to kernel services is privileged and must be granted only to drivers and other critical components of the architecture. IPC-based implementation of access to kernel services enables use of all available technologies of the Kaspersky Security Module to deny/restrict program access to kernel services.
With us, driver porting is more of an exception than a common practice. More often, we try to write them ourselves. Nevertheless, we port some drivers and the very structure of our driver framework (execution inside the user space, isolation of drivers in separate processes, interactions between these via IPC) provides certain guarantees. If the driver turns out to have a vulnerability, it will not lead to compromise of the entire device or disruption of security objectives. This is ensured by driver isolation, policies that we program for each solution specifically, and the use of IOMMU.
Yes, there is a hypervisor. The microkernel contains a module named HV. HV implements the privileged portion of a hypervisor that directly accesses hardware and virtualization extensions like VMX. The hypervisor runs not only on Intel, but there is also fragmented ARMv8 support. The user space contains a virtual machine implementation that imitates typical hardware. We call this program VMAPP.
We are capable of loading various guest systems on Intel. This includes all current Windows versions (11 not tested yet), Linux and BSD distributions, and hobby systems like Haiku and ReactOS.
The virtual machine supports a set of standard devices installed in an x86-compatible computer: Q35 chipset, legacy controllers, E1000 network adapter, EHCI controller, and some virtio devices.
The standard usage scenario is hardware passthrough, so virtualization of a large set of devices is not required.
The hypervisor has been evolving fairly slowly because we have not yet found a need for it in any of our product solutions.
It all depends on the product. We do not provide dynamic updates by default. However, when it comes to products like the mobile platform, IoT gateway or thin client for which we are planning an application model, the update issue does come up. Some of the mechanisms that allow us to modify certain elements of policies on the fly are now available or under development. The security monitor is not modified in its entirety. Instead, only certain settings are modified.
When we port drivers, we copy over the code as is. If there is a huge change, we certainly make minor modifications.
Our first step is to copy the driver source code and commit it to a repository unchanged. Our second step is to make the modifications that are necessary for it to work under KasperskyOS. This approach guarantees that we can upgrade to newer driver versions virtually for free.
The interrupt handler in the driver freezes on a CallEx system call and waits for the kernel to wake it up with a notification about a new interrupt. After it wakes up, the handler performs the required processing operations and then sleeps on CallEx again.
Good question. This is highly specific to the devices and driver, but the architecture offers ways to resolve this. As you may recall, drivers in KasperskyOS are separate processes. In other operating systems, if you get a bad driver in a kernel context and it enters that state, you can only get around the glitch by rebooting the entire system. In KasperskyOS, you can stop and restart the driver, which can prevent the glitch. We plan to add a feature that monitors resource usage by entities. They will be restarted when a certain threshold is reached.
Drivers always interact with real hardware. Without hardware, you can only debug certain parts of them, such as transport libraries that implement client or server entities. You could write an emulator for debugging the non-hardware part, but you would need to build test stands to verify the driver’s performance in practice. This is what we are doing. We have a lab with testing and measurement instrumentation.
In a microkernel system, drivers of devices and low-level subsystems are moved to isolated processes of the user space. Drivers of peripherals and network adapters are implemented completely in the user space, which means that an error (vulnerability) in any driver cannot harm the OS kernel or other components. This is true for the network stack and USB. We develop the drivers for most of the required devices ourselves, and we port some from operating systems with suitable licenses.
There are no guides for porting drivers and applications from Linux to KasperskyOS. Drivers are ported based on ready-to-use drivers and the accepted driver model.
KasperskyOS Community Edition is a software development kit (SDK) designed to help you build a custom KasperskyOS image for a specific set of hardware platforms. The distribution kit includes the KasperskyOS kernel, solution development tools, numerous libraries (with usage examples), and documentation. The SDK is distributed as a DEB package for Debian GNU/Linux 10 “Buster” and can be downloaded for free at the provided link. The image does not include command-line interface tools such as a console or GUI. After installation, the SDK is deployed in the directory /opt/KasperskyOS-Community-Edition-<version>.
KasperskyOS Community Edition was designed to serve as a free tool for learning the principles of building a KasperskyOS-based solution, understanding the specifics of implementing security policies, and writing and debugging custom pilot projects. The license will also let you modify the components that are provided as source code. KasperskyOS Community Edition currently lets you develop software for embedded systems managed over an Ethernet network (via web interface or other protocols).
The KasperskyOS Community Edition (CE) version is not intended for commercial use. This distribution package lets you develop a fully functional product and demonstrate it to potential customers. To directly distribute commercial products based on KasperskyOS, you must purchase a commercial license.
The terms and conditions of a commercial license depend on many parameters, including the number of devices that will be produced and the specific business model (for example, fixed payments, royalties, or shared revenue). The cost may also be affected by any work performed by Kaspersky experts if necessary for a specific project. This potential work may include support for the specific hardware platform, other technical support, and updates.
If you already have tentative details or project parameters, please share them with us so that our colleagues can propose a suitable business model for you and calculate the appropriate cost.
Even if you have not yet decided on any specific parameters, Kaspersky is committed to supporting successful KasperskyOS-based products and will never set any cost-prohibitive terms for licenses.
KasperskyOS Community Edition is not intended for commercial use. In other words, it cannot be resold, even as a part of other software/hardware systems. A separate license would be required for such purposes. To find out the conditions for such use, please contact os@kaspersky.com
KasperskyOS Community Edition is not intended to directly run applications that were written for other operating systems. Applications must be properly ported before they can be run.
KasperskyOS Community Edition currently works with Raspberry Pi 4B and with AArch64-based virtual machines in QEMU. SDKs can be prepared for x86 and NXP i.MX if requested. KasperskyOS Community Edition could also potentially work on other platforms with a memory management unit (MMU). If you have any queries regarding other platforms, please send them to os@kaspersky.com.
Ethernet network stack, SD card operations, and GPIO in ordinary I/O mode.
There are no special hardware requirements as compared to Linux, for example. MMU is mandatory, and we prefer platforms with IOMMU because this technology can also extend isolation to DMA operations.
Together with our technological partners, we are currently releasing solutions for certain hardware (x86_64 and ARMv6/7/8). If there is ever a need for different hardware platforms, we will port our solutions to those platforms.
It is not an easy task to support new hardware, but we manage to do so with our own resources. For example, we write drivers and BSPs, and sometimes we port them from other open-source operating systems. However, sometimes this work is carried out by our partners.
PCRE (regular expressions), CivetWeb, Boost, mbedTLS, and Mosquitto.
These libraries are currently supported entirely by the KasperskyOS development team. At some point, we would like to hand off support for these libraries to original developers or to the open source community.
The KasperskyOS Community Edition-compatible libraries nginx fork, PHP fork, Samba fork, NodeJS fork and Nmap fork are already available on their respective websites. Porting of other libraries can be found at https://github.com/KasperskyLab.
You can use static and dynamic libraries. To utilize libraries when building a solution, you need to specify the relevant library in the dependencies of the corresponding artifact. Dynamic libraries are provided in the SDK, and can also be created by a KasperskyOS-based solution developer. Normal operation of third-party dynamic libraries cannot be guaranteed.
This is due to a problem encountered by a local process attempting to access the X Window System. Possible solutions:
If X11 Server is installed, run “xhost local:” (grant access to all processes).
If X11 Server is not installed, you must either install it or add the -nographic flag when running QEMU: in the einit/CMakeLists.txt file, add the string QEMU_FLAGS “${QEMU_FLAGS} -nographic -monitor none” to the build_kos_qemu_image target before ${ENTITIES}
You must perform the procedure for “Running an example on a Raspberry Pi 4B” directly after the procedure for “Preparing a bootable SD card.”
GPIO examples will not run correctly in QEMU.
Rust is a promising programming language. It resolves a number of problems with C and C++ and does so on the cheap. Like C++, Rust follows the path of zero-cost abstractions.
We are eying Rust primarily as a language for developing user space code. The product development team is preparing to add Rust support to KasperskyOS to support the new version of the Suricata engine.
We have ported the Lua interpreter and Java virtual machine to KasperskyOS. A WebKit-based web browser that supports JavaScript execution is also available for our system.
Third-party applications that can be installed in some builds of KasperskyOS are run in a containerized environment. For instance, an application receives its own isolated storage and virtual file system, and access to the functions provided by the basic OS is provided through capabilities. This type of application cannot reach the data of other applications and directly contacts drivers and other system services.
KasperskyOS is based on a multi-service architecture: components responsible for specific functions of the system are run in the user space, while interaction with these components occurs via typed interfaces. Components can create objects and provide access to them via remote calls. All resources in the system are represented by objects such as kernel resources (threads, memory regions, ports, interrupts, channels) as well as user resources (devices, files). In other words, it’s closer to an object-oriented paradigm because the system can be conditionally represented as a set of objects that exchange messages.
The file system in KasperskyOS is an alienated entity, so you can represent a KasperskyOS build variant that doesn’t have any file system at all. You can also create a system variant that does not have a POSIX API. For these reasons, the “everything is a file” approaches from Plan 9 and more traditional Unix-like systems are inapplicable here.
A specialized in-house file system was not developed for KasperskyOS. Usually we port the open implementations of file systems from operating systems that have a suitable license, then we refine those implementations to meet our requirements.
The collection of KasperskyOS components already includes popular libraries and programs that have been ported. The main vector of product development entails the creation of proprietary solutions based on KasperskyOS. However, KasperskyOS Community Edition is a good example in this regard because developers of this system build actually port popular programs and technologies from GNU/Linux to attract developers who are familiar with these technologies.
KasperskyOS uses a simple graphical compositor based on the Wayland protocol. We have laid the groundwork for a graphical stack (based on DRI). However, we currently have no plans to develop a full-fledged desktop solution.
The kernel, libkos base library, driver framework, input framework, and most of the drivers developed by the KasperskyOS team contain no borrowed code, with only a few exceptions. For instance, the kernel configuration system and parts of the RTL (snprintf and rb tree) contain some borrowed code. The full list of these exceptions can be viewed in the legal.lst file. Borrowed code can also be found among product teams and teams that work on system components, such as VFS and network stacks. This is mostly code under BSD and MIT-like licenses.
Yes, we have found and fixed errors in open-source components. Our test coverage goals are 100% for features and 75% for branches. We have not reached these goals yet, but we are getting there.
The licenses are inherited.
Yes, it can. In particular, an application with a data diode guarantee (KISG-100) can consist of two types of entities: input and output protocol converter. These can be supplied by two different developers or by the same one. We have realized that you cannot concentrate all protocol processing logic within one entity for a data diode guarantee. We have ended up with a base application (protocol converter) that consists of two processes.
An ordinary TLS level. The same algorithms that are used in HTTPS, for example.
We only connect to servers that we trust. We do not expect attacks from an RDP server. If we did, we would have to conduct deeper and more extensive fuzzing and pentesting for FreeRDP.
TLS terminator was originally a small entity with one function. That kind of entity is easier to scan and has a small attack surface, and we consider it to be trusted. The fact that we had to create a separate TLS Terminator instance customized for a specific protocol does not prevent it from having the same properties. On the other hand, embedding a TLS implementation in the form of a library significantly increases the attack surface and violates the principles of building a Cyber Immune solution.
There are two options.
The more complicated option: the developer must use an IPC call to the server component of the called library.
The simpler option: the library must be provided together with a client component that is statically linked to the developer’s solution and hides IPC from the developer.
By default, messages can be printed to terminal via stderr. You must use the VFS program to print to stdout.
Currently, KasperskyOS solutions can be developed in C and C++ using GCC cross compilers.
The currently recommended development environment is VSCode with C/C++ syntax highlighting.
Operating system for Internet-connected embedded systems with specific cybersecurity requirements
