SELinux blocking nginx -t

Question

I'm setting up Rocky Linux and I've run into this error:

sudo nginx -t

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied)
nginx: configuration file /etc/nginx/nginx.conf test failed

My user's SELinux information is:

id -Z

staff_u:staff_r:staff_t:s0-s0:c0.c1023

sudo -s
id -Z

staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023

My sudoer rule:

USERNAME ALL=(ALL) ROLE=sysadm_r TYPE=sysadm_t NOPASSWD: ALL

I have followed https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/using_selinux/managing-confined-and-unconfined-users_using-selinux#confining-an-administrator-using-sudo-and-the-sysadm_r-role_managing-confined-and-unconfined-users.

After having trouble getting any errors logged, I disabled the 'dontaudit' rules and got:

ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent

time->Fri Oct  6 17:02:35 2023
type=PROCTITLE msg=audit(1696611755.583:1149): proctitle=7375646F006E67696E78002D74
type=PATH msg=audit(1696611755.583:1149): item=0 name="/lib64/ld-linux-x86-64.so.2" inode=8668 dev=fd:02 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1696611755.583:1149): cwd="/home/USERNAME"
type=EXECVE msg=audit(1696611755.583:1149): argc=3 a0="sudo" a1="nginx" a2="-t"
type=SYSCALL msg=audit(1696611755.583:1149): arch=c000003e syscall=59 success=yes exit=0 a0=56233d0695a0 a1=56233d1800a0 a2=56233cffae40 a3=8 items=1 ppid=6128 pid=11286 auid=1000 uid=1000 gid=1000 euid=0 suid=0 fsuid=0 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=3 comm="sudo" exe="/usr/bin/sudo" subj=staff_u:staff_r:staff_sudo_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1696611755.583:1149): avc:  denied  { siginh } for  pid=11286 comm="sudo" scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=staff_u:staff_r:staff_sudo_t:s0-s0:c0.c1023 tclass=process permissive=0
type=AVC msg=audit(1696611755.583:1149): avc:  denied  { rlimitinh } for  pid=11286 comm="sudo" scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=staff_u:staff_r:staff_sudo_t:s0-s0:c0.c1023 tclass=process permissive=0
type=AVC msg=audit(1696611755.583:1149): avc:  denied  { noatsecure } for  pid=11286 comm="bash" scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=staff_u:staff_r:staff_sudo_t:s0-s0:c0.c1023 tclass=process permissive=0

It seems to be running as

staff_u:staff_r:staff_t:s0-s0:c0.c1023

and not

staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023

I'm far from an expert when it comes to this so any help is greatly appreciated!

---

As requested:

audit2allow -a

#============= chkpwd_t ==============
allow chkpwd_t user_devpts_t:chr_file { read write };

#============= init_t ==============
allow init_t unconfined_service_t:process siginh;

#============= staff_sudo_t ==============
allow staff_sudo_t chkpwd_t:process { noatsecure rlimitinh siginh };
allow staff_sudo_t self:capability net_admin;
allow staff_sudo_t shadow_t:file read;
allow staff_sudo_t sysadm_t:process { noatsecure rlimitinh siginh };

#============= staff_t ==============
allow staff_t staff_sudo_t:process { noatsecure rlimitinh siginh };

#============= sysadm_t ==============
allow sysadm_t http_port_t:tcp_socket name_bind;

sudo ls -Z /etc/nginx

system_u:object_r:httpd_config_t:s0 conf.d
system_u:object_r:httpd_config_t:s0 fastcgi_params
system_u:object_r:httpd_config_t:s0 mime.types
system_u:object_r:httpd_config_t:s0 modules
system_u:object_r:httpd_config_t:s0 nginx.conf
system_u:object_r:httpd_config_t:s0 scgi_params
system_u:object_r:httpd_config_t:s0 uwsgi_params

sudo ls -Z /etc/nginx/conf.d

system_u:object_r:httpd_config_t:s0 default.conf

Answer 1

It looks like your setup is working correctly, and your staff_u user running a command preprended with sudo is indeed running with sysadm_r role.

Here, your error nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) and the audit log allow sysadm_t http_port_t:tcp_socket name_bind; does show that you have a denial because the type sysadm_t cannot name_bind the port http_port_t:tcp_socket, here the port tcp/80.

To allow this behaviour, you can create a policy:

cat > sysadm_bind_http.te << EOF
module sysadm_bind_http 1.0;

require {
type sysadm_t;
type http_port_t;
class tcp_socket { name_bind };
}

#============= sysadm_t ==============
allow sysadm_t http_port_t:tcp_socket name_bind;
EOF
checkmodule -M -m -o sysadm_bind_http.mod sysadm_bind_http.te
semodule_package -o sysadm_bind_http.pp -m sysadm_bind_http.mod
semodule -i sysadm_bind_http.pp

Answer 2

On Red Hat-based systems, such as Red Hat Enterprise Linux (RHEL) or CentOS, SELinux (Security-Enhanced Linux) can also sometimes block nginx -t due to policy violations or incorrect security labels. To troubleshoot and resolve this issue on Red Hat systems.

Here are the steps to troubleshoot and resolve SELinux issues with nginx -t on Red Hat-based systems:

1. Check SELinux Audit Logs:

   Review SELinux audit logs to gain more insights into why nginx -t is being blocked. You can use the ausearch command:

   sudo ausearch -c 'nginx' --raw | audit2allow -M my-nginx-policy
   sudo semodule -i my-nginx-policy.pp
   

   This generates a custom SELinux policy module based on the audit logs and installs it.

2. Check Nginx Configuration Files:

   Ensure that the Nginx configuration files have the correct SELinux security context labels using the ls -Z command. If labels are incorrect, use chcon to set the correct labels:

   sudo chcon -t httpd_config_t /etc/nginx/nginx.conf
   

   Replace /etc/nginx/nginx.conf with the actual path to your Nginx configuration file.

3. Test Nginx Configuration:

   After addressing any SELinux policy issues and verifying the security labels, try running nginx -t to check the configuration syntax:

   sudo nginx -t
   

   SELinux should no longer block this operation if the issues have been resolved.

4. Relabel the Entire Nginx Configuration Directory (if necessary):

   If you have multiple Nginx configuration files with incorrect security labels, you can recursively relabel the entire directory:

   sudo restorecon -Rv /etc/nginx/
   

   This command resets SELinux security context labels for all files and directories under /etc/nginx/.

5. SELinux Policy Modification (if necessary):

   If SELinux continues to block the operation despite taking the above steps, you may need to create a custom SELinux policy module specifically for your Nginx configuration. Be cautious when modifying SELinux policies, as it can impact system security.

Remember to follow SELinux best practices and only modify policies when you fully understand the consequences. Additionally, regularly updating your system and keeping SELinux policies up-to-date can help avoid issues like this in the future.