Qubes OS is pretty secure, everything you do in it is in virtual machines. That includes putting wifi and usbs in separate virtual machines. The root virtual machine is completely separated from everything else so any attackers can't get access to it. There are also temporary virtual machines that you can use for unsafe stuff.
Privacy Guides
In the digital age, protecting your personal information might seem like an impossible task. We’re here to help.
This is a community for sharing news about privacy, posting information about cool privacy tools and services, and getting advice about your privacy journey.
You can subscribe to this community from any Kbin or Lemmy instance:
Check out our website at privacyguides.org before asking your questions here. We've tried answering the common questions and recommendations there!
Want to get involved? The website is open-source on GitHub, and your help would be appreciated!
This community is the "official" Privacy Guides community on Lemmy, which can be verified here. Other "Privacy Guides" communities on other Lemmy servers are not moderated by this team or associated with the website.
Moderation Rules:
- We prefer posting about open-source software whenever possible.
- This is not the place for self-promotion if you are not listed on privacyguides.org. If you want to be listed, make a suggestion on our forum first.
- No soliciting engagement: Don't ask for upvotes, follows, etc.
- Surveys, Fundraising, and Petitions must be pre-approved by the mod team.
- Be civil, no violence, hate speech. Assume people here are posting in good faith.
- Don't repost topics which have already been covered here.
- News posts must be related to privacy and security, and your post title must match the article headline exactly. Do not editorialize titles, you can post your opinions in the post body or a comment.
- Memes/images/video posts that could be summarized as text explanations should not be posted. Infographics and conference talks from reputable sources are acceptable.
- No help vampires: This is not a tech support subreddit, don't abuse our community's willingness to help. Questions related to privacy, security or privacy/security related software and their configurations are acceptable.
- No misinformation: Extraordinary claims must be matched with evidence.
- Do not post about VPNs or cryptocurrencies which are not listed on privacyguides.org. See Rule 2 for info on adding new recommendations to the website.
- General guides or software lists are not permitted. Original sources and research about specific topics are allowed as long as they are high quality and factual. We are not providing a platform for poorly-vetted, out-of-date or conflicting recommendations.
Additional Resources:
- EFF: Surveillance Self-Defense
- Consumer Reports Security Planner
- Jonah Aragon (YouTube)
- r/Privacy
- Big Ass Data Broker Opt-Out List
But you'll need much more RAM, 8 GB is a bare minimum...
I think most computers have at least that much ram these days, my phone has that much ram.
I would look into Gentoo's Hardened + SELinux profile if you want good security in a standard system, but as others have mentioned QubesOS is probably the most secure option OOTB (but it is very limiting). SELinux is pretty difficult to use but it's really effective, and there is good information about it on the Gentoo wiki. Not sure what exactly goes into their hardened profile but I know it implements at least some of the suggestions listed on that site (like hardened compilation flags). Also it's probably more vulnerable to 0-day attacks than Qubes, since it uses up-to-date software. But it's really flexible, and learning SELinux is useful
You can even mix and match it H/SELinux with musl (and Clang, if you're up for some masochism and performance boost), though it does require patching sometimes. From my experience, you can find patches from Alpine's Aports and that should fix it ~90% of the time, but sometimes you'd need to write your own. Another tip in case you're interested in trying musl on Gentoo is that there's a compilation flag for large file support documented in Gentoo Wiki's musl development page which fixes compilation failures caused by calls to functions with names ending in 64 (e.g. fseek64). This is yet another massive source of compilation failure in musl. Lastly, you should mask musl versions ≥ 1.2.4 if you want to have any semblance of a * good time with it.
Oh good to know! Thanks for the tips. What do you like about musl over glibc?
To be honest, I only use it for fun. Unless you enjoy tinkering like I do, or you have really low RAM, there's no reason to use it over glibc. I'm aware that Madaidan also mentioned that it is more secure, but I'm not too knowledgeable on that so I can't really comment.
Ah gotcha, just asking because I've never used it before. Good to know that Gentoo supports hardening it
Gentoo lets you do basically whatever you want. The whole idea of it is that you make all the decisions in your system, as opposed to how most distros impose their developers' choices.
Yep! Gotta love the flexibility of it
Really fasttracked my Linux learning experience too. If you're starting out Linux and are predisposed to masochism like I am, using Gentoo as your first distro really catalysed my understanding of Linux (at the cost of a week's worth of crying and self-loathing lmao).
Totally, props on taking it on as your first distro! Haha, yeah a week of pain sounds about right. My last Gentoo setup took an entire month (off and on), but I was doing something crazy (Qubes-like, every application in its own Gentoo VM, strict SELinux on host and guests)... ended up ditching that because I got comfortable enough with SELinux to write stronger policies for everything important, which is good enough for me.
I had the benefit of using other distros before trying Gentoo, so my first attempt at it wasn't so bad (but still took two full days). It's definitely taught me way more than any other distro, including Arch (although Arch was a very good stepping stone). I don't think I could go back to anything else at this point
What a coincidence, I'm trying to learn SELinux too! Any tips?
Awesome! Here are a few things that come to mind:
Make sure you have some aliases/functions for common operations:
audit2allow -a
to view audit violations (or-d
for dmesg audits)- also
-r
to add a requires statement for module construction
- also
restorecon -Rv
to recursively apply file contexts from policy (or-FRv
to also apply user context)rm -f /var/log/audit/audit.log.*; >/var/log/audit/audit.log
to clear audit logs- note: sometimes lots of logfiles (audit.log.1, etc.) collect, slowing down audit2allow
chown -R user:user PATH; chcon -R -u user_u PATH
to recursively change labels to user- could be generalized for arbitrary Linux/SELinux users
semanage fcontext -a -t TYPE PATH -s $SEUSER
to add a custom file context to the policy- e.g.
semanage fcontext -a -t "user_secrets_t" "/home/[^/]+/.secrets(/.*)?" -s user_u
- I've had better luck with this approach than the standard method of creating a
.fc
file, but in any case a custom policy is needed to create custom types
- e.g.
semanage fcontext -d PATH
to remove a custom file contextsemanage fcontext -lC
to list custom file contextssemodule -DB
to rebuild policy with all dontaudit rules disabled- often, something will not work, but
audit2allow
doesn't show anything
- often, something will not work, but
semodule -B
to rebuild policy (with dontaudit rules)semodule -i MODULE.pp
to install a modulesemodule -r MODULE
to remove a module
Also a few scripts for policy creation and management are essential. There are two basic approaches to policy creation: modules and policy modules.
Modules: can be used to modify AVC rules and are pretty simple
# a violation has occurred that you want to allow or dontaudit
echo "module my_allow 1.0;" > my_allow.te
audit2allow -ar >> my_allow.te
# verify that my_allow.te has what you expect
cat my_allow.te
# build and install the module (replace mcs with whatever policy you are using)
make -f /usr/share/selinux/mcs/include/Makefile my_allow.pp
semodule -i my_allow.pp
# clear audit logs
rm -f /var/log/audit/audit.log.*; >/var/log/audit/audit.log
Policy modules: can do anything, but are complicated, and the tools for creating them are mostly based on Red Hat.
Creating a new type:
# generate foo.fc, foo.if, and foo.te
sepolicy generate --newtype -t foo_var_lib_t -n foo
# note: see sepolicy-generate(8); sepolicy generate only supports the following
# type suffixes, but its output files can be adapted to your use case
# _tmp_t
# _unit_file_t
# _var_cache_t
# _var_lib_t
# _var_log_t
# _var_run_t
# _var_spool_t
# _port_t
# modify the .fc file with the desired file contexts, for example (with s0 for mcs)
# /path/to/context/target -- gen_context(system_u:object_r:type_t,s0)
#
# note: the "--" matches regular files, -d for directories, -c for character
# devices, -l for symbolic links, -b for block devices, or can be omitted
# to match anything. also, as mentioned before, I often have better luck
# with `semanage fcontext`, especially for user directories
vi foo.fc
# build and install the policy module
make -f /usr/share/selinux/mcs/include/Makefile foo.pp
semodule -i foo.pp
# use restorecon to adjust the file contexts of any paths you have
# by default, all operations involving this type will be denied
# (and are sometimes not audited)
semodule -DB # --disable_dontaudit
# ... use the type, collect violations ...
audit2allow -ar >> foo.te
# if dontaudit is disabled, you'll likely have a lot things to remove from here
vi foo.te
# ... repeat until rules regarding type are fully defined
Creating a new application type:
# sepolicy-generate is made for Red Hat,
# but you can use --application to get started
# creates a bunch of files that define bar_t and bar_exec_t
sepolicy generate --application -n bar [-u USER] CMD
# remove the line making the app permissive (up to you, but
# I prefer using audit violations to define the permissions)
perl -i -00 -pe 's/^permissive bar_t;\n\n//g' bar.te
# ensure that the file bar_exec_t file context points to the right bin:
vi bar.fc
# build and install the policy module
make -f /usr/share/selinux/mcs/include/Makefile bar.pp
semodule -i bar.pp
# ... use the application, update AVC rules, repeat ...
If your target application is interpreted, you'll need to write a custom C program that launches the interpreter in a specific context, then write your policy around that application. For example, you should execv something like this: /usr/bin/runcon -u user_u -t my_script_t /bin/bash PROG
.
Thanks! I'll be copypasting all of these to my notes haha
np! Hope it helps; it's a big pain but I do think it's pretty secure if configured correctly
How about Kicksecure Hardened Debian?
This is the best choice IMHO. You have a rock solid OS (Debian) and all possible taken measures to harden it with Kicksecure patch.
It's a solid option indeed but a little difficult to install in my opinion
The kicksecure documentation is well written. Go here for distro-morphing of Debian 12, step by step things to do are pretty explicit and you can even copy the command lines if you think you'll make a mistake...
Does Kicksecure implement proprietary software into Debian? Personally me, I run OpenRC and the linux-libre kernel on my Debian 12 system on a Libreboot laptop with fully free software. Haven't used Kicksecure in awhile.
Awesome!
You have the holy grail of Free Software ---
Richard Stallman approves!
I really like Linux libre kernel but it has some downsides because it doesn't have patchs to fix some critical vulnerabilities. Libreboot is just a distant dream unfortunately few devices are compatible with it.
I don't think so, mostly it's hardening, and few security related software, all FOSS
Do you know if I can morph my GNOME Debian version to Kicksecure? I read their documentation and they recommend XFCE.
According to their Wiki, other Distros (including DE) are not supported/documented and if you do it's at your own risk. Personally, I wouldn't dare trying that.
Kicksecure is a good choice for an install on bare metal. For a level-plus secure and private system you can even install a Whonix VM on Kicksecure, so you can use Kicksecure daily use your Whonix VM to get on internet. It's a great combo i thinkk, as they use the same base, the same DE (xfce) and have a lot of defaults programs in common.
I'll assume that you intend to use it as a traditional daily driver, as such Tails and Whonix will not be taken into consideration. Qubes OS will also be dismissed as it's technically not a Linux distro. Though, it's simply the best if you take security seriously.
Within the space of traditional Linux distros, the closest one would probably be Kicksecure. Madaidan even works on the distro, so I'd say it's fair to assume that it upholds some of the values that are mentioned in the article.
Alternatively, packages for Fedora that would set this up automatically
Hehe, wishful thinking 😂. Uhmm..., bummer, but such a thing simply does not exist. Best we've got would be relying on so-called hardening scripts made by people that you don't know but somehow trust for hardening your system. Honestly, I'm also -to a degree- guilty of this as I one day hope to either adopt these scripts or rebase to one of these hardened 'immutable' Fedora images (when they're ready); Madaidan's guidelines have actually been an initial inspiration for the scripts found in the first link, so yeah 🙂. Until then, our best bet would probably be relying on hardening guides like this one; the guide has been carefully written (and is still getting regularly updated) with consideration for all the different major distros one might be using. Alternatively, you might try to implement Madaidan's guidelines directly. But, my previous attempts on Fedora didn't bear the best results. Though your mileage may vary. Special shout out to Brace as it's the closest thing to a package that does the hardening for you and works on multiple distros including Fedora. It's maintained by the same people that have brought us the excellent DivestOS, so it's trustworthy.
Thanks for this comment. I had not come across that hardening guide. It is extremely well written, and it's worth a read, even if you have no intention of trying to harden your system, just to see what's out there.
I'd consider most of it overkill for my threat model, but there are some things I'll probably implement or try out just because they look pretty neat.
This might be way off, but iirc OpenBSD is pretty secure
My first thought is tails.
The Rocky or Alma (red hat clones) installation provides a set of hardening options to make the system compliant with various published standards. https://www.cyberithub.com/step-by-step-guide-to-install-rocky-linux-8-4/#Step_13_Security_Policy
You might want to look at Debian and install only minimal components, and then just read through the security guide. If you care about security, I am not sure automated is the way to go, or at least not without some personal knowledge and a personal audit of the supposedly secure system. There is also the question of hardened against what meaning one has to consider your threats.
Keep in mind that security is boring. You want it to be boring. Long established distributions with good team and release cycle, really good security team, and minimal software, minimal attack surface (i.e. less is more). Just mention because Fedora is a test bed really, and so not exactly what one would choose for a secure system.
This is why of the list that people provided I would personally favor Rocky (RHEL), Debian, or OpenBSD. All of the others have a lot to prove to me frankly. Not saying bad, lot were good suggestions, but they have the downsides of being less mainstream and/or more cutting edge, or more specialized.