view the rest of the comments
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
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)-r
to add a requires statement for module constructionrestorecon -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 logschown -R user:user PATH; chcon -R -u user_u PATH
to recursively change labels to usersemanage fcontext -a -t TYPE PATH -s $SEUSER
to add a custom file context to the policysemanage fcontext -a -t "user_secrets_t" "/home/[^/]+/.secrets(/.*)?" -s user_u
.fc
file, but in any case a custom policy is needed to create custom typessemanage fcontext -d PATH
to remove a custom file contextsemanage fcontext -lC
to list custom file contextssemodule -DB
to rebuild policy with all dontaudit rules disabledaudit2allow
doesn't show anythingsemodule -B
to rebuild policy (with dontaudit rules)semodule -i MODULE.pp
to install a modulesemodule -r MODULE
to remove a moduleAlso 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
Policy modules: can do anything, but are complicated, and the tools for creating them are mostly based on Red Hat.
Creating a new type:
Creating a new application type:
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