• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

SELinux blocking NGINX from binding to port

 
Marshal
Posts: 3655
516
Android Eclipse IDE TypeScript Redhat MicroProfile Quarkus Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am trying to use NGINX as a security gateway for TLS traffic (ProtoBuf over TLS, not HTTP over TLS), where TLS is terminated by NGINX with the unencrypted stream is proxied to the application.

I have a working configuration, but SELinux is complaining that NGINX is not permitted to bind to my ingress port (in my testing I was using port 12345):

It seems like I may need to register a new port type, associate the port number with the new port type, and then associate the new port type with the nginx application  Have I got this correct?  Any pointers on where I can a practical example?  I'm new to SELinux.

OS is CentOS Linux release 7.8.2003.
 
Saloon Keeper
Posts: 24314
167
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Actually, I use nginx as my primary proxy for backend Tomcat and Apacher servers splattered all over the DMZ, so I'm using ports 80 and 443 and it's Apache that I have to assign alternative ports to. But the selinux considerations are the same either way.

Run the audit2allow utility against the audit log and it will spit out the necessary rules to apply. In redhat-style systems, the audit2why and audit2allow utilities come in a package named something like "selinux-python-utils". I forget the details on the Debian/Ubuntu/Raspbian, but an apt-cache search should help there.

The audit2allow application traditionally ran using /var/log/audit/audit.log as its input, but recent systems have moved the audit log to the systemd journal. You can pipe the output straight from journalctl to audit2allow, although it's politer to filter for audit-specific messages. Since I can't remember what the filter is, though, I generally use brute force.
 
Skool. Stay in. Smartness. Tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
reply
    Bookmark Topic Watch Topic
  • New Topic