Based on my past experience with operating systems and software, 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.
Sadly, there is no reliable or usable freedom operating system based on a microkernel design (yet). 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?
seL4
Redox
Zircon
All mentioned are in active development and free software (sel4 is copyleft).
What i woul…
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, only to make the package work as is from the upstream).
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.
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.
Similar idea discussed here:
Android, iOS, macOS, and Chrome OS all provide a level of separation between user-installed applications and the operating system. The operating system may provide certain applications to the user, but those applications are not installed by the user and generally cannot be uninstalled or replaced. User-controllable applications are separated from the rest of the system, and generally are sandboxed to prevent them from doing damage if they turn out to be malicious or become compromised.
Debian …
Instead of having software per user isolation (used in android), it will be each VM will run at the user level, and every VM will have its own dedicated user ID (and inside the VM where the app is installed). This isolation ensures that if a VM is compromised, it won’t lead to the compromise of all user packages or affect other VMs.
Sorta related:
https://computingforgeeks.com/use-virt-manager-as-non-root-user/
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.
Inspiration for a graphical permission gears:
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 in the VM (This case if the system using different kernel like seL4 or so, but if its using Linux then no other OS should be given/cared …
Note: This is written with the assumption of having a separation between the packages for the system differ from the packages for ApV.
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 should remains the long-term goal).
What we can do instead is source packages from existing systems, whether Nix, Arch, Gentoo, or others as long as we can obtain pure, upstream, pat…
Type 1 (bare-metal) hypervisors should be used for minimalism, reduced attack surface, and better performance.
seL4 Microkernel provides libsel4vm , which fits well with this design.
For Linux kernel we can use Xen hypervisor .
Note: KVM is not true hypervisor type 1, check comparison of KVM vs Xen .
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.
It should be ideally possible to build up your OS from source code. I think this is can be possible, if the OS will be by default with minimal core packages (system level). More info:
There shouldnt be x11/xorg nor xwayland, either wayland or no land.
Otherwise we gonna face the loop of legacy and unwanted vulnerabilities .
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)
Only x86 will should be supported, due to its widespread use (Intel or AMD CPUs or so). 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&Linux supports ARM anyway).
There shouldnt 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.
Since there shouldnt 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.
It is more secure to avoid installing the operating system while connected to the internet, as also advised in Debian’s security manual .
Similar to Qubes OS, the system core/base should not be connected to the internet (essential for security purposes).
Although not a direct security issue on its own, systemd is a bulky piece of software and has been heavily criticized for numerous things.
For linux there are init available check here .
For seL4 good news is that Genode OS has developed its own lightweight init component .
Note: Though Genode init is not with (yet) rich features as systemd.
It should be easily to achieve this with immutable upgrades (you can rollback to the previous state).
Its nice to have a way to make ApV able to manage server/s.
Only makes sense when it doesnt depend on microsoft keys.
This feature will be the responsibility of the hypervisor provider like seL4 team or KVM or Xen…etc, 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).
Sadly, there is no reliable or usable freedom operating system based on a microkernel design (yet). 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?
seL4
Redox
Zircon
All mentioned are in active development and free software (sel4 is copyleft).
What i woul…
We can also support App-per-VM rollback, or install older version directly, if these (old) packages already exists in the repository (in case we gonna use something similar to nix or arch).
This approach doesn’t conflict with the core philosophy of keep it updated, as the primary focus remains on using updated software, not rollbacks.