Secure Operating Systems (Microkernels seems to be the future)

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

mikey,

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.

Punk_face,

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.

TheAnonymouseJoker,
@TheAnonymouseJoker@lemmy.ml avatar

Not gonna lie, this post looks like a thinly veiled attempt at shilling GrapheneOS and believing in the same Fuchsia/microkernel vision crap as Micay. And Graphene is a very ordinary AOSP fork with rebranding to begin with.

dsemy,

Graphene is not a very ordinary AOSP fork, why don’t you do some research before making incorrect claims.

TheAnonymouseJoker,
@TheAnonymouseJoker@lemmy.ml avatar

Why do you not do some research before buying into their pompous marketing claims? I have investigated and documented security charlatans in FOSS/privacy communities for 5 years, with nothing equivalent in the world as of today.

dsemy, (edited )

If you are so qualified to talk about this, why don’t you provide any details at all, instead of repeating yourself?

Edit: btw why would they even do “marketing”? It’s a non-profit free software project.

TheAnonymouseJoker,
@TheAnonymouseJoker@lemmy.ml avatar

FOSS snake oil and scams are plenty out there. There are many who abuse FOSS moniker as a medal of honour.

GrapheneOS is pure snake oil with a disgusting sole developer that believes in pushing corporate Big Tech propaganda, harassing and witch hunting any critics, having a little social media army with sockpuppets to do this, abuses mentally challenged by hiding behind “autism” label (Louis Rossmann has a nice video), falsely claims he was swatted without giving evidence or coverage in local Canadian media and blames everyone from redditors to community mods to YouTubers and so on.

I covered this disease for about 5 years, and it emanates from the same sewer that “security” clowns like Brad Spengler and madaidan do in Linux community. All they do is either push their bullshit solutions or push corporate Big Tech propaganda and hate any FOSS project they think will not worship them.

You can read my documentation of this lore here.

old.reddit.com/…/writeup_criticism_of_rprivacygui…

old.reddit.com/…/grapheneos_corporate_foss_loving…

dsemy, (edited )

All I see is a bunch of drama. Daniel Micay is also no longer the head of GrapheneOS.

IDK maybe beyond the wall of text there is some actual technical criticism, but I’m not going to sift through a bunch of unrelated pictures to find it.

GrapheneOS very recently reported two CVEs affecting Android, with one not affecting GrapheneOS due to their mitigations.

GrapheneOS has many features which are clearly visible to users and don’t really exist elsewhere - eSIM without Google Play, sandboxed Google Play, additional “Sensors” permission just to name a few.

Edit: I watched the Louis Rossmann video, www.youtube.com/watch?v=4To-F6W1NT0, and he also only talks about drama related to Daniel Micay (while clearly not saying anything negative about the project on a technical level).

TheAnonymouseJoker, (edited )
@TheAnonymouseJoker@lemmy.ml avatar

Daniel Micay is also no longer the head of GrapheneOS.

Then why is he the only one making any commits to this AOSP fork project on GitHub? You fell for his tricks too, like most.

Android devices in general are very good against security risks at this point, since Android 9/10 came. Android security continues to get solid across all devices at this point, with Android 14 release. Anything that is close to or stock is going to be very solid, and then it depends on competition evaluations like in BlackHat Pwn2Own every year. Pixel, Huawei/Honor, and Sony/Moto like stock phones tend to do very well, while Samsung, Xiaomi have issues due to lots of cruft and custom APIs they make in their skinned phones. Apple does well but iOS is insecure compared to Android.

I should clarify that sandboxed Google Play means practically nothing. You can use AppOps and neuter its permissions and achieve same effects of privacy and security on any non rooted phone, where only IP address and pings for Google certified SafetyNet device number is attained by Google, if you choose to use GMS.

Most of the security measures are something you can take with lots of Android devices, and is nothing exclusive to Pixel/Graphene fairy tales. Micay and his minions just love selling that combo as the only solution, and I frankly hate it as it has no basis in reality.

Edit: this is not drama. Please read the paper by Ken Thompson, co-creator of Unix and C, on why we should be able to trust the developer and NOT the code. cs.cmu.edu/…/Thompson_1984_ReflectionsonTrustingT…

dsemy,

This argument is going nowhere.

grapheneos.org/features lists features of GrapheneOS which differentiate it from AOSP. Are you claiming this is all fake?

Most of the security measures are something you can take with lots of Android devices, and is nothing exclusive to Pixel/Graphene fairy tales.

Is the Pixel 8 not the first device to support MTE? Is hardened_malloc pointless? And I literally listed 3 more features exclusive to GrapheneOS in my last comment.

TheAnonymouseJoker,
@TheAnonymouseJoker@lemmy.ml avatar

Hardened_malloc function is in Linux kernel, and so it is part of every single Android device since years now.

MTE looks like some memory overflow protection, but that comes in the form of various functions. It is not a fancy thing limited to Pixels or Chromium browser. Memory protection is such a standard thing in software, I am not sure how MTE specifically is some form of USP. Also, let me tell you that all apps in Android basically run sandboxed, as far as memory goes, and now with SAF, even storage permissions are restricted by default.

I broke down Graphene features a year or so ago to someone. Here it is. i.imgur.com/pQHoq84.jpg

There are only 3 things they ever did on their own as extras, and even they have basically no value in the grand scheme of things, them being offering:


<span style="color:#323232;">instead of 16 character, 64 character password limit on lockscreen
</span><span style="color:#323232;">PIN scrambling
</span><span style="color:#323232;">Morula method of exec spawning instead of Zygote method used in most AOSP projects
</span>

Now, I will elaborate on these 3.


<span style="color:#323232;">Elaborating on first one, it is kind of useless as you can see for obvious reasons.
</span><span style="color:#323232;">For second one, you already understand why fingerprint avoids the issue of someone peeping at your PIN/password entered across your shoulder. Fingerprint is infinitely superior. Even more so with Android and iOS both offering biometric Lockdown features.
</span><span style="color:#323232;">This one is somewhat half credible, but the goal is to destroy the memory blocks used by an app after it is exited, so that memory blocks do not retain essential text strings of data to exploit. For this, you can just go to Developer Options and enable “Don’t keep activities” and it will achieve the same effect as Morula method of exec spawning implemented by GrapheneOS.
</span>

So out of the 20-30 features GrapheneOS claims they developed, basically everything is either a modification of app permissions or firewalling or AOSP feature rebranding. You can do these things on any non rooted Android device.

Also, as you may have famously heard about “Sandboxed Play Services”, it is not developed by GrapheneOS, but a project called ProtonAOSP, whose developer is kdrag0n. GrapheneOS took that and rebranded it as their own developed thing.

I am not too interested in their buzzword self-circlejerking campaign after I observed this, in addition to the drama they invent via sockpuppets or otherwise to stay relevant in privacy communities.

dsemy,

hardened_malloc is a replacement for the libc function malloc. It is not part of Linux.

MTE is hardware-based, and is in fact restricted to Pixels currently (8+) AFAIK.

As I said in my first comment to you, do more research.

TheAnonymouseJoker,
@TheAnonymouseJoker@lemmy.ml avatar

They are not much more than buzzwords, and I did my research. Nothing is “dealbreaker” about not using Pixel/Graphene, and it is perfectly okay to use other Androids with plenty security. They sell snake oil dreams and pretend theirs is the only solution, and that sounds dishonest. Not to mention, them lying in YouTube comment sections on how they bought $1M Israeli Cellebrite kits and Pixel/Graphene combo is immune to bootloader attacks.

I do not see the developer and his internet minions lying as a source of increasing trustworthiness in the project, not to mention their FUD and dogma dissemination cultist tactics that fool privacy seekers. They are not keen on improving or teaching security, but in fooling and scaring people for personal benefits.

dsemy,

They are not buzzwords. I do agree that the project and its members could improve in many ways, but this is unfortunately true for many security focused projects.

TheAnonymouseJoker,
@TheAnonymouseJoker@lemmy.ml avatar

The ultimate result is not much more than buzzwords is what I mean. Memory security exists in Android to a great degree, and there are many protection mechanisms besides the obvious app sandboxing in general.

The project leader and his minions lie too much, refuse accountability, and this is not drama. It dissolves trust in any code they make or modify. The developer has to be morally trustworthy and honest first. If it was like a Linus being rude situation, it does not matter, because he is honest and his moral intent and heart is in good direction. Micay and “security” weirdos are the opposite in FOSS community.

dsemy,

You also made incorrect claims, bordering on lies honestly, as you didn’t seem to be familiar with hardened_malloc and MTE at all, and then doubled-down and called them buzzwords and then deflected in this very comment by claiming you meant “the ultimate result is not much more than buzzwords”. Then you proceeded to personally insult them.

Your behavior is much less extreme but not so different to the kind of behavior you’re criticizing. But at least Daniel Micay and his “minions” are working very hard to enhance the security and user experience of their users, even if you believe their efforts amount to minor improvements at best. So why should I trust you over them?

TheAnonymouseJoker,
@TheAnonymouseJoker@lemmy.ml avatar

Why should you trust me? Well, because I am not telling you to trust me. And I am only telling with hard evidence that they are working hard to harass, witch hunt critics, lie about everything, spread FUD and dogma that Pixel/Graphene is the only solution to world’s problems. They are NOT working to make phone security more accessible, or to clear doubts, but to increase doubts and fear.

The reality is that you cherrypicked marketing nonsense, and 1 feature that firstly practically amounts to nothing, and secondly dismisses the immense risks of Google’s proprietary security chip that brings with it a whole set of new issues that are directly related to security being verifiable and trustworthy. Apple’s “security” chips have all been hacked to date, both the ones in iPhones and MacBooks, leaving permanent backdoors, and Pixel is going to be no different with a refusal to open source the chips.

It is not insult to insult people that insult everyone. It is facts. Calling a Nazi a Nazi for example would not be an insult. Micay and other clowns have harassed FlorisBoard and Bromite devs on GitHub trackers by falsely calling them “neonazis” and other things, just as example. They deserve not just scrutiny but a lot of bashing for the horrible things they do to FOSS community members and all kinds of people, and they will receive every single bit of it for dodging accountability.

MigratingtoLemmy,

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

nickwitha_k,

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.

MigratingtoLemmy,

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.

nickwitha_k,

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).

MigratingtoLemmy,

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.

nickwitha_k,

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.

MigratingtoLemmy,

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.

onlinepersona,

I don’t know about OS development to chime in, but what outdated practices does RedoxOS have?

Anti Commercial AI thingyCC BY-NC-SA 4.0

ruben,
@ruben@lemmy.blahaj.zone avatar

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?

SecuMiKern,

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

dsemy,

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.

TheAnonymouseJoker,
@TheAnonymouseJoker@lemmy.ml avatar

Graphene has almost nothing special to it. Just about everything it claims is AOSP features/patches rebranded, and it borrows/copies/rips from other projects like ProtonAOSP and Bromite and who knows what else.

ruben, (edited )
@ruben@lemmy.blahaj.zone avatar

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?

barbara,

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.

wuphysics87,

Gnu Hurd

SecuMiKern,

Their basic premise seems solid, but is it actively developed? it seems to go through long periods of inactivity

lemmyreader,
vk6flab,
@vk6flab@lemmy.radio avatar

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.

SecuMiKern,

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

vk6flab,
@vk6flab@lemmy.radio avatar

I’m not sure what information you are working from, but these links appear to say something different:

ShortN0te,

Qubes is not mentioned at all.

shreddy_scientist,
@shreddy_scientist@lemmy.ml avatar

Qubes OS is Snowdens daily driver, Fedora SecureBlue is also designed with security and privacy in mind.

SecuMiKern,

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

Fedora Silverblue seems to be Fedora but immutable so many of linux’s problems still apply

shreddy_scientist,
@shreddy_scientist@lemmy.ml avatar

Fedora SecureBlue is hardened Fedora, and Fedora is also the base layer for Qubes as it’s all in all quite secure and private with some setting changes. I don’t know, but Qubes is top tier in my book. Tails OS could be another option if you’re that big on privacy and security though.

TheAnonymouseJoker,
@TheAnonymouseJoker@lemmy.ml avatar

And GrapheneOS is a rebranding of AOSP features. Whoops, I see a lot of double standards and misinformation. QubesOS has far more work into it than Graphene AOSP fork does.

zwekihoyy,

you’ve posted this same comment at least 5 times and you’ve been wrong every time.

TheAnonymouseJoker,
@TheAnonymouseJoker@lemmy.ml avatar

Claiming nonsense for trolling purposes does not make you a hero. You purposely did it few weeks ago and you are doing the same. This will not be allowed. You have no interest in being constructive, and generate false bait even though facts are different than your beliefs.

zwekihoyy,

I’m not trolling you’re just demonstrably incorrect.

TheAnonymouseJoker,
@TheAnonymouseJoker@lemmy.ml avatar

It so happens you supply no evidence and write thin air sentences, whereas I document and supply evidence. You are the demonstrably incorrect person here, that rides on Graphene cult wagon and gets 2-3 upvote ratio from those cult trolls.

zwekihoyy,

okay buddy

SecuMiKern,

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:

reddit.com/…/mesosphere_opensource_nintendo_switc…

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.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • privacy@lemmy.ml
  • Durango
  • DreamBathrooms
  • thenastyranch
  • magazineikmin
  • tacticalgear
  • khanakhh
  • Youngstown
  • mdbf
  • slotface
  • rosin
  • everett
  • ngwrru68w68
  • kavyap
  • InstantRegret
  • JUstTest
  • cubers
  • GTA5RPClips
  • cisconetworking
  • ethstaker
  • osvaldo12
  • modclub
  • normalnudes
  • provamag3
  • tester
  • anitta
  • Leos
  • megavids
  • lostlight
  • All magazines
    •