Hey everyone,
I’ve been quietly working on a Linux project called GREYWARD for a while now, and I think I’ve finally reached the point where testing it on the same few machines and VMs is giving me diminishing returns.
I’ve spent enough time watching it work on my hardware that I’m probably becoming blind to half the weird things other machines are going to do to it.
So this seemed like a pretty apropriate place to bring it. ![]()
**GREYWARD is an experimental Fedora 44-based desktop built around a fairly simple idea: I wanted stronger security defaults, but I didn’t want using them to mean constantly thinking like a Linux administrator.
**
Linux already has most of the pieces I want. SELinux, firewalld, NetworkManager, Flatpak permissions, LUKS, Secure Boot, USBGuard, Btrfs, and so on.
What I kept finding frustrating was that they’re all separate worlds.
If I want to know what my machine is actually doing, I end up checking several tools, configuration files and terminal commands. And even then, something changing elsewhere in the system can make the answer more complicated than “enabled” or “disabled”.
That’s basically where GREYWARD started.
I’m trying to make the security state of the machine feel like part of the desktop itself, rather than an admin panel you visit once every six months.
So GREYWARD has its own desktop direction and a first-party Security Center that brings together things like:
-
network activity and application connections;
-
firewalld / NetworkManager / OpenSnitch state;
-
DNS and VPN-aware network policy;
-
Flatpak permissions and application access;
-
USB/removable-device control;
-
Secure Boot, LUKS, TPM and other system evidence;
-
DNF5, Flatpak, firmware and security-data updates;
-
file scanning/quarantine;
-
Btrfs recovery points and Restic backups.
I’m deliberately not trying to replace Fedora’s existing components with custom daemons everywhere.
If Fedora already has a good mechanism for something, I’d rather use it and build around it.
The interesting part for me is what happens when those mechanisms start interacting.
One example I’ve spent quite a bit of time on is DNS.
Blocking unexpected DNS traffic is easy enough.
Then you connect a VPN and the VPN legitimately introduces another resolver.
If I blindly keep blocking it, networking breaks.
If I just allow DNS globally, the original protection becomes mostly decorative.
So now the system has to understand what changed, why it changed, and whether that new state is actually legitimate.
That’s the sort of problem I’m interested in with GREYWARD.
There’s also a fairly strong visual direction to it.
I didn’t want the security parts to feel like enterprise management software awkwardly glued onto a normal desktop. I’m trying to make the shell, notifications, Security Center and system surfaces feel like they belong together.
Whether I’ve succeeded is very much open to interpretation. ![]()
Where it is now
0.1.1 is still genuinely alpha.
It boots, installs and is usable, but I’m not presenting it as a hardened production OS and I absolutely wouldn’t put important data on it without backups yet.
I’m also one person, so the amount of hardware I’ve been able to test is laughably small compared with the variety of strange devices out ther.
Which brings me to the reason I’m posting here.
I need some cursed hardware.
If you’ve got:
-
an NVIDIA laptop that hates Linux;
-
unusual AMD or Intel graphics;
-
mixed-DPI or multiple displays;
-
Wi-Fi that only works when the moon is correctly aligned;
-
Bluetooth adapters with opinions;
-
weird USB devices;
-
suspend/resume problems;
-
VPN / DNS setups that aren’t simple;
-
or just an old spare machine you enjoy abusing…
…I’d be genuinely interested in seeing what GREYWARD does on it.
VM testing is useful too if you’d rather not hand an alpha distro an actual disk, which is an entirely reasonable survival instinct.
The failures I’m especially interested in aren’t just crashes.
If Security Center tells you something is protected when reality disagrees, that’s a particularly valuable bug.
Same for a security policy that technically works but makes normal use miserable. The goal isn’t to win a benchmark for number of restrictions enabled.
Another thing worth being transparent about: a lot/most of the implementation has been produced with AI coding agents.
I define the architecture and intended behavior, test it against the actual system, and iterate heavily, but I’m not going to pretend that makes AI-generated implementation equivalent to experienced human engineering.
That’s part of why I’m putting it out in public this early. If someone looks at a subsystem and says “you’ve built 800 lines around something Fedora already solves properly with X”, that’s a win as far as I’m concerned.
Source, screenshots, architecture, threat model, install instructions and the current ISO:
GitHub - MANTIS-devlab/GREYWARD · GitHub
If anyone here does try it, don’t feel obligated to write a polished bug report.
“Booted it on this hardware, this thing broke, here’s roughly what happened” is already useful.
And if you just want to dig through the architecture and tell me where I’ve made a bad assumption, that’s useful too.

