I don't understand... Your motivation for a secure operating system was from an incident where you were nearly social engineered? How will a "more secure" os help you with that?
this post was submitted on 10 Dec 2025
65 points (89.2% liked)
Linux
60406 readers
1024 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 6 years ago
MODERATORS
I am excited to see Chimera Linux mature because iy seems like a distro which prioritizes a simple but modern software stack.
Features of Chimera that I like include:
- Not run by fascists
- Not SystemD (dinit)
- Not GNU coreutils (BSD utils)
- Not glibc (musl)
- Not jemalloc (mimalloc)
- Proper build system, not just Bash scripts in a trenchcoat
What I would like:
- MAC (SELinux)
- Switch to Fish over Bash (because it is a much lighter codebase)
- Switch from mimalloc to hardened_malloc (or mimalloc built with secure flag). Sadly hardened_malloc is only x64 or aarch64
- Hardened sysctl kernel policy
What are the pros/cons of GNU coreutils vs BSD utils?
EDIT : from their website : Desktop environment -> GNOME. What a choice, not for me.
First, I use either Niri or KDE Plasma on Chimera Linux. Both are just an “apk add” away. You do not have to use GNOME. There is even a KDE live image so you do not even have to run GNOME once to install if you do not want.
I really like the BSD utils and have come to prefer them. Well written. Sleek. Well documented. The man pages are a walk through UNIX history. They feel “right” to me.
That said, the BSD userland is frequently a pain when interacting with the rest of the Linux universe. You cannot even build a stock kernel.org kernel without running into compatibility problems. The first time I built the COSMIC desktop on Chimera, I had to edit a dozen files to make them “BSD” compatible.
Sed, find, tar, xargs, and grep have all caused me problems. And you need bash obviously. But bash is no big deal because it has a different name.
The key GNU utils are available in the Chimera repos. But you get files named gfind, gtar, gxargs, gsed, etc. so scripts will not find them.
You often have to either add the ‘g’ to the beginning of utilities in scripts or edit the arguments to work with the BSD versions.
I mean, most things are compatible and I bet most of the command-line switches you actually use will work with the BSD utils. But I would be lying if I did not say third-party scripts are a hassle.
If I could do Chimera all over again, I would make it bsdtar and bsdsed (or bsed maybe) for the BSD versions.
Maybe the regular names could be symlinks with sed pointing to bsdsed by default but you could point it to gsed instead of you want. The system Chimera scripts and tools could use the longer names (eg. bsdsed) instead of the symlinks. The GNU tools could be absent by default like they are now. That would be the best of both worlds. The base system would have the advantages of the BSD tools (like easier builds as outlined on the Chimera site), the system could be GNU free if you want, and you could have a system that actually works out of the box more often with third-party scripts.
It pains me to say this. I would prefer not to use the GNU stuff but the GNU tools are the de facto standard on Linux and many, many things assume them. No wonder UUtils aims for 100% compatibility.
Anyway, even with what I say above, Chimera is my favourite distro. The dev can be a little prickly, but they do nice work.
The GNU utils vs BSD utils issue should be easy to work around with a bit of symlinking and PATH modification:
> type find
find is /bin/find
> type gfind
gfind is /usr/local/bin/gfind
> sudo mkdir -p /usr/local/opt/gnuutils/bin/
> sudo ln -s /usr/local/bin/gfind /usr/local/opt/gnuutils/bin/find
> PATH="/usr/local/opt/gnuutils/bin:$PATH" type find
find is /usr/local/opt/gnuutils/bin/find
or in script form:
#!/bin/sh
# install as /usr/local/bin/gnu-run
# invoke as gnu-run some-gnu-specific-script script-args
export PATH="/usr/local/opt/gnuutils/bin:$PATH"
exec "$@"
/usr/local/opt/... is probably not the best place to put this but you get the idea, you can make it work with POSIX tools. I don't know that much about Chimera Linux but I'd be very surprised if nobody has thought of doing this systematically, e.g. as part of a distributable package.
Thank you for the suggestion. I am ashamed to confess that a temporary PATH variable had not occurred to me.
I first ran into these issues creating package templates. Chimera has a beautiful package build system where packages get built in containers and source code gets downloaded into the container and and built against a clean environment. As you point out, creating a package that creates the symlinks as a dependency (along with the GNU utils) could be a viable approach here. Maybe even just in /usr/local. The GNU utils get installed to /usr/bin in Chimera and the container gets recycled for every new package. The distro would never accept such hacky packages but I can use them myself.
For just generally working in the distro at the command-line, your temporary path idea could work well.
Thanks again. I appreciate it!
GNOME is just the default, there's also KDE and no-GUI options if I'm not mistaken
Chimera is a nice alternative to Alpine, have you thought of sending this feedback to Chimera's dev?
I thought about it (and I might still) but the project is still in beta and implementing sysctl and MAC would slow everything down development-wise. Switching to Fish would be easy and cool though.
Chimera Linux is great. APK and cports are so good I cannot imagine going back to anything else.
Bash is not the default shell though. Chimera uses the Almquist Shell from FreeBSD. Other Linux distros have “dash” which is basically an Almquist variant.
Almquist is lighter than fish and fish is not POSIX compatible.
Bash is available in the Chimera Linux repos of course and is required for many common scripts.
“Not run by fascists”. Sometimes I wonder.
Thanks for the info! Didn't realize it was dash.
I think Secureblue + GrapheneOS are the most reasonable choices imo. Qubes is highly hardware intensive for what it does, it will frustrate most people.
It works decently with just 8 GB RAM, and I'm going to upgrade the RAM.
Secureblue is based on sandboxing rather than paravirtualization, and I'm not sure that's secure enough for me.
I do agree it's likely more secure, but the tradeoff for common use cases (gaming, development) is steep. I could see using it solely for browsing and messaging people
You can also just slot secure blue into a qube I believe
load more comments
(1 replies)
load more comments
(3 replies)
I find it odd that the author didn't mention secureblue at all. I wonder why they didn't consider that option?
I actually forgot to mention it, but I was going to say anyway that sandboxing I deem less ideal than paravirtualization
I don't know anything about that but it sounds interesting. If you have any sources for further reading about sandboxing vs paravirtualization, I'd like to read up on it
What I want out of a secure Linux (or BSD) system is full (top-to-bottom) sandboxing of all components to enforce least privilege. I am want to learn how to make my own distro (most likely for personal use) which uses strong SELinux policies, in conjunction with syd-3 sandboxing, which seems like the most robust and feature rich, unprivileged sandbox in both the Linux/BSD worlds (also it's totally in safe Rust from what i can tell).
Another thing that I would love to make is a drop-in replacement for Flatpak that is backwards compatible but uses syd-3 instead. It has much better exploit protections than Bubblewrap, and is actually an OOTB secure sandbox. I dont know much about the internals of Flatpak, or how to use xdg-desktop-portal, but I am going to start more simple with a Bubblejail alternative. One major advantage of syd is that you can modify an already running sandbox, so theoretical you could show a popup that says something like "App1 is requesting microphone access.", where you could toggle on without needing to restart the app.
Need to get better at coding tho lol
You can try to just make a hardened NixOS config. The only requirement is systemd to use NixOS options. Other components you can freely interchange.
I'm not very good at securing Linux, but from what I've seen, NixOS leaves a lot to be desired. It doesn't officially support SELinux and requires a lot of work to make it function properly. It supports other mandatory access control programs, which I'm not really sure how they compare. The store being world readable is another problem. The most obvious issue with that is if you're doing business work with two clients on the same computer where infrastructure needs to remain confidential, where one client's programs can read the store and see information about the other clients, even on separate user accounts.
I think the preferred approach is AppArmor because SELinux is not supported on immutable distros. I'm not a security expert either, but I would not share environments between two clients at all, I would put them in separate VMs
SELinux is used on all the Fedora Immutable distros, and the OpenSUSE Immutable distro. It's actually much easier to do SELinux in Immutable distros in a lot of ways than non-immutable. Especially the bootc-style ones where even more of the system is defined and prebuilt before deployment.
AppArmor is OK, but the whole issue is that you have to know what to throw into it. That's also its benefit, you can focus in the high risk things and ignore the low risk things. It keeps expanding profiles more and more though, and ironically the ultimate destination is everything being under MAC.
Well, that's because it's a first party solution. From NixOS point of view SELinux is mutating the store which is forbidden
It's not. SELinux predates Fedora. Fedora went all-in on SELinux pretty early on though (a few other older distros too, but Fedora is one of the few remaining with significant mind-share), and many other distros decided not to do security at all for many years.
AppArmor is "sufficient" if you only want to deal with known-in-advance high risk applications being locked down, which was the approach most other distros took since it's extremely complex to have a policy for absolutely everything (like SELinix requires).
In the latest distros using AppArmor, it's been expanding so much that it is arguably easier to just implement SELinux and derive from Fedora's Standard Policy. Ubuntu 24.04 for example was been broken by thier various AppArmor bugs for almost 1.5 years after release, all because they slapped system-wide AppArmor policy restrictions on the default system and didn't coordinate any of it.
SELinux also doesn't mutate the store unless the package in the store failed to set an SELinix file label. Providing the labels in most cases is trivial, so trivial in most cases that a global SELinux Nix policy package exists in a number of distros that can set normal defaults that work for most things.
Setting the label is the mutation
And it's only necessary because Nix doesn't include it. Which is the only way anything is allowed to run on an SELinux system. SELinux doesn't require Nix mutation, it requires Nix to be complete.
There are workarounds to fix Nix's incomplete definitions, but most end users opt for the easy post-install solution that ends up mutating thier store rather than including the fix as a unique derivation for every package to add the missing SElinux labels and policy.
Which is what I was talking about when I said immutable systems need a first party solution. Meaning the system itself needs to implement it, you can't bolt it on with packages or services
load more comments
(7 replies)
Thanks, Ironclad and Gloire look interesting for a RISC-V system, gonna try out at some point alongside CheriBSD
Oh dang!
I just posted
The Ironclad kernel intrigues
before reading other replies, presuming no one else would have mentioned it.
Well done Jay. :)
[Edit: Oh, I just got down to the PS in the original article. Heh. Ironclad mentioned there too. XD Good to see I'm not the one raising it first.]
Another step up is the confidential computing project. Requires hardware that supports it though, which sucks, but takes the virtual hardware concept and adds multi key memory encryption on top.
Remember though security without a threat model is just paranoia, so what level of hoops and investment you need really depends on what your threats actually look like.
I personally love containers and Macsec. It limits most of my concerns. I want to mess with confidential containers next, which is to say lightweight VMs in containers with memory encryption set, but thats all future to me. The irony is that I then I have to figure out attestation better for those machines since from the host they are black boxes.
The Ironclad kernel intrigues.
view more: next ›