Configuring CentOS 9 to block httpd from accessing any program with setuid or setgid using SELinux

[Hudle]

The steps I have taken so far:
Enabled SELinux (Enforcing)

Create a file for the custom SELinux Policy
sudo vi /root/httpd_no_setuid.te

Added the following content:

module httpd_no_setuid 1.0;

require {
    type httpd_t;
    type setuid_exec_t;
    type setgid_exec_t;
    class file { execute execute_no_trans };
}

# Deny access to setuid or setgid files by httpd
neverallow httpd_t setuid_exec_t:file execute_no_trans;
neverallow httpd_t setgid_exec_t:file execute_no_trans;

After saving the file, I attempt to compile and install the SELinux policy module by running:
sudo checkmodule -M -m -o /root/httpd_no_setuid.mod /root/httpd_no_setuid.te
sudo semodule_package -o /root/httpd_no_setuid.pp -m /root/httpd_no_setuid.mod
sudo semodule -i /root/httpd_no_setuid.pp

The first two commands return with no error but the third returns:
Failed to resolve typeattributeset statement at /var/lib/selinux/targeted/tmp/modules/400/httpd_no_setuid/cil:2
Failed to resolve AST
semodule: Failed!

I have not been able to figure out the reason behind this error. Any advice?

 

[wizardfromoz]

Moving this to RPM-based distros subforum

 

[f33dm3bits]

The first two commands return with no error but the third returns:
Failed to resolve typeattributeset statement at /var/lib/selinux/targeted/tmp/modules/400/httpd_no_setuid/cil:2
Failed to resolve AST
semodule: Failed!

It's because the "setuid_exec_t" and ""setgid_exec_t" contexts don't exist. If you remove that non-existing contexts and replace it with an existing one as a test, for example: zebra_t. Check and package, then it will install.

[root@localhost ~]# cat httpd_no_setuid.te
module httpd_no_setuid 1.0;

require {
    type httpd_t;
    #type setuid_exec_t;
    #type setgid_exec_t;
    type zebra_t;
    class file { execute execute_no_trans };
}

# Deny access to setuid or setgid files by httpd
#neverallow httpd_t setuid_exec_t:file execute_no_trans;
#neverallow httpd_t setgid_exec_t:file execute_no_trans;
neverallow httpd_t zebra_t:file execute_no_trans;
neverallow httpd_t zebra_t:file execute_no_trans;
[root@localhost ~]# checkmodule -M -m -o /root/httpd_no_setuid.mod /root/httpd_no_setuid.te
[root@localhost ~]# semodule_package -o /root/httpd_no_setuid.pp -m /root/httpd_no_setuid.mod
[root@localhost ~]# semodule -i httpd_no_setuid.pp
[root@localhost ~]# semodule -l | grep  setuid
httpd_no_setuid

 

[Hudle]

@f33dm3bits This is the first I have ever learned anything about this. How would I know what an existing context is and what isn't?

 

[f33dm3bits]

How would I know what an existing context is and what isn't?

dnf install setools-console
seinfo -t

SYNOPSIS
seinfo [OPTIONS] [EXPRESSION] [POLICY]

DESCRIPTION
seinfo allows the user to query the components of a SELinux policy.

-t [TYPE], --type [TYPE]
Print a list of types or, if TYPE is provided, print the named type. With -x, print a list of attributes
which include each displayed type.

 

[Hudle]

@f33dm3bits Is there an easy way to confirm that my server is now blocking setuid and setgid?

 

[f33dm3bits]

@f33dm3bits Is there an easy way to confirm that my server is now blocking setuid and setgid?

To be clear I said.

If you remove that non-existing contexts and replace it with an existing one as a test, for example: zebra_t. Check and package, then it will install.

I said as an example use an existing context to show that it will then build and install. That was to prove the "setuid_exec_t" and ""setgid_exec_t" contexts don't exist, as an example I gave "zebra_t". No idea what context you need to block setuid and setgid.

If you are referring to this reply. Then what you are doing is not necessary because that person's experience is with an older version of Debian(I think 11) where he is using Apache. CentOS 9 has selinux enabled which would limit the damage a vulnerability could do if there is one. With how selinux is setup with default policies Apache is not allowed to access any context that is not one of these.

[root@localhost ~]# seinfo -t | grep httpd | grep sys
   httpd_sys_content_t
   httpd_sys_htaccess_t
   httpd_sys_ra_content_t
   httpd_sys_rw_content_t
   httpd_sys_script_exec_t
   httpd_sys_script_t

And to execute something as apache, it would need to have the context of the last two probably. So you don't need to setup a custom policy for this. Lastly Redhat is active when it comes to patching vulnerabilities and if there is a known existing one, they will create a CVE for it and patch it within a certain time.

 

[Trenix25]

Personally I don't trust SELinux because it's from the nsa. I use ACLs to block access to anything to setuid or setgid for any servers that I use. See setfacl(1).

Signed,

Matthew Campbell

 

[dos2unix]

Access Control Lists (ACLs) and Security-Enhanced Linux (SELinux) are both mechanisms for managing permissions and access control on Linux systems, but they operate in different ways and serve different purposes.

Access Control Lists (ACLs)
Purpose: ACLs provide a more flexible permission mechanism than the traditional Unix file permissions. They allow you to define permissions for any user or group, not just the file owner, group, and others.
Functionality: With ACLs, you can specify detailed permissions for multiple users and groups on a per-file or per-directory basis. This is useful in environments where fine-grained access control is needed.
Implementation: ACLs are implemented at the filesystem level and are supported by many modern filesystems like ext4, XFS, and Btrfs.

Security-Enhanced Linux (SELinux)
Purpose: SELinux is a security architecture for Linux systems that provides a mechanism for supporting access control security policies, including mandatory access controls (MAC). It was originally developed by the NSA and is now maintained by the open-source community.
Functionality: SELinux uses security policies to define what actions users and processes can perform on the system. It enforces these policies through a set of rules that control access to files, processes, and other system resources based on security contexts.
Implementation: SELinux is integrated into the Linux kernel and operates independently of traditional Unix permissions and ACLs. It provides an additional layer of security by enforcing strict access controls that cannot be bypassed by users, even with root privileges

 

[f33dm3bits]

Personally I don't trust SELinux because it's from the nsa.

Selinux is opensource, read through the code if you don't trust it. If it had been proprietary software I would have agreed with you but it is not the case.

SELinux Project

SELinux is flexible Mandatory Access Control (MAC) for Linux - SELinux Project

github.com

Security-Enhanced Linux - Wikipedia

en.wikipedia.org

It is not necessary ot scare someone away from selinux just because you don't trust the project.

What is SELinux?

Security-Enhanced Linux (SELinux) is a security architecture for Linux® systems that allows administrators to have more control over who can access the system.

www.redhat.com

How trustworthy is SELinux?

Given the ongoing leaks concerning mass surveillance and the fact that the NSA is the original developer of SELinux, I'm wondering whether that means that backdoors should be expected in there? As...

security.stackexchange.com

SELinux In Linux 6.6 Removes References To Its Origins At The US NSA - Phoronix

www.phoronix.com

Access Control Lists (ACLs) and Security-Enhanced Linux (SELinux) are both mechanisms for managing permissions and access control on Linux systems, but they operate in different ways and serve different purposes.

As @dos2unix already said here they are additions of security tools that can add to the security of the system.