blog.ndumas.com/content/posts/standing-up-gogs/index.md

---
draft: false
title: "Standing up Gogs and fighting with SELinux"
aliases: ["Standing up Gogs and fighting with SELinux"]
author: "Nick Dumas"
series: []
cover: ""
summary: "SELinux like all security tools end up getting in the way of users who know what they're doing."
showFullContent: false
date: "2018-02-20"
tags:
- nginx
- gogs
- selinux
---

# The Reveal

It took me way longer than I'd like to admit but I finally discovered why I was not able to properly reverse proxy a subdomain ( [git.ndumas.com](http://git.ndumas.com) ). As it turns out, SELinux was the culprit. I wanted to write a short post about this partly to reinforce my own memory and maybe to make this sort of thing easier to find for others encountering 'mysterious' issues when operating on SELinux Fedora installations like Digital Ocean droplets.

# Symptoms

SELinux interference with nginx doing its business will generally manifest as a variation on "permission denied". Here's one such error message:

```
2018/02/20 23:32:51 [crit] 4679#0: *1 connect() to 127.0.0.1:3000 failed (13: Permission denied) while connecting to upstream, client: xxx.xxx.xxx.xxx, server: git.ndumas.com, request: "GET /favicon.ico HTTP/1.1", upstream: "http://127.0.0.1:3000/favicon.ico", host: "git.ndumas.com", referrer: "http://git.ndumas.com/"
```

# Solution

Resolving this requires whitelisting whatever action/context SELinux is restricting. There's a useful tool, `audit2allow`, that will build a module for you automatically. You can invoke it like this:

```
sudo cat /var/log/audit.log|grep nginx|grep denied|audit2allow -M filename
```

Once you've done this, you'll have a file named `filename.pp`. All you have to do next is:

```
semodule -i filename.pp
```

SELinux will revise its policies and any restrictions nginx encountered will be whitelisted.