excellent writeup with some high quality referencing.

Thank you!

though i’m not sure it’s fair to say FF is insecure if we are by comparison inferring Chromium is secure?

The whole debate is a mess, so at some point you have to pick a camp of thinking and stick to it. I tried to clear this up before, but failed:

• https://lemmy.ml/post/21367269
• https://lemmy.ml/post/21887275

does this read like coreboot is proprietary? isn’t it GPL2? i might’ve misunderstood something.

Good question! I should have clarified. Libreboot removes proprietary drivers, firmware, and other code from coreboot in favor of their open source counterparts (where available). Some of that code is used to keep the system secure, even if it is proprietary, so Libreboot favors open source over security.

there is still an implicit arms race where privacy corroding features might be implemented at various layers vs the inevitably less resourced team trying to counter them.

is there some additional semi-blind ‘faith’ we’re also employing where we are probably assuming the corporate entity currently has little financial incentive in undermining the opensource base project because they can simply bolt on whatever nastiness they want downstream?

Most Google BS is simply not included in AOSP at all, and is instead added to their own proprietary Pixel OS (based on AOSP). For the invasive bits that are included, it’s easy enough for GrapheneOS to look over the incremental updates in Android and remove the bits that they don’t like.

and now I see that this person is flaunting the fact that they can ban people for whatever they consider “misrepresentation”?

Do check out this amusing post. The GrapheneOS team has a long history of being kind of a dick. It sucks, but there’s no alternative mobile OS as secure, so it’s currently a necessary evil. I even talk about the community in this post. They are seldom open minded, which is a trap many people who share their ideas fall into. I recognized this early on, so I choose to adopt their ideas but keep an open mind and open heart about other differing ideas (as best I can).

I was debating making a part 2 to this post, because one topic I wanted to talk about is Briar. Briar is a messaging app with the ability to work offline over Bluetooth. I don’t think it’s as secure as Signal or SimpleX Chat, but I recognize that there is a proper use case for it.

I once opened an issue on GrapheneOS’s issue tracker, asking for a way to install GrapheneOS offline from another GrapheneOS device. Tails and Briar both include that functionality. GrapheneOS completely deleted the issue (not just closed, but fully deleted) and (after an extreme amount of prying) I was able to find out that they removed it because they don’t want to endorse Briar in any way.

You can actually check how many issues GrapheneOS has deleted by adding up the number of open issues/PRs (currently 725) to the number of closed issues/PRs (currently 3,941) which currently adds to 4,666. Subtract that number from the number of the latest issue/PR (currently #5708) and you get 1,042 deleted issues (~18.26%).

That might sound like a lot, but I measured the percentage of deleted issues from other big repos, and it’s about standard.

I hope that the GrapheneOS community will recognize the dangers of centralizing all moderation power to somebody who seems so self-righteous.

Me too. I do think there is a place for strict perfectionism in the context of security, but there are better ways to go about it. Not everyone on the GrapheneOS team is as bad, thankfully. Most people in the GrapheneOS community are quite nice and welcoming.

That’s fair. I have nothing else to say. Thank you for this discussion!

The system you linked is a WiFi 5 system. That’s 10+ year old technology.

I feel old… First adopted in 2013

Outside of the US nobody uses SMS or the built in text apps.

Which is for the best, since SMS is insecure.

it’s just a weird thing to wrap my head around that Android would be the most secure option.

An easy way to imagine it is that all apps on Android have permission control. That’s only available on Linux through Flatpaks, but Flatpaks have issues of their own.

Another issue is that for what I’m doing I need to rent VPSes and there you’re already quite limited as to what you can run on them, probably Android wouldn’t be an option right?

Probably not, at least not yet. Android runs on a specific instruction set (ARM chips), so you’ll find it difficult finding a place that hosts those. It’s a growing standard, though. Even then, proper security on Android relies on GrapheneOS, which itself only runs on Pixel devices (for now).

And let’s say I want to deploy some apps there would this work on Android out of the box?

With the Linux terminal added to Android, technically yes. However, it’s still quite experimental, and you’ll need to do some specific configuration to get it working properly.

I know it’s Linux under the hood I’m just not really deep into the more advanced Linux stuff tbh.

No worries! Do check out this post where people share things they have hosted on Android. It’s mostly hosted from the Termux app, rather than the new terminal.

If you want to host a server securely and with at least some documentation, do try Qubes OS or securecore (made by secureblue).

Hello there!

It’s nice to see some constructive discussions going on, thank you for that!

First off, most recommendations for Debian are recommending it for use on the server.

Madaiden’s Insecurities admits that Linux is more secure when run on a server for various reasons, so I didn’t really focus on the server side of things. I’ll talk more about this in a bit. I do think Debian is better suited for a server rather than a desktop, but I see Debian recommended countless times for desktop use as well.

But for the server, after having used both Debian and Fedora CoreOS

Nice to see someone who has experienced both!

I trust Debian more in terms of security and stability. For example, last summer when there was a major OpenSSH vulnerability, Debian had already patched it, because the security researchers had notified the Debian maintainers prior to the announcement. CoreOS on the other hand, took multiple weeks to release the fix.

secureblue includes modified images of CoreOS called securecore. While this doesn’t fix the issue you described, it is worth mentioning as a (technically) more secure option than both Debian and CoreOS. Qubes OS can also be run as a server, and that’s what Let’s Encrypt uses for their servers.

I can’t speak in terms of stability, since the most I’ve done is a couple Docker containers on a Raspberry Pi.

As for the topic of F-Droid, you brought up the PrivSec article on F-droid security issues. This article is a few years old and is always brought up in criticisms against F-Droid.

This was actually my first time doing proper research on the F-Droid insecurity issues, so I went with the sources I thought were most credible. Privacy Guides also recommends against using F-Droid’s main client in some cases.

F-Droid has had issues with certificate pinning, and this whole thread has a lot of things against F-Droid.

It’s a deep rabbit hole that I don’t quite want to spend time digging through.

(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.