Как я могу сказать SELinux разрешить nginx доступ к сокету unix без audit2allow?

Кажется смешным, что вы не можете настроить политику, позволяющую nginx записывать данные в сокет, не получив сначала отказа, а затем запустив инструмент, который разрешает то, что было запрещено.

Ну нет, SELinux - это обязательный контроль доступа, по умолчанию все запрещено, и вы должны что-то явно разрешить. Если авторы политики не учли конкретный (откровенный) стек или авторы демона не сделали его осведомленным о SELinux и не написали для него политику, тогда вы сами по себе. Вы должны проанализировать, что делают ваши службы и как они взаимодействуют с SELinux, и придумать собственную политику, позволяющую это сделать. Есть инструменты, которые помогут вам audit2why, audit2allow и т.п.

... Это единственный способ?

Нет, но решение зависит от того, что вы пытаетесь сделать и как пытаетесь это сделать. Например, вы можете привязать nginx (httpd_t) к порту 8010 (unreserved_port_t). Когда вы запускаете nginx, он не работает

Starting nginx: nginx: [emerg] bind() to 0.0.0.0:8010 failed (13: Permission denied)

и вы (в конце концов) посмотрите в журнал аудита и найдете

type=AVC msg=audit(1457904756.503:41673): avc:  denied  { name_bind } for
pid=30483 comm="nginx" src=8010 scontext=unconfined_u:system_r:httpd_t:s0
tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket

Вы можете запустить это через audit2alllow и наивно принять его выводы.

allow httpd_t port_t:tcp_socket name_bind;

который затем позволяет httpd_t подключаться к любому порту TCP. Возможно, это не то, что вам нужно.

Ты можешь использовать sesearch чтобы изучить политику и посмотреть, какие типы портов httpd_t может использовать name_bind для

sesearch --allow -s httpd_t | grep name_bind
...
allow httpd_t http_port_t : tcp_socket name_bind ;
allow httpd_t http_port_t : udp_socket name_bind ;
...

Среди других типов http_t может связываться с http_port_t. Теперь вы можете использовать semanage копать немного глубже.

semanage port -l | grep http_port_t
http_port_t                    tcp      80, 81, 443, 488, 8008, 8009, 8443, 9000
...

Порт 8010 отсутствует в списке. Поскольку мы хотим, чтобы nginx привязался к порту 8010, не лишним будет добавить его в список http_port_t.

semanage port -a -t http_port_t -p tcp 8010

Теперь nginx будет разрешено привязать name_bind к порту 8010, а не каждому порту tcp, как указано выше.

Как узнать, что именно включено?

Изменения в политике довольно легко читать, пропуская ваши сообщения через audit2allow, мы получаем

allow httpd_t httpd_sys_content_t:sock_file write;
allow httpd_t initrc_t:unix_stream_socket connectto;

которые кажутся довольно понятными.

Первый из них относится к файлу с inum 76151. Вы можете использовать find, чтобы получить его имя (find / -inum 76151), а затем использовать semanage fcontext -a -t ... для изменения политики и restorecon для исправления контекста.

Второй относится к /run/gunicorn/socket который снова имеет неправильный контекст. Используя поиск, мы видим, что http_t может подключаться к unix_stream_sockets типа (среди прочего) http_t. Таким образом, мы можем соответственно изменить контекст, например

semanage fcontext -a -t httpd_t "/run/gunicorn(/.*)?"
restorecon -r /run

Это устанавливает контекст / run / gunicorn и дерева | файлы под ним в httpd_t.

Как это должно работать, если вы настраиваете машины в автоматическом режиме?

Вам необходимо проанализировать систему и внести соответствующие изменения в тест. Затем вы используете свои инструменты автоматизации для развертывания изменений, марионетка и доступный объект имеют для этого поддержку.

Конечно, вы можете делать все это в продакшене с SElinux, установленным на permissive. Соберите все сообщения, проанализируйте их, выберите свои изменения и разверните их.

О SELinux нужно знать гораздо больше, но это предел моих навыков, Майкл Хэмптон лучше, а Мэтью Ифе снова намного лучше, им, возможно, есть что добавить.

Тип, который вы хотите использовать, не httpd_sys_content_t. Это статические файлы, которые веб-сервер предназначен для обслуживания пользовательских агентов.

Для сокета, используемого для межпроцессного взаимодействия, вам нужен тип httpd_var_run_t.

Однако учтите, что, поскольку вы запустили gunicorn без ограничений, могут возникнуть дополнительные проблемы при общении с ним.

Я безуспешно пробовал предыдущие ответы, в моем случае я использую сервер nginx в качестве интерфейса для приложения uwsgi, используя сокеты unix для их связи, мой O.S. Это сервер Fedora 26.

Сокеты unix создаются в каталоге /var/local/myapp:

/var/local/myapp/server.sock    
/var/local/myapp/stats.sock

Для настройки SELinux мне пришлось добавить тип контекста: httpd_sys_rw_content_t

semanage fcontext -at httpd_sys_rw_content_t "/var/local/myapp(/.*)?"
restorecon -R -v '/var/local/myapp'