Mods. Please remove this if it is inappropriate…
I just published the inital draft/ release of a work-in-progress guide on building a secure, privacy-focused desktop. Open-source, evolving, and free to use (Arch / EOS based).
Because the tutorial/ document is evolving and several pages long I have it here (if you wish to use it on EOS wiki or elsewhere, feel free.
this ^ is correct. with the colon at the end in your post it goes to a 404
I woulda preferred 2 or more additional sentences of context, for each bullet point, in the " BIOS & Disk-Level Security" which is a great section. You know ‘whys’ and ‘becauses’ type info.
Pretty cool overall.
So some things ..
It will probably be important to expand on this as
It would probably also make sense to have some tidbits on bootloader and its config, regardless of any secure boot expansion.
At least as pertains to services .. what would be the difference between ‘active’ and ‘enabled’ ?
What does this mean?
Is hblock never run?
Is hblock.timer not enabled?
(I dont use the timer either .. but I run hblock myself pretty reliably)
I know this is still a draft, but these were some of my thoughts nonetheless.
Good luck on your future progress.
Thank you for the comments. I have been working on a bunch of materials all eos/arch based. Here are two pages with a lot of additions. About 6 pages are brand new. The cybersecurity page is my attempt at making dozens of pages of security related materials, tutorials more accessible. It’s all free and worth every penny!
https://eirenicon.org/resilient-desktop/ (check the links on this page they go to tool implementation guidance).
This next link is to the cybersecurity group of posts-tutorials (16 of them)
Feel free to use the materials, edit them for your own application… whatever.
You’ll also see more of what I’m working on hinted at on the cybersecurity page. If anyone is interested in placing requests, posers, whatever, I am happy to help if I am able. I can try doing that here or (my preferred approach is to build answers into tutorials for everyone to use).
I think you should remove USBGuard from the list. The reasoning is the team supporting USBGuard is not responding to any of the bugs for almost a year.
Just read through the numerous issues where the development team is not engaging on issues where USBGuard is locking out devices which have allow rules setup.
My issue after many years of using USBGuard:
I believe we should take measures like firejail for sanboxing, UFW, fail2ban and Opensnitch to enhance security. But when I see projects being irresponsible, then something like USBGuard is likely to frustrate people into any kind of hardening (because of system stability).
Thats my 2 cents on the matter.
It certainly seems like your is a reasonable position to hold. I was not aware of the lack of support. I’ll research to see if there are other options. 
I did raise an issue with the Arch Package manager over what was going on. But they were not able to take any action. As long as the USBGuard project makes minor changes and checks in new code, then they stay in the Arch Repository.
This is also why I take the position to reduce your attack surface and only install what you need. I’m not confident in Arch being able to catch malicious code. Instead it is the curious Security Researchers who we should partner with.
I’ll try to get you a stupid simple optional replacement approach tomorrow sometime. Basically it is USB Polling: A Viable “Old School” approach (I’m old)
It would not be a robust as USBGuard but it will let you know when an un-approved USB is connecting to your system so you can attack them with a large stick… Just sayin’
FWIW… I going to try interuppt not polling as the way to discover unwanted access. I’m not going to inventory devices if I don’t have to. I’m going to allow the logged in user obtain usb use rights without a lot of fuss/ muss. I’ll forgo worrying about the situation where an evil usb user is holding a gun to my head. It’s early days… but I don’t want anything resource consumptive.
Do let us know how you implemented the polling to discover unwanted access for USB devices.
My actual needs end up being very simple. I did look into the polling and the solution seemed quite difficult beyond these two ultra painless solutions. One is to run udiskie (install and start it). Here’s what I use on dwm:
udiskie --smart-tray --automount --notify &
Here’s what I use on i3
exec --no-startup-id udiskie --smart-tray --automount --notify &
I found that for xfce4 (I assume other DEs as well…) can be done:
Create a new udev rule:
Open a terminal and run sudo nano /etc/udev/rules.d/99-usb-notification.rules (or use your preferred text editor).
Add the following line to the file:
ACTION=="add", RUN+="/usr/bin/notify-send 'USB Device Connected' 'A USB device has been connected to your system.'"
Save and close the file.
Reload udev rules:
Run sudo udevadm control --reload-rules to apply the new rule.
Test the setup:
Plug in a USB device. You should receive a desktop notification indicating that a USB device has been connected.
All I need is a screen flash notifying me of plugin or removal. Since I’m sitting at my machine whenever there’s a usb disk being plugged in or dismounted, that simple process works for me. If my machine is off, then my system front doors are locked, pretty tightly.
I should mention that my research uncovered a couple of apps that are still maintained. Perhaps for those with more sophisticated needs one will fit.
[Moderators] If you feel there might be broader use (or NO use) for this material… do with it whatever you think best.
For those following my work on an EOS/ Arch resilient desktop (laptop) I have published a significant amount of new material. Among other things I have updated all the tasks on this page and provided direct links to my initial release of secure scripts. All the scripts are copy-left licensed and developed in combination with AI (my skill level would never be able to produce scripts of this level). I will continue enhancing the scripts and making them more robust (as I am able).
If you just want a link to the scripts without reading the attendant update tutorial materials, here’s the script Dropbox folder. I hope it works for someone other than me. 
Over the next month or two, I plan to set up my system to use Btrfs functions more thoroughly. As I do that, I will re-write all the scripts to take advantage of those features and arch’s capabilities in he ‘secure’ realm.
This is really interesting and valuable.
Thank you
Just to be clear - I quoted that from the linked page in order to discuss the contents.
For myself I dont use the majority of items listed there and I am not sure I would suggest them all, even for an extra ‘secure’ setup.
For example - I do not use ufw and if I did I would not need GUFW, fail2ban is more useful in something like a server environment where you would be accepting incoming connections, and I have no familiarity with brevo at all (is an SMTP service even relevant for security?).
TBH I am on the fence about using smtp services routinely.
In my materials I am attempting to provide approaches and that are known to have application in various security use-cases (irrespective of whether they fit mine). In other words, I’m trying to be reasonably thorough. Where an smtp server fits the security paradigm, in my experience is when security settings become very stringent and sent email is treated by receiving email systems such as gmail- and email is no longer being received. That has happened to me. When that happens the secure (now treated as spam) user can insert a neutral, known reputable, smtp server as their ‘sender’ thus masking the source which was earlier treated as bad incoming mail (by the receiving server).
Does everyone need to do that… probably not. But then there are quite a few things folks may not wish to do. Truthfully, my paranoia may be simply higher than yours. 
Fort hose who were seeking alternative USB security approaches, I have come across one that may be of value to some??? Here’s the direct link.
404: Page Not Found. Please adjust the correct link in your 1st post.