Operating System from Heaven

Genode and Sculpt OS
1

Hi There, Whonix/Kicksecure community here.

I have wrote an article showing where did i have reach with my experience of what we should have for the future as an OS, i would like to share that with you and see if you share the same vision.

In nowadays there is still no great secure operating system developed, especially one based on free software. Most of the necessary software exists, but the challenge lies in integrating it all into a cohesive whole to produce the most secure operating system.

What I will add here are software that already exist in reality, not theoretical ones.

Kernel (system)

Sadly, there is no reliable or usable freedom operating system based on a microkernel design. What we have are only monolithic ones, based on the Linux kernel.

Linux, by design, does not offer the same level of security as a microkernel. It is considered obsolete; nobody would want to build an operating system from scratch based on a monolithic design in nowadays.

Alternatives?

All mentioned are in active development and free software (sel4 is copyleft).

What i would avoid for sure is Zircon, because its google based.

What’s left are seL4 and Redox. Both are good, and if I had to choose one, I would choose seL4 due to its maturity.

Note (1): Minix and GNUmach are inactive.
Note (2): Hybrid kernel is not an option.

Packages Policy

The package is only going to be as secure and up-to-date as the upstream developers made it. There must be no interference or external involvement in adding or removing code from any package (no package maintainer).

Why

We have the Debian design, and we’ve seen how flawed it is when it comes to security and feature fixes. It’s horrible in every aspect. What we get from Debian is, at best, working software, but that doesn’t mean it’s secure, up-to-date, or even always stable. Issues like packages crashing on shutdown when clicking X or freezing on specific Y action, are common (because they are already in the distro passing freeze timeline without upstream fixes), and such bugs when occurs are unlikely to be addressed in a timely manner.

A major security flaw in Debian and Debian-like philosophies is that if the upstream of a package fixes a security issue and pushes it to their users, Debian remains unaware of it and will not include the fix in their own package unless it is documented or assigned a CVE. As a result, users remain vulnerable for up to maybe entire five years.

Another issue is the complexity trust in the chain of delivery. The more people who can add, remove, or manipulate the code, the more trust becomes a concern. If the code goes from developer X to intermediary Y (or even more intermediaries) before reaching the user, then the user must trust not only X but also Y and anyone else in the chain. Moreover, X doesn’t know Y or their practices, so X must also trust Y not to tamper with the code before reaching the user. This design introduces unnecessary trust assumptions. Code must be delivered directly from X to the user.

Note: Operating system developers should only interact with core/system-level packages, such as the kernel or desktop environment or VM configs or so.

System VS User Packages

System packages: Are going to be immutable, meaning read-only, no ability to modify with any rights (This helps as well with Verified Boot).

User packages: Will always be kept up to date with the upstream.

Kernel (user)/App-per-VM (ApV)

Realistically, having pure packages working directly with seL4 is not practical. It could take 10 to 20 years or even longer. (Linux has been around for over 30 years, and there are still packages that are Windows-only.)

So to solve this issue, we gonna use an already functional kernel which is linux!.. ok hold on a second didnt we just say that linux is a bad design? Thats correct if its used as the main operating system kernel, but if its used in a VM and that VM runs only a single application like firefox or thunderbird..etc the danger drastically decreased/minimized.

Note: AppArmor, SELinux, Firejail, Containers.. all are flawed designs when it comes to relying on them for security with packages running on Linux directly on hardware.

VM per Package per User (compartmentalization)

Each VM will run at the user level, and every VM will have its own dedicated user account. This isolation ensures that if a VM is compromised, it won’t lead to the compromise of all user packages or affect other VMs.

Default Block All

By default, when any app is installed in the VM, nothing is allowed automatically. Every permission including internet access must be explicitly granted by the user. This approach prevents any unwanted permissions from being applied silently without the user’s notice or consent.

No Backward Nor Sideward compatibility

No Backward: The operating system will continue updating itself for supported XYZ hardware. Once any hardware becomes obsolete, it will no longer be compatible, no legacy support.

No Sideward: There will be no compatibility for Linux, Windows, or BSD software at the system level. Compatibility may exist in App-per-VM. By default, only Linux apps are supported.

Additionally, if any app running in a VM does not work with a specific Linux version or hardware architecture, it is not the operating system’s responsibility to ensure compatibility (upstream issue).

Packages Source (App-per-VM)

One might say that hosting our own packages on our own servers would be the ideal solution, and that’s true. However, with a small team and limited resources, that’s not currently feasible (though it remains the long-term goal).

What we can do instead is source packages from existing systems, whether Gentoo, Arch, Nix, or others as long as we can obtain pure, upstream, patchless packages. Reproducibility is essential here to ensure that the packages have not been tampered with in the path of delivery.

Note: We can also support App(per-VM) rollback, or install older version directly, since these packages already exists in these OSs repository.

This approach doesn’t conflict with the core philosophy of keep it updated, as the primary focus remains on using updated software, not rollbacks.

App-per-VM Hypervisor type

Type 1 (bare-metal) hypervisors will be used for minimalism, reduced attack surface, and better performance.

seL4 provides libsel4vm, which fits well with this design.

Package Manager Security

All packages delivery must comply with TUF, meaning delivery path of the packages must be secured without the depends on TLS to do that.

Note: This level of security is not fully implemented by any existing package manager that I’m aware of. However, it can be enforced when using our own server for packages, especially in the App-per-VM model.

Bootstrappability

I think this is possible, since the OS will be with minimal packages (as a system level). [ref]

Wayland only

There wont be x11/xorg nor xwayland, either wayland or no land.

No Rescue mode

Rescue mode is like giving a backdoor to your own OS or software. If you break your system or forget your password, it’s your responsibility, no one else’s and no help will be provided, because there’s nothing anyone can do.

This also encourages users to maintain proper backups of their data, whether on their own hardware or in the cloud.

(Rollback and Snapshots helps as well)

Architecture & CPU Support

Only x86 will be supported, due to its widespread use (Intel or AMD CPUs). Support may be extended in the future to other freedom (or almost freedom) based architectures, such as RISC-V.

ARM or similar proprietary architectures will not be supported—there’s no reason to waste time on them. Supporting the most common proprietary architecture (x86) is sufficient. (Though seL4 supports ARM anyway).

No Stupid or OLD Devices Support

There wont be any old or nonsense software support in the system level (like IRC in the kernel?! or Floppy Disk Support..)

If necessary, such support may be possible within the App-per-VM (ApV) model, since it’s based on Linux and already includes support for these kinds of legacy features. However, this will never be a priority.

Only Latest/Best Encryption Used

Since there will be no backward compatibility, only the best and most secure options available will be used, whether in TLS versions, cipher suites, OS-level encryption, or any other security-related components.

Offline Installation

It is more secure to avoid installing the operating system while connected to the internet, as also advised in Debian’s security manual.

Offline System Core

Similar to Qubes OS, the system core/base will not be connected to the internet (essential for security purposes).

Non-Systemd Init

Although not a direct security issue on its own, systemd is a bulky piece of software and has been heavily criticized for numerous things. The good news is that Genode OS has developed its own lightweight init component that works with seL4.

Hardware Specifications

Similar to qubes requirements or equivalent:

Optional Preferable

Btrfs/Snapshots/Timeshift like

It should be easily to achieve this with immutable upgrades (you can rollback to the previous state).

Server Support

Finding a way to make ApV able to manage server/s.

FSDG Consideration

This all can go through only supporting freedom software (software for the ApV must be taken from FSDG distro repository in this case).

Secureboot

Only makes sense when it doesnt depend on microsoft keys.

Onion Repository

Will harden the avoidance of targeted attack (explained here).

Nested Virtualization

This feature will be the responsibility of the seL4 team, whether they implement it correctly and securely or not. It’s particularly relevant in scenarios involving running an OS + VM inside another VM, or using a virtualizer/hypervisor within a VM (e.g. VirtualBox-in-VM).

Competitors

Proprietary competitors are on the rise. HarmonyOS, for example, is arguably the most mature general-purpose microkernel-based OS developed in China. Google’s Fuchsia is another example. If we don’t stay ahead of these developments, control over security will slip from our hands, placing it instead in the hands of large corporations or state-backed entities.

2

Welcome to the community!

There is a lot of food for thought in the essay. I have in the past pondered the idea of starting a thread of Fuchsia vs Harmony vs Genode, and I see that mentioned towards the end.

You imply that the essay is already posted elsewhere on the internet and I wonder, in the interests of brevity, whether your original post might link to that rather than copy and paste in its entirety.

1 Like
3

Thank you

Im the same author, but in our platform the topic is divided into different small topics for each subject, here just in one entire chunk as it will be easier to comprehend the image.

1 Like
4

In the first half of the proposal, many items remind me of Genode’s philosophy of “opt-in” rather than “opt-out” authority. In Genode-based systems, launching an application implies that the system adds (explicit) permissions. What is not allowed, is automatically disallowed. It’s the system’s choice of how to do that and expose it to the user. For instance Sculpt OS provides menus allowing the user to ‘connect’ an app (Falkon e.g.) to a file system, audio in/out, screen/windowing, network and so on. If the user connects e.g. Audio-In to a black-hole, there is nothing the app can do to “jail break” and access the microphone. So the concept outlined above of VMs that require explicit permissions for any and all access reminds me of that.

As to Genode’s init, I’m not sure I would compare it to systemd. In my mind, it is simply an abstraction layer on top of Genode’s PD primitives, to be used by programmers and system integrators. It allows programmers to easily instantiate (launch) an executable by creating a “script” written in XML instead of the underlying APIs, but it does not handle automatic launch after boot-up and “daemon” features and such, on its own. Those have to be programmed on top of it. That responsibility lies on the system inegrators, i.e. the programmers who create a Operating System based on the Genode framework. I might be misunderstanding the point made in the article though.

1 Like
5

Nice! thats a good security mindset.

I see, its still like more initd than systemd level at the moment. Not bad for now, any improvements towards more features on the roadmap?

Yeah my article is that do you guys moving towards the same goals? how much does your software support some of the suggestions at the moment or on the roadmap?

ThX!

6

In Sculpt OS, you mean ? That’d be for the Genode team to answer, the february-november roadmap does not mention it. I’d speculate adding initd/systemd-like features is not to be expected in the near future, as the Genode team tends to focus on ‘foundational’ features and consolidation. And if they do add something like that to Sculpt OS in a year or three, it will probably be tabula rasa, i.e. it will probably break free from the past and implement a new vision, based on a fresh analysis of the needs ^^

As to the other goals, I suspect they would also like to ‘delegate’ some of them to the community, rather than implement them themselves.

And that makes sense:

To me, the Genode framework is possibly the only one out there for which it is almost as easy for ‘outsiders’ to write an OS, as it is for the Genode team itself:

  • the Genode team writes Sculpt OS based on (their) Genode code
  • outsiders like us can write our own OS based on the very same Genode code

Other systems have a rather high “barrier to entry”, whereas Genode has very clear code, good documentation, and an incredibly accessible architecture. So in theory anyone can “compete with Sculpt OS”, and it’s a mystery (and a shame) to me, why there aren’t more, many more, people doing just that!

To put it another way, their vision of an Operating System based on Genode is Sculpt OS. Other people might have another vision… And indeed there are a few attempts to write an OS “competing” (so to speak) with Sculpt OS (one commercial/industrial with financial backing, and the others are more like “hobby” projects). There should be many more such projects, and they should reach completion.
If a new “Linux-Sculpt OS” project is added to the list, that would be interesting. And such a project, aiming at executing Linux binaries “as-is”, based on the Genode framework, might attract followers and motivated ecosystem members. No idea ATM what the tech side involves though.

1 Like