I am not satisfied with Linux’s security and have been researching alternative open source OS for privacy and security So far only thing that’s ready to use is GrapheneOS (Based on Android) but that’s not available on desktop (Though when Android release Desktop mode it may become viable)
Qubes OS is wrapper around underlying operating systems, so it doesn’t really fix for example Linux’s security holes it just kinda sandbox/virtualize them
OpenBSD is more secure than Linux on a base level but lack mitigations and patches that are added to linux overtime and it’s security practices while good for it’s time is outdated now
RedoxOS (Written in Rust) got some nice ideas but sticks to same outdated practices and doesn’t break the wheel too much, and security doesn’t seems to be main focus of OS
Haiku and Serenity are outright worse than Linux, especially Haiku as it’s single user only
Serenity adopted Pledge and Unveil from OpenBSD but otherwise lacks basic security features
All new security paradigms seems to be happening in microkernels and these are the ones that caught my eyes
None of these are ready to be used as daily driver OS but in future (hopefully) it may change
Genode seems to be far ahead of game than everything else
Ironclad Written in ADA
Atmosphere And Mesosphere Open Source Re-implementation of Nintendo Switch’s Horizon OS, I didn’t expected this to be security-oriented but seems like Nintendo has done a very solid job
Then there are Managarm, HelenOS, Theseus but I couldn’t figure out how secure they are
Finally there is Kicksecure from creators of Whonix, Kicksecure is a linux distro that plans to fix Linux’s security problems
if you know of any other OS please share it here
You must log in or register to comment.
Linux is run on basically all servers. What kind of security do you have in mind? Someone else already stated it, qubes and secure blue are good. Your text is rather vague, I don’t understand what you are looking for.
I’m unsure why you think that Linux mitigations should apply to OpenBSD.
A different approach is to use a version of an OS that is read-only (immutable).
I noticed that you didn’t mention ChromeOS.
Edit: Added immutable, couldn’t think of the word.
Some vulnerabilities are not specific to linux like Heartbleed, Spectre, Meltdown
And even though OpenBSD fix most famous/severe ones, others are not tested or their fix may lag behind
I’m not sure what information you are working from, but these links appear to say something different:
GrapheneOS is just Android and (as far as i know) all Android versions use SELinux. Why not just use a basic distribution like Arch with SELinux?
It’s not, GrapheneOS is hardened Android check their site for more information
And android is not just linux + SELinux there is much more to it
IDK why people are downvoting you, you’re absolutely right.
Android is Linux (with SELinux enabled and integrated) + a userspace designed to run sandboxed applications securely. The result is much more secure than probably any Linux distro (other than stuff like Qubes).
Sandboxes employed by Flatpak and Snap are extremely weak in comparison.
Of course Android is not just that and I never claimed that. Are we talking about the security of the kernel or the whole OS? If you deem the kernel used in GrapheneOS to be sufficient for you, I’m assuming that it is the rest of the OS that concerns you. What in particular do you find to be good in GrapheneOS that SELinux with AppArmor and a trusted userland doesn’t achieve?
Whew, there’s a lot to unpack here.
First, microkernels being the future: This is a sentence that was said time and time again, but while microkernels definitely have some advantages in separating components which could yield better security, in practice it also introduces other security concerns, not present with monolithic kernels, mostly with the communication between the kernel services.
Second, about the no secure Linux distros thing: As many others have mentioned, there are security-conscious Linux distros, mostly the “immutable” distros. You can use Fedore Silverblue (or even better, SecureBlue) as a daily driver, with Flatpak for your apps. That way, your main OS is read-only, thus harder to infect and all system updates are signed and verified. Using Flatpak helps enforce permissions on apps in a manner similar to Android permission (you can deny an app the right to see your files, for example).
Third, I don’t really understand what you mean by “Linux’s security holes”. Of course it’s not bug free, but no kernel of this magnitude is. Also, GrapheneOS uses Linux as well, albeit with a hardening patchset, but you can also get that with desktop Linux distros. If you think Linux (being a monolithic kernel) is automatically less secure than microkernel and hybrid kernel based systems, take a look at Windows and macOS, which both use non-monolithic kernels, but most security experts will tell you that you’re better off using Linux.
Fourth, about all the niche, mostly hobby OSes you listed: A big part of security is about having more eyes on the source code. Even if you write a kernel in a “safe” programming language, there will be bugs. Something as advanced as a kernel that’s ready for daily desktop use and provides advanced isolation between processes is going to be so complex that you won’t be able to see what bugs arised from the different parts interacting with each other. Safe programming languages make it easier to write safe code, but don’t stop you from messing up the logic that defines what apps have which permissions. Your best bet is to stick to software that has had time to mature and had more people and companies look through it. Linux is regularly audited by all tech giants, because all clouds use Linux to some extent. If it’s secure enough to isolate the workloads in Google Cloud, and Amazon’s AWS, it’s going to be secure enough for your desktop, provided you use it well (make use of it’s security features and don’t shoot yourself in the foot by disabling mitigations and the like). This is partly why I think the idea that OpenBSD is more secure than Linux is somewhat outdated. Yes, they advertise it as such, but it has seen much-much less auditing than Linux did in the cloud era.
Of course, there’s nothing wrong with playing around with alternatives operating systems, just don’t think you’ll be more secure just because something is written in Rust, or is a microkernel. Those can help, but there’s much more to security than the guardrails a programming language or software architecture can provide, especially with something as complex as a modern kernel.
Gnu Hurd
Their basic premise seems solid, but is it actively developed? it seems to go through long periods of inactivity
I’ve not come across such a topic in a while; what security issues do you see with monolithic kernels that are not present in Microkernels? Other than the “more code so more bugs” part
Worse performance and increased attack surface due to substantial increase in number of system calls required for any given task?
Oh. You were asking how microkernels are better… They’re smaller. I think that’s about it. Great for things like RTOS where the scope of the kernel is much more limited, specialized, and likely needs to live in an MCU’s tiny ROM.
As I understand it, a crude way to specify a micro kernel might be to call it a specialised slice of a monolithic kernel. It’s still a kernel, and it being more/less efficient, have better security etc depends on the code itself rather than something external.
Understandably, I understand that the motivation comes from a combination of embedded projects: I remember that Minix is still a good example of a micro-kernel albeit being extremely vulnerable and buggy. Microkernels are nice, but I suppose one should look for a compromise when thinking of an OS based on Linux which runs around the world, and having a specialised kernel might not be the best idea.
As I understand it, a crude way to specify a micro kernel might be to call it a specialised slice of a monolithic kernel. It’s still a kernel, and it being more/less efficient, have better security etc depends on the code itself rather than something external.
You’ve got a lot of it, yeah. A microkernel tends to try to implement the smallest amount of essential functionality needed. When used in a specialized environment, like embedded controllers (ex. ZMK firmware, which is built on the Zephyr Kernel), microkernels are great and can exhibit great performance and efficiency.
Once one starts trying to build a general-purpose OS with a microkernel, however, things deteriorate very quickly. Things that are essential for general-purpose computing usually do not make it into the scope of the microkernel’s functionality. This means that anytime something as simple as opening a file is required, a lot more communication is needed between processes, increasing the number of times that calls need to cross between the kernel and user context boundary.
Every context change requires one or more operations and the isolation necessary to be secure, means that they microkernel has to act as a messenger any time that a subsystem needs to communicate with another. The total number of system calls grows at an exponential rate, killing performance and increasing the threat surface that an adversary can target (individual components even end up needing greater awareness of security because there are now a lot more potential “weak links” in the data transmission chain).
That’s why a suitable middle-of-the-road approach seems to be statically compiling one’s kernel with the least amount of add-ons (drivers - that’s what most of the kernel is anyway) possible. I see it as a decent idea but annoying in practice since bigger updates mean either a script/manual intervention every time, and I like Debian so you can see how I perceive that.
Exactly. And it also introduces limitations, should your system usage exceed the bounds expected and established when compiling. Like so many other things, context matters.
And now we’ve come a full circle. Microkernels are better because they have less code, but to make them usable across various systems you’d need to add more code. And after a point it’ll stop being a micro kernel.
Qubes is not mentioned at all.
More info on Atmosphere (Open Source Horizon AKA SwitchOS) as I find it fascinating that an OS created for a gaming device got such tight security:
https://www.reddit.com/r/emulation/comments/hygtnx/mesosphere_opensource_nintendo_switch_kernel_now/
Quotes from Creator of Atmosphere:
It is a completely unique microkernel with a cooperative (non-preemptive) scheduler. The kernel is secure – so far as I can tell (as a reverse engineer and hacker), it has zero security bugs. They throw out years of backwards compatibility (they’re not POSIX/UNIX), and they really, really benefit from it from a security and modularity PoV. Horizon’s the only meaningful RTOS with a microkernel that I’m aware of (other than Fuschia). Everything’s in userland – filesystems, gpu (and other device drivers). The OS is capability-based and conceptually all about lots of different processes/drivers (“system modules”) that host microservices. The fact that Nintendo designed such a rock-solid, modular, custom operating system for their consoles fascinates me.
IPC is the hottest hot-path in a microkernel, correspondingly Nintendo marked every function involved in IPC as attribute((always_inline)), this was kind of a huge pain to reverse engineer as a result. In addition, Nintendo implemented “SvcReplyAndReceive” as a single system call that allows a microservice server process to reply to and receive a new message in one invocation. That said, there’s actually less overhead than you think. Past of why FUSE is slower than a kernel driver for FS is because FUSE has to talk to the kernel to do filesystem stuff, so when you read a file you have your process -> FUSE -> kernel -> hardware. In comparison, on Horizon the kernel is completely uninvolved in filesystem management (it doesn’t even have the sdmmc hardware mapped). Thus processes will do process -> FS system module process -> hardware.
In Horizon, everything is very distinctly not a file. There’s no global filesystem paths the way that unix/linux have special /dev/whatever. Pipes don’t exist in Horizon – all IPC is done via the horizon ipc (“HIPC”) protocol. UNIX/POSIX have stuff like fork() and child processes…but creating a process is an incredibly privileged operation in a capability-based operating system. Fork() is impossible to implement in Horizon, all threads are created via SvcCreateThread() instead. Child processes aren’t a thing that exist.
I just read an older article about the black market using graphineos to create a supposed private phone to run drugs, however the FBI joined forces with two other countries to infiltrate a man in the middle attack and busted the drug ring. I think a private os is a pipe dream since you still need to get on the internet and as long as you’re online, you’re vulnerable.
deleted by creator
Server security is not completely same as desktop one, Linux kernel is spaghetti code with very large attack surface, only reason it’s not exploited more is Linux Desktop is not as lucrative target as Windows, Proper sandboxing doesn’t exist and is half assed, Qubes is the only one properly doing sandboxing on Linux
OpenBSD and Qubes seems best solution so far but neither are ideal
Qubes doesn’t address Linux’s security problems it just sandbox/virtualize them and it requires beefy hardware
Fedora Silver Blue doesn’t do anything special really it’s your normal linux distro just immutable and relies on flatpaks (On another note Flatpaks sandbox are easy to break and most programs don’t use it properly)
only reason it’s not exploited more is Linux Desktop is not as lucrative target as Windows
It would be much more lucrative to exploit the Linux servers, Android (based on Linux) phones, embedded Linux devices,… than that tiny niche of Windows desktops could ever be.
Linux servers exploit is different than Linux desktop exploit and 1000% different than exploiting Android
It’s general misconception that Android is just Linux but it’s not, it’s like saying Linux is just GCC compiler
You already said that openbsd has pros and cons. I’m not sure how you get to the conclusion that it’s better overall than linux at the same timr as stating that it’s behind linux.
https://lemmy.ml/comment/10078459
This is the comment. There was a duplicate which is why I deleted it. Somehow you answered to the one I deleted.
Anyway, I was refering to secure blue, not silverblue.
Your criticism about flatpak implies that the user installs the malicious app in the first place. Just don’t. As dumb as it sounds but the user can be the best antimalware shield. Just don’t install crap. Facebook is tracking you? Don’t install it. Look at xz, and how well it was detected and how quickly everything was fixed. Don’t install unknown software. Use trusted sources. Listen to other people. Flatpak is in a good path. I’m not sure why criticing it leads to abandoning instead of improving it.
I am not native English speaker so sorry for misunderstandment
I didn’t say it’s overall better
I said even though on base level OpenBSD is much more clean and secure than Linux it lacks or lags behind Linux in adding mitigations for security vulnerabilities
And there are far less eyes on OpenBSD so many vulnerabilities don’t get discovered in first place
Any software can be malicious even essential ones just look at recent Xz vulnerability (And it was discovered by sheer chance), OS should have systems in place like proper sandboxing, permissions (Not half baked one like flatpak) …
Many Flatpaks bundle libraries which aren’t available in any runtime. There have been cases of non-malicious Flatpaks (on Flathub) containing known vulnerable versions of libraries. Is a user expected to cross reference a Flatpak’s manifest with known library vulnerabilities before installing it?
Flatpak’s “sandbox” (more of a container really) also breaks internal sandboxing mechanisms used by some other apps notably Chromium-based browsers (they use some hack to use Flatpak’s sandbox instead but I doubt it is as secure).
Flatpak is not a security tool, it is a software distribution tool (Edit: BTW, the Flatpak project doesn’t even claim to be about security).
Let’s improve flatpak, instead of abandoning it :)
Personally I don’t see the harm in abandoning Flatpak, the technologies developed to support it (bubblewrap, desktop portals and the secure contexts Wayland protocol to name a few) are far more important and can be used independently.
I think Flatpak has the potential to be good, if distros use it as their primary package manager with a sane (not Flathub) repository (Fedora has a well maintained Flatpak repo, for example). Otherwise, for the average user, installing a Flatpak from Flathub when there is a distro package available might seem like a good idea because they heard about sandboxing, but in many cases it will actually be more secure to just use the distro package.
-
https://chimera-linux.org FreeBSD userland with Linux kernel and Musl C library.
-
I don’t know about OS development to chime in, but what outdated practices does RedoxOS have?
Anti Commercial AI thingy
