Long Term R&D: Secure OS (proposal)

1. Summary

This is a motion proposal for the long-term R&D of the DFINITY Foundation, as part of the follow-up to this post: Motion Proposals on Long Term R&D Plans (Please read this post for context).

This project’s objective

This project aims to complement the security of the IC by focusing on the IC providing virtual machines and the associated host operating system. To strengthen the security it is planned to compartmentalize the IC software and holistically secure the system. As a part of this process, a clearly defined and fine-grained security policy has to be devised to detect and prevent security breaches. In case the former cannot be achieved, for example, due to a zero-day vulnerability, the aim is to limit the impact and launch countermeasures to prevent further damage.

2. Discussion lead

Helge Bahmann

3. How this R&D proposal is different from previous types

Previous motion proposals have revolved around specific features and tended to have clear, finite goals that are delivered and completed. They tended to be measured in days, weeks, or months.

These motion proposals are different and are defining the long-term plan that the foundation will use, e.g., for hiring and organizational build-out. They have the following traits and patterns:

  1. Their scope is years, not weeks or months as in previous NNS motions
  2. They have a broad direction but are active areas of R&D so they do not have an obvious line of execution.
  3. They involve deep research in cryptography, networking, distributed systems, language, virtual machines, operating systems.
  4. They are meant to match the strengths of where the DFINITY foundation’s expertise is best suited.
  5. Work on these proposals will not start immediately.
  6. There will be many follow-up discussions and proposals on each topic when work is underway and smaller milestones and tasks get defined.

An example may be the R&D for “Scalability” where there will be a team investigating and improving the scalability of the IC at various stages. Different bottlenecks will surface and different goals will be met.

3. How this R&D proposal is similar to what we have seen

We want to double down on the behaviors we think have worked well. These include:

  1. Publicly identifying owners of subject areas to engage and discuss their thinking with the community
  2. Providing periodic updates to the community as things evolve, milestones reached, proposals are needed, etc…
  3. Presenting more and more R&D thinking early and openly.

This has worked well for the last 6 months so we want to repeat this pattern.

4. Next Steps

Developer forum intro posted
1-pager from the discussion lead posted
NNS Motion proposal submitted

5. What we are asking the community

  • Ask questions
  • Read 1-pager
  • Give feedback
  • Vote on the motion proposal

Frankly, we do not expect many nitty-gritty details because these are meant to address projects that go on for long time horizons.

The DFINITY foundation’s only goal is to improve the adoption of the IC so we want to sanity-check the projects we see necessary for growing the IC by having you (the ICP community) tell us what you all think of these active R&D threads we have.

6. What this means for the existing Roadmap or Projects

In terms of the current roadmap and proposals executed, those are still being worked on and have priority.

An intellectually honest way to look at this long-term R&D project is to see them as the upstream or “primordial soup” from which more baked projects emerge from. With this lens, these proposals are akin to asking, “what kind of specialties or strengths do we want to make sure DFINITY foundation has built up?”

Most (if not all) projects that the DFINITY foundation has executed or is executing are borne from long-running R&D threads. Even when community feedback tells the foundation, “we need X” or “Y does not work”, it is typically the team with the most relevant R&D area that picks up the short-term feature or project.

1 Like

Please note:

Some folks gave asked if they should vote to “reject” any of the Long Term R&D projects as a way to signal prioritization. The answer is simple: “No, please, ACCEPT” :wink:

These long-term R&D projects are the DFINITY’s foundation’s thesis at R&D threads it should have across years (3 years is the number we sometimes use internally). We are asking the community to ACCEPT (pending 1-pager and more community feedback of course). Prioritization can come at a separate step.

Hello everyone, I am Helge Bahmann working as senior researcher for OS security at dfinity. I have been working Linux and system security for a long time and want to ensure that IC nodes are protected as best as they could against attacks. Besides operating systems my interests are compilers and certified programming. Before dfinity I worked at secunet and Google.

3 Likes

Summary

The Internet Computer (IC) is a general platform to host applications processing all kinds of data and digital assets. For its architecture, protocol and growth, decentralisation has so far been a key concern. The latter includes being resilient against various forms of network-centric and distributed attacks. The following “Secure Operating System” motion proposal aims to complement the security of the IC by focusing on the IC providing virtual machines and the associated host operating system.

To strengthen the security it is planned to compartmentalize the IC software and holistically secure the system. As a part of this process, a clearly defined and fine-grained security policy has to be devised to detect and prevent security breaches and in case the former cannot be achieved, for example due to a zero-day vulnerability, to limit the impact of a successful attack to a minimum. Furthermore, the proposal targets to implement measures for an early detection of such attacks and a rapid impact analysis to establish countermeasures such as updating the system.

Objective

The two main objectives of this proposal are to reduce the attack surface and mitigate the effects of a successful attack at the IC node level. This will be achieved by compartmentalization of the IC software and establishing a fine-grained security policy thereby limiting and controlling access and execution privileges of all system actors. Based on the former a layered security architecture to improve the resilience of the IC at the virtual machine and the host operating system level will be established. In case of successful attacks support for an early detection needs to be provided to facilitate an instant root cause and impact analysis enabling to deploy countermeasures.

Background

The system architecture of an IC node has been designed with a reduced attack surface in mind and represents a controlled and clearly structured environment. The IC protocol and all attached software has been implemented in Rust to offer a secure and very stable system. Nevertheless, as the IC matures the implemented security measures need to be amplified.

This requires further decomposition of the system in isolatable components with clearly defined interfaces. The achieved compartmentalization builds the basis of a mandatory access control and a fine-grained security policy. Together this forms the basis for a layered security or defense in depth where even in case of a successful attack the damage will be limited and can be better assessed. Furthermore an attacker can be slowed down and the likelihood of detecting and implementing counteractions rises.

Why this is important

The growth of the IC and new features like canisters holding ICP and the integration with other digital currencies such as Ethereum will make the IC an attractive high value target for attacks. Despite the strong commitment of making the IC a secure and resilient infrastructure due to the complexity of the system, vulnerabilities might surface. To address them in the first place and contain their impact if necessary, this motion proposal sets out to strengthen the security at the node level and establish mechanisms for a fast incidence detection and response.

Topics under this project

While compartmentalization of the IC system software and the establishment of a fine-grained mandatory access control is the initial overarching goal, a set of measures can be identified that will be applied at the virtual machine level and if applicable at the host operating system stage as well.

In a first step, all software including the operating system and otherwise static data will be made immutable via a read-only and integrity protected file system. This prevents unwanted modification to binaries, hinders the persistence of malicious code. Boot and upgrade integrity verification stops a successful intruder from installation of backdoored system images.

Subsequently, a fine-grained mandatory access control policy will be designed, extensively tested and finally deployed. This policy will not only restrict the software during normal operation but also restrict and control the access of administrative personnel in case of maintenance and incident response. Security policies will also ensure that operator access to nodes is fully auditable. This allows independent verification that operator intervention was performed in accordance with procedures.

While the “Sandboxing mechanism for canister WASM execution” motion proposal already divides the IC core software by separating the execution of canister code from the main protocol logic, further compartmentalization steps will be explored as part of this proposal. Prime candidates to extend the already started process-based separation are functionalities related to code generation, components facing the public network and cryptographic operations. Initially, a detailed security analysis as well as performance impact study will be performed, thereby rating the individual compartmentalization scenarios. The candidates with the best security and acceptable performance trade-off will be implemented, tested, and deployed.

Beside these steps, to increase the protection of the IC, a number of measures to respond to incidents need to be established. In particular the proposal will devise mechanisms providing the basis for a controlled and privacy-preserving monitoring of IC nodes. It is important to offer detailed monitoring data to facilitate an early detection of security-related issues, while preventing the exposure of sensitive information as part of the monitoring data. In case of successful attacks a root cause and impact analysis needs to be performed. It is planned to develop tool support for guiding these measures.

Key milestones

This motion proposal targets a long-term perspective and as such is planned for three years. Parts of it will be detailed and refined as the work progresses. At this stage six milestones are planned:

  • M1: Read-only, integrity protected root file system
  • M2: Initial security policy for the IC virtual machines
  • M2: Initial security policy for the IC host operating system
  • M3: Methodology for a semi-automated validation of performed partitioning of the IC core software
  • M4: Extended partitioning of the IC core software
  • M5: Methodology for a semi-automated approach enabling to adapt and validate the security policies of the IC virtual machine and host operating system
  • M6: Methodology and tools for extensive but privacy-preserving logging, incident root cause analysis as well as impact assessment of successful attacks

Discussion leads

As members of the DFINITY research team Helge Bahmann and Rüdiger Kapitza will drive the proposal and are available for discussion.

Why the DFINITY Foundation should make this a long-running R&D project

In general securing systems is an ongoing topic as new forms of attacks are discovered and large distributed systems are constantly being attacked. The proposed set of measures touches almost all parts of the system and the envisioned changes have to be performed with great care. For the next up to three years the main research and engineering work will be carried out but the performed compartmentalization and the designed security policies have to be constantly revised as the system evolves. Ensuring security as such is a long-term commitment.

Skills and Expertise necessary to accomplish this

The initial driver of this proposal will be the DFINITY Foundation’s node team in close interaction with the execution and the security team. However, as security is a cross-cutting concern, all teams that design and implement functionality executed on the IC will at some point be involved in this proposal.

As compartmentalization and policies are established this requires extensive tests to ensure that the policies don’t hinder required functionality but also are not too relaxed.

Expertise-wise the proposal requires researchers and engineers with strong background in operating and systems security as well as for the partitioning of the IC core software a deep understanding of software architecture and system design. As indicated by the outlined research questions for the envisioned semi-automated policy adaptation researchers from the fields of formal methods, testing and software engineering are key.

Open Research questions

While the starting point of this proposal is to decompose the software on an IC node in multiple compartments and establish a fine-grained security policy for mandatory access control, the research questions root in the rapid evolution of the IC software and the Rust-based IC core software. In particular the aim is to answer the following questions:

  • How can a fine-grained security policy be safely adapted in a rapidly evolving software ecosystem? The aim is to establish a semi-automated approach for validation of adaptation steps.
  • How to enable an at least semi-automated validation of a partitioning of the IC core code?
  • How to ensure an extensive but privacy-preserving logging that can be validated?
  • How to not only detect a security breach but also perform an automated impact analysis that can be used to establish counter measures?

Examples where community can integrate into project

Since the proposal is developed in the open the community can and should cross-check the compartmentalization and associate policies in order to validate the security of the IC. The community has also the potential to act as an early warning system for new forms of attacks and possible vulnerabilities of the IC.

What we are asking the community

The security of the IC is an essential property that needs to be constantly strengthened and adapted. This proposal aims to make a strong contribution to this effort. We welcome comments, questions and feedback and hope for a positive vote on the proposal.

4 Likes

Proposal is live: Internet Computer Network Status