Interesting thoughts about privacy, security, and all the things
I'm making this post to share some interesting less talked about things about privacy, security, and other related topics. This post has no direct goal, it's just an interesting thing to read. Anyways, here we go:
I made a post about secureblue, which is a Linux distro* (I'll talk about the technicality later) designed to be as secure as possible without compromising too much usability. I really like the developers, they're one of the nicest, most responsible developers I've seen. I make a lot of bug reports on a wide variety of projects, so they deserve the recognition.
Anyways, secureblue is a lesser known distro* with a growing community. It's a good contrast to the more well known alternative** Qubes OS, which is not very user friendly at all.
* Neither secureblue, nor Qubes OS are "distros" in the classical sense. secureblue modifies and hardens various Fedora Atomic images. Qubes OS is not a distro either, as they state themselves. It's based on the Xen Hypervisor, and virtualizes different Linux distros on their own.
** Qubes OS and secureblue aren't exactly comparable. They have different goals and deal with security in different ways, just as no threat model can be compared as "better" than any other one. This all is without mentioning secureblue can be run inside of Qubes OS, which is a whole other ballpark.
secureblue has the goal of being the most secure option "for those whose first priority is using Linux, and second priority is security." secureblue "does not claim to be the most secure option available on the desktop." (See here) Many people in my post were confused about that sentence and wondered what the most secure option for desktop is. Qubes OS is one option, however the secureblue team likely had a different option in mind when they wrote that sentence: Android.
secureblue quotes Madaiden's Insecurities on some places of their website. Madaiden's Insecurities holds the view that Linux is fundamentally insecure and praises Android as a much better option. It's a hard pill to swallow, but Madaiden's Insecurities does make valid criticisms about Linux.
However, Madaiden's Insecurities makes no mention of secureblue. Why is that? As it turns out, Madaiden's Insecurities has not been updated in over 3 years. It is still a credible source for some occasions, but some recommendations are outdated.
Many people are strictly anti-Google because of Google's extreme history of privacy violations, however those people end up harming a lot of places of security in the process. The reality is, while Google is terrible with privacy, Google is fantastic with security. As such, many projects such as GrapheneOS use Google-made devices for the operating system. GrapheneOS explains their choice, and makes an important note that it would be willing to support other devices as long as it met their security standards. Currently only Google Pixels do.
For those unfamiliar, GrapheneOS is an open source privacy and security focused custom Android distribution. The Android Open Source Project (AOSP) is an open source project developed by Google. Like the Linux kernel, it provides an open source base for Android, which allows developers to make their own custom distributions of it. GrapheneOS is one such distribution, which "DeGoogles" the device, removing the invasive Google elements of the operating system.
Some Google elements, such as Google Play Services can be optionally installed onto the device in a non-privileged way (see here and here). People may be concerned that Google Pixels can still spy on them at a hardware level even with GrapheneOS installed, but that isn't the case.
With that introduction of secure Android out of the way, let's talk about desktop Android. Android has had a hidden option for Desktop Mode for years now. It's gotten much better since it was first introduced, and with the recent release of Android 15 QPR2, Android has been given a native terminal application that virtualizes Linux distros on the device. GrapheneOS is making vast improvements to the terminal app, and there are many improvements to come.
GrapheneOS will also try to support an upcoming Pixel Laptop from Google, which will run full Android on the desktop. All of these combined means that Android is one of, if not the, most secure option for desktop. Although less usable than some more matured desktop operating systems, it is becoming more and more integrated.
By the way, if you didn't know, Android is based on Linux. It uses the Linux kernel as a base, and builds on top of it. Calling Qubes OS a distro would be like calling Android and Chrome OS distros as well. Just an interesting fact.
So, if Android (or more specifically GrapheneOS) is the most secure option for desktop, what does that mean in the future? If the terminal app is able to virtualize Linux distros, secureblue could be run inside of GrapheneOS. GrapheneOS may start to become a better version of Qubes OS, in some respects, especially with the upcoming App Communication Scopes feature, which further sandboxes apps.
However, there is one bump in the road, which is the potential for Google to be broken up. If that happens, it might put GrapheneOS and a lot of security into a weird place. There might be consequences such as Pixels not being as secure or not supporting alternative Android distributions. Android may suffer some slowdowns or halts in development, possibly putting more work on custom Android distribution maintainers. However, some good may come from it as well. Android may become more open source and less Google invasive. It's going to be interesting to see what happens.
Speaking of Google being broken up, what will happen to Chrome? I largely don't care about what happens to Chrome, but instead what happens to Chromium. Like AOSP, Chromium is an open source browser base developed by Google. Many browsers are based on Chromium, including Brave Browser and Vanadium.
Vanadium is a hardened version of Chromium developed by GrapheneOS. Like what GrapheneOS does to Android, Vanadium removes invasive Google elements from the browser and adds some privacy and security fixes. Many users who run browser fingerprinting tests on Vanadium report it having a nearly unique fingerprint. Vanadium does actually include fingerprint protections (see here and here), but not enough users use it for it to be as noticeable as the Tor Browser. "Vanadium will appear the same as any other Vanadium on the same device model, and we don't support a lot of device models." (see here)
There's currently a battle in the browser space between a few different groups, so mentioning any browser is sure to get you involved in a slap fight. The fights usually arise between these groups:
- The group that is strictly anti-Google and uses Firefox-based browsers
- The security focused group that recognizes that Firefox is insecure and opts for privacy enhanced versions of Chromium
- The political group that only care about the politics behind an organization rather than the code itself (examples: Firefox Terms of Use update, Brave Browser including a crypto wallet)
For that last one, I would like to mention that Firefox rewrote the terms after backlash, and users have the ability to disable bloatware in Brave. Since Brave is open source, it is entirely possible for someone to make a fork of it that removes unwanted elements by default, since Brave is another recommended browser by the GrapheneOS team for security reasons.
Another interesting Chromium-based browser to look at is secureblue's Trivalent, which was inspired by Vanadium. It's a good option for users that use Linux instead of Android as a desktop.
Also, about crypto, why is there a negativity around it? The reason is largely due to its use in crime, use in scams, and use in investing. However, not all cryptocurrencies are automatically bad. The original purpose behind cryptocurrency was to solve a very interesting problem.
There are some cryptocurrencies with legitimate uses, such as Monero, which is a cryptocurrency designed to be completely anonymous. Whether or not you invest in it is your own business, and unrelated to the topics of this post. Bitcoin themselves even admit that Bitcoin is not anonymous, so there is a need for Monero if you want fully decentralized, anonymous digital transactions.
On the topic of fully decentralized and anonymous things, what about secure messaging apps? Most people, even GrapheneOS and CISA, are quick to recommend Signal as the gold standard. However, another messenger comes up in discussion (and my personal favorite), which is SimpleX Chat.
SimpleX Chat is recommended by GrapheneOS occasionally, as well as other credible places. This spreadsheet is my all time favorite one comparing different messengers, and SimpleX Chat is the only one that gets full marks. Signal is a close second, but it isn't decentralized and it requires a phone number.
Anyways, if you do use Signal on Android, be sure to check out Molly, which is a client (fork) of Signal for Android with lots of hardening and improvements. It is also available to install from Accrescent.
Accrescent is an open source app store for Android focused on privacy and security. It is one of the default app stores available to install directly on GrapheneOS. It plans to be an alternative to the Google Play Store, which means it will support installing proprietary apps. Accrescent is currently in early stages of development, so there are only a handful of apps on there, but once a few issues are fixed you will find that a lot of familiar apps will support it quickly.
Many people have high hopes for Accrescent, and for good reason. Other app stores like F-Droid are insecure, which pose risks such as supply chain attacks. Accrescent is hoped to be (and currently is) one of the most secure app stores for Android.
The only other secure app store recommended by GrapheneOS is the Google Play Store. However, using it can harm user privacy, as it is a Google service like any other. You also need an account to use it.
Users of GrapheneOS recommend making an anonymous Google account by creating it using fake information from a non-suspicious (i.e. not a VPN or Tor) IP address such as a coffee shop, and always use a VPN afterwards. A lot of people aren't satisfied with that response, since the account is still a unique identifier for your device. This leads to another slap fight about Aurora Store, which allows you to (less securely) install Play Store apps using a randomly given Google account.
The difference between the Play Store approach and the Aurora Store approach is that Aurora Store's approach is k-anonymous, rather than... "normal" anonymity. The preference largely comes down to threat models, but if you value security then Aurora Store is not a good option.
Another criticism of the Play Store is that it is proprietary. The view of security between open source software and proprietary software has shifted significantly. It used to be that people viewed open source software as less secure because the source code is openly available. While technically it's easier to craft an attack for a known exploit if the source code is available, that doesn't make the software itself any less secure.
The view was then shifted to open source software being more secure, because anyone can audit the code and spot vulnerabilities. Sometimes this can help, and many vulnerabilities have been spotted and fixed faster due to the software being open source, but it isn't always the case. Rarely do you see general people looking over every line of code for vulnerabilities.
The reality is that, just because something is open source, doesn't mean it is automatically more or less secure than if it were proprietary. Being open source simply provides integrity in the project (since the developers make it as easy as possible to spot misconduct), and full accountability towards the developers when something goes wrong. Being open source is obviously better than being proprietary, that's why many projects choose to be open source, but it doesn't have to be that way for it to still be secure.
Plus, the workings of proprietary code can technically be viewed, since some code can be decompiled, reverse engineered, or simply read as assembly instructions, but all of those are difficult, time consuming, and might get you sued, so it's rare to see it happen.
I'm not advocating for the use of proprietary software, but I am advocating for less hate regarding proprietary software. Among other things, proprietary software has some security benefits in things like drivers, which is why projects like linux-libre and Libreboot are worse for security than their counterparts (see coreboot).
Those projects still have uses, especially if you value software freedom over security, but for security alone they aren't as recommended.
Disclaimer before this next section: I don't know the difference in terminology between "Atomic", "Immutable", and "Rolling Release", so forgive me for that.
Also, on the topic of software freedom, stop using Debian. Debian is outdated and insecure, and I would argue less stable too. Having used a distro with an Atomic release cycle, I have experienced far less issues than when I used Debian. Not to mention, if you mess anything up on an Atomic distro, you can just rollback to the previous boot like nothing happened, and still keep all your data. That saved me when I almost bricked my computer motifying /etc/fstab/ by hand.
Since fixes are pushed out every day, and all software is kept as up to date as possible, Atomic distros I argue give more stability than having an outdated "tried and tested" system. This is more an opinion rather than factually measured.
Once I realized the stable version of Debian uses Linux kernel 6.1, (which is 3 years old and has had actively exploited vulnerabilities), and the latest stable version of the kernel is 6.13, I switched pretty quick for that reason among others.
Now, many old kernel versions are still maintained, and the latest stable version of Android uses kernels 6.1 and 6.6 (which are still maintained), but it's still not great to use older kernel versions regardless. It isn't the only insecurity about Debian.
I really have nothing more to say. I know I touched on a lot of extremely controversial topics, but I'm sick of privacy being at odds with security, as well as other groups being at odds with each other. This post is sort of a collection of a lot of interesting privacy and security knowledge I've accrued throughout my life, and I wanted to share my perspective. I don't expect everybody to agree with me, but I'm sharing this in case it ever becomes useful to someone else.
Thanks for taking the time to read this whole thing, if you did. I spent hours writing it, so I'm sure it's gotten very long by now.
Happy Pi Day everyone!
The 8232 Project
in reply to marauding_gibberish142 • • •secureblue: Hardened Fedora Atomic and Fedora CoreOS images
securebluewarmaster
in reply to The 8232 Project • • •From secure blue's website:
Why do they say that? What limitations does Linux have in terms of security?
The 8232 Project
in reply to warmaster • • •privsec.dev/posts/linux/linux-…
That's a more up-to-date article about security issues with Linux.
TL;DR is that Linux (the desktop, not the kernel) is fundamentally insecure, and so the more secure options for desktop are Qubes OS (Qubes OS is not a Linux distro) or (even better) GrapheneOS used in Desktop Mode. secureblue is about as secure as Linux can get, but the most secure option for desktop itself.
Things also get weird when you consider running secureblue inside of Qubes OS. See my post for more thoughts about that.
Linux Insecurities
Tommy (PrivSec - A practical approach to Privacy and Security)unhrpetby
in reply to The 8232 Project • • •Unless you have an unusual threat model, this statement is utter nonsense. I can run a kconfig stripped kernel with zero kernel modules and one userspace process that is completely audited and trusted, without the ability to spawn even other processes or talk to network (because the kernel lacks support for the IP stack).
Secureblue might offer something significant when compared to other popular and easily usable tools, but if you compare it to the theoretical limit of Linux security, its not even comparable.
I examined Secureblue's kernel parameters and turned multiple of them off because some were mitigations for something that was unnecessary. IE: The kernel would make the analysis that your hardware is not affected by a vulnerability, and thus there is no need to enable a specific mitigation. But they would override this and force the mitigation, so you take a performance hit, for what I understand to be, no gain. Not sure why they did that, a mistake? Or did they simply not trust the kernel's analysis for some reason? Who knows.
marauding_gibberish142
in reply to The 8232 Project • • •Hey, I recognise you now! That was a great post, I had a lot of fun reading it. If I could follow people on Lemmy I'd follow you.
What do you think about Kicksecure (and Kicksecure inside of Qubes)? I know they are criticised for backports but leaving that issue aside, I think they have created a very handy distro. I personally go through CIS benchmarks for most of stuff including Kicksecure but it's definitely nice to have a prey hardened distro (SecureBlue too but I hear SecureBlue isn't a big team, not sure how much time they have to address the broad range of desktop Linux security issues).
Honestly, Qubes is the best at this by far. Their method of compartmentalisation takes away the complexity of reasonable security from the end-user making it a mostly seamless experience. I personally think that if you were to put GrapheneOS and Qubes OS side-by-side on uncompromised hardware, I'd take Qubes. I'd run GrapheneOS inside Qubes with a software/hardware TPM passed through if I could.
The 8232 Project
in reply to marauding_gibberish142 • • •Look mom, I'm famous! 😛
Thank you!
The best you can do in regards to that is adding my profile to your preferred RSS reader, so you get notified each time I post. A few good ones for android are Feeder, Read You, or (my favorite) Capy Reader.
I'm not sure if you mean actual Kicksecure or if you mean Whonix. Either way, if I were to use Qubes OS, I would do Whonix inside of Qubes (until a secureblue template is made).
secureblue backports a lot of fixes from other projects (e.g. their browser, Trivalent, backports fixes from GrapheneOS's Vanadium). Their team is small but mighty.
GrapheneOS compartmentalizes as well, but in a different fashion. All apps on GrapheneOS are sandboxed, Once GrapheneOS implements App Communication Scopes, apps will be able to be completely* isolated. Without App Communication Scopes, the best way to isolate apps is by setting up separate profiles.
*While APC prevents communication between apps, they are still installed on the same profile, and thus have access to unique profile identifiers. Apps with network access can technically communicate with each other via a third party. Furthermore, apps may be able to directly communicate with each other through a telephone effect (e.g. Pixel Camera tells Google Play Services to tell Google Calendar about the photo you just took). I am massively oversimplifying this, but you get the gist.
I mentioned in my post that security is going to become very interesting with the introduction of the Linux terminal into Android. If GrapheneOS chooses to expand on this, that means, like Qubes OS, GrapheneOS could emulate multiple Linux distros.
Anyways, this is how I would rank them in terms of security (again, oversimplified):
GrapheneOS > Qubes-secureblue > Qubes-Whonix > secureblue
Each project fundamentally has different goals, so there is no one "security" to rank them by.
Though, for desktop, I prefer secureblue, as I don't have a secondary GrapheneOS device, and secureblue is far more usable than Qubes OS.
GitHub - Ashinch/ReadYou: An Android RSS reader presented in Material You style.
GitHubwarmaster
in reply to The 8232 Project • • •Are secureblue and grapheneos more secure than a hardened OSX / Windows?
unhrpetby
in reply to warmaster • • •This is an impossible question to answer without more information. Depends on your threat model, how you use the computer, your distro, etc.
warmaster
in reply to unhrpetby • • •unhrpetby
in reply to warmaster • • •A threat model which you don't trust the Linux Foundation and volunteers but do trust Microsoft.
Its all about what you want to protect. If a security breach is worse for you on Linux than it is on Windows because of which party has the data, then for you, Windows might be more secure.
Some people get confused because they think there is some objective measurable security rating one can apply to a system for every person. There isn't. We may use the same systems but have different threat models and thus rate the security different.
pastermil
in reply to marauding_gibberish142 • • •What do you want to achieve exactly?
Different requirement can lead to different approach.
marauding_gibberish142
in reply to pastermil • • •pastermil
in reply to marauding_gibberish142 • • •What does that even mean? What kind of exploitation are you talking about?
Every use case comes with its own risk, and every risk needs to be handled differently. People jokingly said that if you wanna be sure, don't connect your computer to the network at all; and if you wanna be surer, don't use a computer. While that was a joke, there's truth in that.
If you're just going to use it as a workstation, then firewall to make sure some randos don't ping you should suffice. If you're sharing this workstation with your tech illiterate mates, then perhaps something to prevent executing random stuff like SELinux or AppArmor would do. If executing random stuff is just what you do, then set up VMs or some other ways to isolate that execution environment.
If you're sharing files directly from your computer to the internet (e.g. with SMB or NFS), then you'd need to make sure only the right people have the access, and the auth can't be brute-forced (i.e. with rate-limiting and lock-out policy). Same goes if you allow remote login (i.e. thru SSH). Some people use custom port number to obscure their stuff, and you can do it too, but do keep in mind it could make your life (or your mates' lives) harder.
If you're running other outward facing services like SQL database or HTTP, that would require different ways to address. If you're on such level, you'd want do some serious readings.
marauding_gibberish142
in reply to pastermil • • •You raise a valid point. In which case, I want to try and prevent malicious privilege escalation by a process on this system. I know that's a broad topic and depends on the application being run, but most of the tweaks I've listed work towards that to an extent.
To be precise, I'm asking how to harden the upcoming AlmaLinux based Dom0 by the XCP-NG project. I want my system to be difficult to work with even if someone breaks into it (unlikely because I trust Xen as a hypervisor platform but still).
I admit I was a bit surprised by the question since I've never consciously thought about a reason to harden my OS. I always just want to do it and wonder why OSes aren't hardened more by default.
unhrpetby
in reply to marauding_gibberish142 • • •Privilege escalations always have to be granted by an upper-privilege process to a lower-privilege process.
There is one general way this happens.
Ex: root opens up a line of communication between it and a user, the user sends input to root, root mishandles it, it causes undesired behavior within the root process and can lead to bad things happening.
All privilege escalation is two different privilege levels having some form of interaction. Crossing the security boundary. If you wish to limit this, you need to find the parts of the system that cross that boundary, like sudo[1], and remove those from your system.
[1]: sudo is an SUID binary. That means, when you run it, it runs as root. This is a problem, because you as a process have some influence on code that executes within the program (code running as root).