this post was submitted on 13 Sep 2023
16 points (100.0% liked)

Privacy Guides

697 readers
1 users here now

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:

Learn more...


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:

  1. We prefer posting about open-source software whenever possible.
  2. 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.
  3. No soliciting engagement: Don't ask for upvotes, follows, etc.
  4. Surveys, Fundraising, and Petitions must be pre-approved by the mod team.
  5. Be civil, no violence, hate speech. Assume people here are posting in good faith.
  6. Don't repost topics which have already been covered here.
  7. 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.
  8. Memes/images/video posts that could be summarized as text explanations should not be posted. Infographics and conference talks from reputable sources are acceptable.
  9. 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.
  10. No misinformation: Extraordinary claims must be matched with evidence.
  11. 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.
  12. 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:

founded 1 year ago
MODERATORS
 

For example, ones that implement these guidelines? https://madaidans-insecurities.github.io/guides/linux-hardening.html

Alternatively, packages for Fedora that would set this up automatically

you are viewing a single comment's thread
view the rest of the comments
[–] ruination@discuss.tchncs.de 2 points 1 year ago (3 children)

What a coincidence, I'm trying to learn SELinux too! Any tips?

[–] ctr1@fl0w.cc 1 points 1 year ago* (last edited 1 year ago) (2 children)

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
  • 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
  • semanage fcontext -d PATH to remove a custom file context
  • semanage fcontext -lC to list custom file contexts
  • semodule -DB to rebuild policy with all dontaudit rules disabled
    • often, something will not work, but audit2allow doesn't show anything
  • semodule -B to rebuild policy (with dontaudit rules)
  • semodule -i MODULE.pp to install a module
  • semodule -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.

[–] ruination@discuss.tchncs.de 2 points 1 year ago (1 children)

Thanks! I'll be copypasting all of these to my notes haha

[–] ctr1@fl0w.cc 1 points 1 year ago

np! Hope it helps; it's a big pain but I do think it's pretty secure if configured correctly