I am new to Fedora. I recently tried out a couple of atomic Fedora versions, as well as other companies versions. However I can not seem to be able to locate/install additional software, such as usbguard, fail2ban, etc, that are not readily in the Appimage/Flatpak/Snap gui PM’s in these atomic versions. All the documentation I have poured over so far about atomic/immutable distributions mentioned that they “only” use Appimages and Flatpaks/Snaps for packages. So if they are not in those repos from the graphical PM side, is it some compile cli side repo that must be aquired?? And if not, are these distros more vulnerable to attack by Bad USB/Wi-Bad USB?
P.S. I Have heard of a workaround with installing via distrobox, however that does not seem as though it is a solution for software that requires a certain level of permanence on the system such as Usbguard and Fail2ban.
You can install RPM packages via “Package Layering”:
2 Likes
Ty for the info. This does look like a solution, however I am apprehensive given the last line
In the documentation stating that this approach
Is generally not recommended. I realize this is probably a stop gap measure until software gets repo’d into Flatpak, Appimage, etc. But Ty for the info. I will have to pour over the info to know how to remove it in case there’s trouble.
I’m a newbie myself, but to my understanding, software that needs system level access still needs to be layered. Flatpaks and Appimages aren’t great for those purposes. Similar system level software such as those related to VPNs or virtualization also need to be layered.
If you’re interested in USBGuard, I have bad news for you. The issue there, sadly has to do with Gnome supported distros.
1 Like
Actually I posted a question on that very issue. Apparently there is a collaborative solution needed between Gnome devs and os devs(and perhaps others), to fix that in Gnome de’s. Hopefully this is not systemic to other De’s as well. Now that bad usb is easily WiFi’d on Arduino chips, remote attacks can happen easily, remotely and with little knowledge about how
It works and is implemented. The need for apps like this to work is paramount to mitigate
an issue USB chip devs should have solved long ago but “overlooked”, or worse perhaps for gvmnt agencies. (Ie. intended to proliferate).
I understand your confusion. I also agree that Fedoras Atomic Desktops are less user friendly than they could be.
Some things cannot be achieved possibly for legal reasons, even though I am unsure if specific cases (like “can we preinstall Flathub” were really tested).
Being specific
At the start: all these atomic distros are different, so generalizations dont help.
Fedora Atomic Desktops are specific:
- the core system is very minimal
- the system composes/images are the same but include different desktops
- normally, rpm-ostree is just used for updating and version upgrading, the latter is done by rebasing
- apps are installed as Flatpaks.
- The Fedora Flatpak remote, with a small set of apps packaged from RPMs.
- The advantage: a single runtime. The apps are the same you would install as RPMs, but in a different format. So you have no additional trust.
- The disadvantage: There are very few apps, so you would add Flathub, the main source of Flatpaks, anyways. So you now have Flathub Flatpak runtimes, and the single Fedora Flatpak runtime. That may be one too much for you, I remove the Fedora Flatpak remote
flatpak remote-delete fedora
- Flathub, which can be added in the “3rd party sources” setup dialog and can be added in the GUI stores
- The Fedora Flatpak remote, with a small set of apps packaged from RPMs.
- RPM packages can still be installed! But the method is quite complex, but I am against not recommending it. The only problem is slower updates and maybe the need to remove a package before an upgrade. NOTHING compared to the risk of installing packages on traditional distros
- appimages are not recommended. There is no store preinstalled (and if you want one, use “AppMan” which is the only good one it seems)
- Snaps dont work on Fedora Atomic Desktops and are generally not more secure than system packages, outside of distros using “Apparmor” for their security. Fedora uses “SELinux” which is a different method also used in Android, and Snaps are only isolated with Apparmor. Flatpaks are simply better here.
GUI Stores
So, the GUI stores show apps available in the repos.
Normally they also show system packages. This is done via “packagekit”, an abstraction for various package managers like APT (Debian, Ubuntu), DNF (Fedora, RHEL), zypper (OpenSUSE), pacman (Arch)…
Packagekit
Packagekit is an abstraction, meaning a GUI store says “install GIMP” and Packagekit tells the used package manager “dnf install GIMP”, roughly speaking.
On Atomic Desktops, the GUI stores dont use Packagekit. But rpm-ostree is not used only for updating, but can be used to layer apps onto the system.
There simply is no GUI store integration for installing apps. I think there was one, but the UX (user experience) is quite bad. (It is better to install all wanted packages at once, otherwise the process explained below is repeated for every package)
rpm-ostree
You can imagine that your system works like 2 or more CD-ROMs.
The CD is inserted into the PC, and you boot from it. During boot, you cannot write to it, only read. It is read-only.
If you do an update: you insert an empty CD into the PC. You write the contents of the current one to the empty one. But that would be a copy. So instead, the system ostree knows which packages changed between the current, and the new system. So instead, you write the current system to the empty CD plus the changes that ostree tells you happened.
Now you have 2 CDs, one that you are using, read-only, and one other, that you are not using, that you can write to and that has the new system.
At the end, the new CD is set as the next boot target so if you reboot, you will boot into that, automatically.
rpm-ostree rpm installs
Now if you want to install a package what happens is:
- you create an empty CD (a new deployment)
- you clone the current (read only) system to this CD
- you also download the RPM and use DNF to resolve the dependencies, so you download the dependencies too. For example a program, and a library that the program needs. Both are downloaded and added to the cloned system
- the process finishes, your system is unchanged but you have a copy PLUS the added packages on the new system
- you reboot to use the cloned system plus the added packages
Instead of CDs it uses deployments and you also dont have everything doubled due to the magic of BTRFS deduplication. But this visualization helps a lot.
So what happens if you add a package, is that the base image, where ostree compares “what has changed and what not” is cloned on every update. PLUS you also download that package on every update, and always add it new to the new system.
I dont know if this is also done local, but I imagine this means higher network usage. Only if it is not local.
But it also means that this is done from now on on every update. So the process is slower.
installing rpms is safe!
But it also means that even though you add packages, the ostree image is never changed. It is always a transparent change you add, and rpm-ostree reset will revert all these changes and you are 100% vanilla again.
This is only possible with rpm-ostree
So: installing packages is slower, but it is way safer! It can always be reverted.
a perfect copy
The reason why people recommend against it, is because a huge advantage of atomic desktops is that your system is a 100% (bit by bit) copy of the image Fedora ships. “That issue does not happen on my machine” should never happen again.
If you change that, it is not true anymore. BUT a single rpm-ostree reset brings you back to that state. This is unique.
So I highly disagree. Installing as many RPMs as you like on atomic desktops is perfectly fine. Do whatever you want. A single reset brings you back, absolutely no problem.
traditional systems are messy
People recommending against installing RPMs here, should scream if you install an RPM on traditional Fedora Workstation. Because there, there is no reset. All you can do is hope, that dnf manages to not break the system. It is extremely chaotic.
And yes, usbguard and fail2ban need to be installed with rpm-ostree
rpm-ostree install usbguard fail2ban
other cool commands
Then you can do
rpm-ostree status
And have a look. Pure transparency. This is the future
rpm-ostree update --install fail2ban --install usbguard
If you want to save time
sudo ostree admin pin 0
If you want to keep the current image forever, as a save haven, a working backup
rpm-ostree cleanup --rollback
To remove such backups, if your system works perfectly. This is not needed! You always have 1 backup system, anything older is automatically removed.
rpm-ostree rebase xxxx
Change the ostree remote that your local system mirrors. From now on, you follow a different system. This will convert your system to be bit-by-bit the other system, however different they may be.
It could even replace every single package, no problem.
rpm-ostree override remove package-x
Can be used to uninstall stuff you dont want. Not generally needed that much.
That was a lot, but I hope it helps. Cheers!
2 Likes
Added atomic-desktops, docs, rpm-ostree and removed flatpak
Feel free to change tags and title 
I agree that it should have been fixed long ago and also saw a thread reaching the same conclusion of it requiring a inter-organization effort. In a sense though, this kind of seems relevant to the whole Atomic desktops concept as well. As the post above explained, they are trying to solve a problem that is long overdue. The fact that rpm-ostree is not yet as inviting as it could have been, just like USB Guard, shouldn’t distract from it also being an effort for a better overall implementation.
I can happily say that us security conscious folk seem to be over-represented here so if you stick around, at least you’ll be among good company 
Thank you for the breakdown on that, boredsquirrel !! Some of this I do understand, as I have lived through the era Before Linux when Windows users were using early hypervisors to stay safe there Virtual Box, etc.
Now I realize this isn’t the same, but as I understand it actually better due to less resources used.
And this actually seems to solve the issues of
Verifying ISO’s online, as per your quote,
For that it seems brilliant. I am coming from the
early days of Linux Mint when they had that malware breach on their servers hosting their ISO’s.
I also like the idea of the core root file system as untouched and if there happens to be a malicious Flatpak somewhere in the future, it would not seem as big an issue both for the infected system, which really it would not infect
The system, and for the app itself as the app devs could rollback to an older version without much downtime and fix the issue without as much pressure to find an answer quickly. The rollback feature would also actually work instead of traditional apps like timeshift that, if infected at the time, could corrupt any backups you made. So yeah, that’s a pretty BIG deal if there are no bugs that put a weakness in that armor.
But it still is a big part of a larger whole. Other apps like usbguard are important for now, because we are talking about immutable OS’s.”,
And Not immutable Mother Boards. However I think that for UEFI and Motherboard firmware,
Immutability would work here as well ?? So yeah, this Could send a lot of bad actors looking
for a new vice, hopefully.
Atomic desktops suffer from the need of layering packages, because basic packages are not added to the images. For example a lot of CLI tools are consistently rejected.
Well maybe in the future, someone will figure out a new way of restructuring this system so things work more seamlessly. (Maybe a hybrid system of some sort).
No, before installing you should always verify the ISO. If you use HTTPS, we can argue that is not important.
These chains of trust always start at one “super block” or origin. If the ISO is manipulated, it could have programmed in to mirror the wrong OSTree remote, or include bad packages.
On the “perfect copy”: as I said you can have that by resetting, you dont need to not touch anything.
Also note: rpm-ostree does not improve security a lot.
Actually, in my pretty harsh Change Proposal, which we changed to focus on the fancy "unprivileged updates" part, we fixed a pretty big security issue.
Currently on F40, anyone can install random packages without a password. And “because Fedora does it like that” this is also still the case om F41, but restricted to repo packages which is probably fine.
Also, most of the important stuff is in your home directory. Code can run from anywhere.
Really, an immutable core doesnt protect against malware.
Yes indeed, the ostree remote could change that package and it wouldnt need to be fake-updated like with xz.
Only because there is traditional Fedora, the atomic desktops got this fake upgrade. Otherwise I guess they wouldnt need it. Good point!
I have not used timeshift. 2 things here:
- The critical part here is the bootloader and ostree. If one breaks, you also lose the ability to rollback. I had a broken GRUB once, not fun.
- Timeshift, as well as tons of other models like VanillaOS, OpenSUSE microOS etc. are all worse, because you just have atomic updates, and no reset capability and no image. This means you can never get back to the vanilla image, without also reverting upgrades. You could save the image after install, but that means you fallback tons of versions and can break stuff. On Fedora, a reset can reset AND upgrade your system, to 100% the upstream one!
Lol if your hardware devices are unchangeable, that would make USB pretty useless XD
If you mean firmware then yes. Firmware is normally read-only so immutable.
If you mean atomic, if the chips are big enough, one could store older versions of the firmware and follow the same upgrade principle, but that us not done anywhere afaik.
If you mean image-based / ostree-based (actually 2 different things, an ostree remote is like a git remote), this is done I think? But it may not be updated incrementally.
As far as motherboards go, I was simply stating that immutable, read only updates could prevent malware from altering the code there.
(Of course that isn’t to say malware can’t flash it and substitute its jaded version).
And I did not know Vanilla worked that way, without “baking in” the rollback functionality. Cool to see you devs are so forward (or backward) thinking. Us users only get the “eye candy” screenshots and features the OS devs want to emphasize.
But motherboard malware needs to be addressed as well, whether that’s usb ports or
CPU’s, etc. In the old days this was not even an issue due to ROM chips. But since we were wasting so much silicon the practice was abandoned. Too bad there isn’t a hardware/software solution to this yet.
3mdeb Dasharo coreboot is actually immutable, you need to manually set it into update mode.
Fun fact: the integrated fwupdmgr does not work here, as the firmware is not writable.
Have a look here. I think there are solutions but not sure about everything you said