posts: remove double backslashes

Author: 0xC0ncord

content/posts/2020/07/welcome.md

@@ -9,6 +9,5 @@ tags:
 ---
 
 And so as of the time of writing this, my blog is now officially live. I am still adding content to my other pages and will soon add a [links](https://concord.sh/links/) page, but for now I leave any readers with this notice and a wide future of upcoming content. I also anticipate uploading the full source of the site to a public Git repository.
-\
-\
+
 Until next time, see ya.

content/posts/2020/09/wrong-run_init-authentication.md

@@ -12,14 +12,11 @@ tags:
 - pam
 ---
 Today I noticed that for some reason on one of my Gentoo boxes, I needed to authenticate as root in order to start and stop services, when on my other boxes I would authenticate as my currently logged in user. Normally I like to run `sudo -i` or `sudo -s` in order to run multiple tasks in the same session, and this was never previously a problem until I recently locked down the root account such that I could no longer enter its password (it no longer had one).
-\
-\
+
 On Gentoo at least, when you need to execute some action on some service, the usage of `run_init` is required. The purpose of this utility is to change SELinux contexts from a user context to a system context for the purpose of running some action on some service. The reason for this is that doing this requires a change to the SELinux system user, role, and type, a highly privileged action. You can read more about this [here](https://wiki.gentoo.org/wiki/SELinux/Tutorials/Linux_services_and_the_system_u_SELinux_user). With this in mind, I started digging through my SELinux configuration, looking for anything out of the ordinary. Everything was in place. My SELinux login mapping was correct and I had access to all the correct roles. Then, I started looking through PAM. `run_init` is configured to authenticate through PAM using the configuration in `/etc/pam.d/run_init` which had no differences between both of my systems. Also checking `/etc/pam.d/system-auth` turned up no differences.
-\
-\
+
 At this point I was beginning to pull my hair out a little, and went down the path of running `strace` against `run_init` to see what exactly was going on. I noticed that on the system where `run_init` was working as I was expecting, by asking me for my credentials instead of root's, `run_init` was reading the contents of `/proc/self/loginuid`, and the other system was not. Immediately after this file was read, PAM was invoked using the UID present in this file. That's when I had a vague realization of what was happening.
-\
-\
+
 I did a quick search for what package was providing the `run_init` binary and thought to check its USE flags.
 ```shell
 # equery b `which run_init`
@@ -41,6 +38,5 @@ sys-apps/policycoreutils-3.1 (/usr/sbin/run_init)
 
 ```
 Ah ha! Sure enough, on the system where my user was being authenticated, the `audit` USE flag was set, and here it wasn't. A quick flip of this flag and a rebuild of `policycoreutils` fixed the problem.
-\
-\
+
 This was a little bit of an oddity at first. I feel like this functionality should be separated from the `audit` USE flag in some way, as it looks like `run_init` checks what user is invoking some action in order to log it, but this information is also passed along to PAM. Without this check, `run_init` seems to assume that the root user is the one performing the action and does not authenticate the actual user against PAM. In any case, this simple change implemented the exact behavior I was looking for.

content/posts/2020/10/selinux-nextcloud-cron.md

@@ -10,11 +10,9 @@ tags:
 - nextcloud
 ---
 If you run your own Nextcloud instance, one of the things you will need to do when finalizing setup is to configure Nextcloud's [internal cron service](https://docs.nextcloud.com/server/20/admin_manual/configuration_server/background_jobs_configuration.html).
-\
-\
+
 The default and least reliable option is AJAX, which will run the cron service each time a Nextcloud page is requested. The immediate problem here is that if your Nextcloud instance does not have much continuous usage (like mine), especially from a web browser, the cron service will not run as often as it needs to.
-\
-\
+
 The recommended option is system cron, which requires setting up a system cronjob like so:
 ```sh
 */5 * * * * nginx php -f /var/www/nextcloud/htdocs/cron.php
@@ -25,8 +23,7 @@ node=megumin type=AVC msg=audit(1603560001.338:3684): avc:  denied  { execmem }
 node=megumin type=AVC msg=audit(1603560001.338:3684): avc:  denied  { execstack } for  pid=30481 comm="php" scontext=system_u:system_r:system_cronjob_t:s0-s0:c0.c1023 tcontext=system_u:system_r:system_cronjob_t:s0-s0:c0.c1023 tclass=process permissive=1
 ```
 What's happening here is the cron service is running under the system cron context, which does not have permissions to execute writable memory, which is required for PHP to work.
-\
-\
+
 These are two very sensitive and potentially dangerous permissions, so if you are like me, you may not want to simply grant these permissions to the system cron context. Instead, you think to try and create a stub script in order to set up a process transition like so:
 ```sh
 #!/bin/sh
@@ -38,8 +35,7 @@ application_executable_file(phpfpm_cron_exec_t)
 cron_system_entry(phpfpm_t, phpfpm_cron_exec_t)
 ```
 Now we can label our script as `phpfpm_cron_exec_t`, make it executable, and tell our cronjob to execute this file.
-\
-\
+
 But now we have new problems:
 ```plain
 node=megumin type=AVC msg=audit(1603558690.194:3611): avc:  denied  { map } for  pid=27906 comm="sh" path="/bin/bash" dev="sda4" ino=13238332 scontext=system_u:system_r:phpfpm_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=1
@@ -48,21 +44,17 @@ node=megumin type=AVC msg=audit(1603558690.194:3611): avc:  denied  { read open
 node=megumin type=AVC msg=audit(1603558690.194:3611): avc:  denied  { execute } for  pid=27906 comm="php-fpm" name="bash" dev="sda4" ino=13238332 scontext=system_u:system_r:phpfpm_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=1
 ```
 The `phpfpm_t` type does not have the permissions needed to run a shell and execute the `php` binary.
-\
-\
+
 So that takes us back to square one. Let's take another look at our options again. We also have the option of using a Webcron service. It took me a minute to figure this out since I had never heard of it before, but essentially you can use a third-party service which will send HTTP GET requests (or whatever you configure) to endpoints on your webserver, which will trigger PHP to do something on the backend. After realizing what this could do for us, I came up with the following solution.
-\
-\
+
 We can use the Webcron service and simply `curl` our `cron.php` internally using the system cron. Easy!
-\
-\
+
 So we create a cronjob like so:
 ```bash
 */5 * * * * root curl https://nextcloud.example.com/cron.php >/dev/null
 ```
 And then we tell Nextcloud that we are using a Webcron. That's it!
-\
-\
+
 Additionally, you could even restrict the cron service endpoint to the local host or network only. To do this, you can insert this block into your Nextcloud's server definition in Nginx:
 ```nginx
 location = /cron.php {