(I say as I set up my media center)

I’m getting flashbacks… If you feel like living on the dangerous side, don’t be afraid to bork all your security and chmod -R 777 /!

(This is a joke. Don’t actually run that)

I’m just curious what exactly makes the Fedora and secureblue distros more difficult to understand how far I am from running a secure distro.

Bleeding edge distros (especially Fedora Atomic distros and especially especially secureblue) tend to have less documentation and less people available to help. secureblue is currently so obscure that the best way to get help is by using their Discord or contacting the developers directly. This makes it difficult for users using Linux for the first time to fix basic issues that arise simply from never using Linux before.

As I mentioned in my post, Linux is fundamentally insecure. secureblue is almost as secure as Linux gets, but it’s only a couple steps away from desktop Android, so I would just opt for that if you can. Fedora and (especially) Fedora Atomic are bleeding edge, meaning they adopt newer, more secure software sooner, making them more modern, up to date, and secure than other distros.

I oversimplified things a bit here, so let me know if you have any other questions!

I will never by a portable device without a headphone jack

You can get 3.5 mm to USB-C adapters for relatively cheap, or buy direct USB-C wired headphones. GrapheneOS allows you to restrict the permissions of the USB-C port to your needs. Alternatively, just use wireless earbuds, if you don’t care about the security issues with Bluetooth. GrapheneOS also includes automatically disabling Bluetooth after a timeout when it’s not in use.

In my opinion, the security benefits of GrapheneOS far outweigh the need for a 3.5 mm headphone jack.

Instead I am currently trying out Sailfish OS on a Xperia 10 to use Linux

Linux phones are wildly insecure.

Thank you!

I saw your comment before you edited it, saying you hadn’t heard of Trivalent before. Trivalent is a browser developed by secureblue, and is the main browser for that OS. It was renamed a while back from hardened-chromium. It’s not easy to install on systems other than secureblue, but it is possible.

I bounced back to Mint a few times before. I didn’t like Cinnamon at the time, especially because you could accidentally end up making your system look like Windows 7, but Cinnamon had a redesign months back, so (even though I haven’t tried the redesign) I’m confident that Mint is a good suggestion for beginners.

Hey, thanks for this!

However I would like to say that you may have either oversimplified or misunderstood some concepts you talk about here.

Mostly oversimplification. However, I don’t know everything and do make mistakes like everyone else.

Debian is indeed less secure than a stable release Linux distribution based on sane defaults, however they do backport security issues into their older kernel which is how older kernels are maintained. So while yes, they may still use kernel 6.1, they also may have backported 6.12 vulnerability fixes.

I acknowledged this in this comment.

Groups being at odds is not all good and neither is it all bad.

This is true, but there needs to be more constructive discourse rather than directly attacking different viewpoints. People who say they use Brave on Lemmy often get lynched pretty quickly, for example.

For a beginner distro, definitely don’t use secureblue. While it is user friendly to use, it’s pretty difficult to install properly and requires a bit of knowledge about Linux to do so.

The ideal roadmap I would give to people trying out Linux for the first time would be this:

If you use MacOS: Buy a new laptop and install Ubuntu

If you use Windows 11: Install Kubuntu. Get used to using Linux using that, and, when you’re ready, transition to Ubuntu

If you use Windows 10: Install Linux Mint. Get used to using Linux using that, and, when you’re ready, install Kubuntu. Get used to using that, then, when you’re ready again, transition to Ubuntu.

After you’ve gotten used to Ubuntu and feel ready, install Fedora Workstation.

Once you are used to a Fedora-based distro, you can try out Fedora Silverblue.

After learning Fedora Atomic, you can rebase to secureblue without issue.

(Windows 10 -> ) Linux Mint -> (Windows 11 -> ) Kubuntu -> (MacOS -> ) Ubuntu -> Fedora Workstation -> Fedora Silverblue -> secureblue

It should give you a well rounded knowledge of Linux and an easy, slow transition to more secure distros. Really the important thing when starting with Linux is using a desktop environment that is most familiar to what you already are used to. Desktop environments are the “looks” of Linux.

• Linux Mint uses Cinnamon as a desktop environment, which looks most similar to Windows 10
• Kubuntu uses KDE Plasma as a desktop environment, which looks most similar to Windows 11
• Ubuntu and all the rest use GNOME as a desktop environment, which looks most similar to MacOS

Each transition in the roadmap teaches you something new about Linux to get used to.

Good luck!

Honestly I’m just not sure about Debian being insecure take

Besides Linux being fundamentally insecure (as I mentioned early on in my post), Debian focuses on stability by providing a set of software that is thoroughly tested but does not change for years. While they do provide security fixes for a lot of software, the reality is that using outdated software in any capacity is a security risk of its own, and is bound to provide bugs that harm stability. Comparing Debian to bleeding-edge distros like Fedora, which focuses on security, it’s clear the differences in security between them.

Thanks Very informative

Thank you!

I agree with almost all your takes here

I’m open to discussion, if you want to!

Not so new browser controls let you block all advertisers forever

If someone observed you entering your ring 0 passphrase and stole your backup of ring 0 or ring 0 itself, the database becomes vulnerable. For that reason, it is a good idea to encrypt your database using a different passphrase than ring 0, and/or mitigate the risk of someone having the ability to see you type your ring 0 passphrase.

Storing the ring 0 passphrase on a hardware security key as I mentioned in the previous reply allows you to automatically type your ring 0 passphrase without the need to remember it or risk being seen typing it in. Another way to mitigate this attack would be enabling biometrics on your ring 0 device. However, that doesn’t protect seeing you type the passphrase in a BFU state.

This is the method I’ve come up with:

I have a hardware security key (let’s call it hsk 0). It is configured to store the passphrase for my airgapped GrapheneOS phone (my ring 0 device). ring 0 has biometrics enabled. This means hsk 0 is only used to unlock ring 0 in the BFU state, and can be kept in the safe otherwise. A second factor PIN can be applied to ring 0, and a copy stored in the safe. In general, the second factor PIN will be used often enough to memorize. My ring 0 has a KeePassDX database (db 0), and Aegis for TOTP (I want to avoid the mixup of saying 2FA when I am referring to TOTP). db 0 is protected using a memorized passphrase, and also has biometrics enabled. I found that storing the db 0 passphrase using any other medium introduces too many risks and vulnerabilities. Inside db 0 is the duress passphrase for ring 0, as well as all device credentials for ring 1 devices. The Aegis app will store TOTP for all accounts. An unencrypted backup of the phone will be made and stored in the safe.

Let’s pause here and recap what would need to happen in order to obtain a ring 1 passphrase:

1. An attacker would need either the phone or a backup of it
2. If the attacker has the phone in a BFU state, the attacker would need hsk 0 stored in your safe to unlock it
3. If the attacker has the phone in an AFU state, the attacker would need your fingerprint as well as the second factor PIN you have memorized or a copy of it in your safe
4. Once the attacker unlocks the phone, or if the attacker only has a backup of the phone, the attacker would need the passphrase only you know in order to unlock the database.

It’s important the safe isn’t stored in your home, but rather something like a safety deposit box, that way you aren’t alone near the safe at any time.

The passphrase for Aegis is stored in db 0, and biometrics can be enabled if you want. Each ring 1 device contains an independent KeePassXC database each, that way if a device is remotely compromised while the database is unlocked the damage is minimal. An encrypted backup server is one of the ring 1 devices, which keeps all other ring 1 devices automatically backed up. All accounts are protected via 2FA (whether it’s another hardware security key (hsk 1) or TOTP). 2FA recovery codes are stored in a safe separate from our ring 0 backup. That means TOTP follows the 3-2-1 backup method (1 copy on ring 0, 1 backup in a safe offsite, and 2FA recovery codes kept somewhere else. 3 different storage mediums)

Now, what an attacker would have to do to break into an account:

1. Compromise the device hosting the KeePassXC database storing the account
2. Compromise the KeePassXC database
3. If the account is protected by TOTP: either compromise ring 0 and compromise Aegis, or find the backup of ring 0 and compromise Aegis, or find the 2FA recovery codes
4. If the account is protected by a hardware security key: Find hsk 1 (or a backup of it)

Some hardware security keys allow entering a PIN before successful authentication. One of those is good as your “main” hsk 1, and the PIN can be stored in db 0 in case you forget (forcing the attacker to also need to compromise ring 0 to use hsk 1).

I’m a bit tired while writing this, so please point out any obvious flaws. Here is a summary:

1. A hardware security key hsk 0 stores the passphrase for ring 0
2. hsk 0 is stored in a safe (safe 0) when not in use, and a backup can be stored in another safe (safe 1)
3. ring 0 has biometrics enabled, as well as a second factor PIN
4. The second factor PIN is both memorized and a copy stored in safe 0
5. You have the passphrase for ring 0’s KeePassDX database (db 0) stored in memory
6. db 0 has biometrics enabled
7. Aegis is installed on ring 0 to store all TOTP codes
8. A backup of ring 0 is stored in safe 0
9. db 0 stores the credentials for all ring 1 devices
10. One ring 1 device is used as an encrypted backup server for all other ring 1 devices
11. Each ring 1 device has their own independent KeePassXC databases (db 1)
12. All accounts are either protected with another hardware security key (hsk 1) or TOTP.
13. 2FA recovery codes are stored in safe 1
14. A copy of hsk 1 is kept in safe 0

There must be a “root” piece of information that unlocks all the rest.

One of the first diagrams I made when I was trying to sort this out months ago came to this conclusion. I identified 4 media that can be used to store the “root” passphrase:

1. Memory
2. Pencil and paper (or some other physical engraving)
3. An unencrypted digital storage device
4. A hardware security slot (you can configure a YubiKey to automatically type a specific password when tapped)

The last option is most appealing to me, since it doesn’t rely on memory and it’s more accessible than a USB stick, for example.

For my personal setup, I only need to update the ring 0 database when I buy a new ring 1 device, which is like once a year at most.

This is fair.

I don’t see a way around this, aside from the Qubes solution mentioned in my post.

Obviously store all your passwords on a sticky note taped to your monitor! /s

It’s unfortunate that security costs so much money. Hardware security keys are expensive, and nobody has made that ring 0 device I talked about.

If the root key is air-gapped device or virtual machine (like the Qubes password vault), then it is already 2FA.

By 2FA recovery codes, I was referring to things like this. I worded my question weird, so I apologize. Account recovery files are common, whether it’s a mnemonic seed or those 2FA recovery codes I was referring to. Those shouldn’t be stored on the same device as the password manager protecting those same accounts, so there’s no clear place to store it. You did answer my question later on, but I wanted to clarify.

As mentioned in my post, the database has the same password as the phone.

I’ll comment about this later

The duress passphrase can be stored in the ring 0 device as well, as long as you periodically revisit it to refresh your memory.

I’ll give a fun solution for this later, too.

Stopgap

I had a draft if a system, but I need more time to flesh it out. The issue with the database having the same password as the phone is that there’s only one form of authentication protecting the ring 1 credentials in that case (something you know). We have the ability here to protect it with multiple forms, and I will incorporate that into my system once I’m finished. I spoke too soon. ring 0 or db 0 is something you have, which is the second factor, as you mentioned.

As for the fun duress passphrase solution, you could put a sticky note somewhere that is essentially “PHONE PASSWORD: [duress passphrase]” to throw an attacker off and make them accidentally enter it. There’s a lot of fun and creativity to be had here. In any case, it means you don’t have to remember the duress passphrase, just where it is. “I don’t memorize the password to my phone, I store it in that safe over there.” etc.

Feel free to reply to this message, and I’ll have a working system for you (probably) in the next one.

I remember going through this chain of thought myself a few years back

I, too, went through your chain of thought with the “rings of devices”. My main problems were:

1. Remembering the passphrase for the ring 0 device is risky at best, especially with an added duress passphrase and second factor PIN (if applicable)
2. Keeping the database automatically backed up seemed impossible
3. The added expense and inconvenience of buying and carrying a separate phone was an issue
4. Storing other information such as the duress passphrase or the unlock method for the database had no clear solution

How do you unlock your database? Is it a passphrase, key file, or security key?

In my chain of thought, this is what I came up with:

My “ring 0” device stores device credentials (BIOS passwords, encryption passphrases, database passphrases, etc. for my laptop, desktop, backup server, phone, and any other devices). Each of those devices has their own KeePassXC database separated from each other. Those databases store the accounts used for that device only (e.g. I only access Lemmy from my desktop, so it gets stored in the desktop database and nowhere else). Those devices and their databases are backed up to the backup server. Ideally this server would be selfhosted, but it’s understandable if it isn’t.

That system is simple and elegant, but it isn’t without issues. Besides the issues listed above, there’s no clear way to use 2FA. If the “ring 0” device also has all 2FA codes, that means remembering another passphrase. Where are 2FA recovery codes and other backup methods stored? Likely this would be on the backup server, but offline solutions such as paper and a safe would work too. Where do security keys end up in the mix? What if a KeePassXC database is protected by a key file? Where do you store that?

In the end, it’s close to a good solution, but there’s unanswered questions. I even started theorizing of a dedicated device manufactured specifically to act as a “ring 0” device, to reduce attack surface. I had to ground myself and make sure I was only thinking about currently available technology.

I’d love your thoughts. It’s refreshing to know someone else followed the exact same line of thinking as me.

I will continue to use Proton and their services, not because I support or endorse any political decisions from the CEO/board members (and I don’t), but because they provide open source, secure, and private software that I love.

This is no different than arguing about using GrapheneOS based on the behavior of the maintainers.