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
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: 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 1 year ago
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).
ctr1@fl0w.cc 1 year ago
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
ruination@discuss.tchncs.de 1 year ago
What a coincidence, I’m trying to learn SELinux too! Any tips?
ctr1@fl0w.cc 1 year ago
Awesome! Here are a few things that come to mind:
Make sure you have some aliases/functions for common operations:
audit2allow -ato view audit violations (or-dfor dmesg audits)-rto add a requires statement for module constructionrestorecon -Rvto recursively apply file contexts from policy (or-FRvto also apply user context)rm -f /var/log/audit/audit.log.* && >/var/log/audit/audit.logto clear audit logschown -R user:user PATH && chcon -R -u user_u PATHto recursively change labels to usersemanage fcontext -a -t $TYPE $PATH -s $SEUSERto add a custom file context to the policysemanage fcontext -a -t “user_secrets_t” “/home/[^/]+/.secrets(/.*)?” -s user_u.fcfile, but in any case a custom policy is needed to create custom typessemanage fcontext -d $PATHto remove a custom file contextsemanage fcontext -lCto list custom file contextssemodule -DBto rebuild policy with all dontaudit rules disabledaudit2allowdoesn’t show anythingsemodule -Bto rebuild policy (with dontaudit rules)semodule -i MODULE.ppto install a modulesemodule -r MODULEto remove a moduleAlso a few scripts for policy creation and management are essential. There are two basic approaches to policy creation:
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.