How to interpret SELinux boolean allow rules?

Question

I'm trying to understand what permissions are allowed by some of the SELinux booleans for httpd domain, as it is my main source of concern, and the current policy of my organization is to give truly the least privilege required for getting an application working.

Reading with sesearch what some booleans do, it's clear I don't really need some of them, so they we disabled them. In example, we don't need nginx being able to connect to squid, ftp, gopher and memcache ports, among other things the boolean httpd_can_network_relay allows, because we pass our requests through sockets. Boolean httpd_can_network_connect its too broad for us, as the only port we need open, it's already labeled for redis and we have a very easy to understand policy module for that: https://security.stackexchange.com/a/172569/162749

I've struggled a bit to get some PHP scripts working, even after labeling carefully some public paths, in order to just allow writes from the webapp on uploads and caches for captchas directories, but not letting that upgrade magically by itself or download from third parties scripts that could be executed. Also, just allowing execution of scripts in specific paths.

I've already got this goals working and people outside from IT are working without complains, but I can't quite understand completely yet what the booleans I've had to enable are allowing, because the man pages are useful for quickly enable something but not understanding how the magic works. And the output from sesearch its just too confusing.

For example: sesearch -AC -b httpd_anon_write lets understand that only is allowing writes in public_content_rw_t labeled objects, but I still don't get why it was not working with httpd_sys_content_rw_t.

But, output for booleans httpd_unified and httpd_builtin_scripting are conflicting, and I'm frankly worried to allowing without need too much things. Specially on httpd_sys_rw_content_t labeled objects I couldn't get the writes to work without enabling both booleans, and I didn't enabled httpd_enable_cgi because permissions seem to broad for me. See the most confusing part:

DT allow httpd_t httpd_sys_rw_content_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; [ httpd_enable_cgi httpd_unified && httpd_builtin_scripting && ]

ET allow httpd_t httpd_sys_rw_content_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; [ httpd_builtin_scripting ]

Maybe it's that I don't get where is the AND and if there it is an OR, but I don't get why all operations are allowed according to the former rule, just enabling httpd_builtin_scripting, and why according the first rule, must be enabled that same boolean, AND httpd_unified AND httpd_enable_cgi.

Honestly I would be more than happy to not depend on any boolean that allow more than what it is strictly necessary, that's why I'd be grateful to get a hand helping me to understand the syntax of the booleans needed for a rule to be enabled.

FWIW, the webapp I'm securing is WordPress based, and the tutorials all around are depending on booleans without explaining why they are needed and what risks they introduce. My organization has a distaste for automatic upgrades for compatibility breaks too.

Answer 1

What exactly is your question?

Basically what i think sesearch is trying to tell you is that you have two options if you want to allow httpd_t type associated processes to "read write" httpd_sys_rw_content_t type associated "files"

Either you set these three:

• httpd_enable_cgi
• httpd_unified
• httpd_builtin_scripting

Or you set this one:

• httpd_builtin_scripting

Which obviously does not quite seem to make sense since the former is a super set of the latter. The policy author may or may not have made a mistake there.

The former set of booleans may have the same rules as the latter boolean as part of broader permissions. Your query was quite narrow and so it matched both scenarios

You could use sesearch to see what rules are associated with each of the booleans and then determine whether setting the first three or setting the latter one is in your favor

Granted that this seems to not be very intuitive, but sesearch gives you accurate and to the point info.

The web server policy used commonly by distributions aims to be a general purpose policy, and that makes it pretty complex and introduces some trade-offs. There are many different way's to use web servers. The booleans, and types give you some flexibility but if you want to have a policy that is tailored to your requirements then you can always choose to write your own policy for your web server. Unfortunately that might not be as easy as it should be but it is possible.

As for why things "did not work for you", I would have to see some AVC denials to be able to interpret the events and suggest solutions.