I'm considering the usage of SELinux for several lamp (linux+apache+mysql+php) servers. I have tested SELinux in a virtual machine and have configured some basic rules (allow PHP, email, etc.) and for the moment all seems to work pretty good. But I'm concerned that I have overlooked some pitfalls. What are the some common problems of enabling SELinux for LAMP servers which are easy to overlook?

  • 1
    This is a pretty broad question. Can you narrow it down any? – schroeder Aug 9 '17 at 10:18
  • It would be nice to know a bit of your configuration in a way we can examine it and giving concrete advice. I'm offering my two cents in my answer. – Jesús Franco Oct 31 '17 at 17:12

If you've regression tested everything and not encountered any unsurmountable issues, then great, however my experience is the opposite of TorstenS - I think it results in a net decrease in the security of your system except in the specific scenarios (and "LAMP server" is unlikely to fall into that category) listed in the linked post.

To summarize - the complexity, opaque abstraction and poor documentation make it very difficult to understand the implementation and to adapt it to specific purposes. There is little evidence that even an expertly configured installation is more secure than a system not enforcing a policy. While intrinsically it is unlikely to increase your attack surface, it is likely that solving the functionality an performance impacts it introduces (i.e. compromising the off-the-shelf policy supplied by your vendor) will undermine the overall security of the system in ways you don't understand.


You should be aware that enabling SELinux potentially makes your Server more secure than it would be if it was disabled. But it never is a "one click hardening".

  • 1
    This doesn't really seem like an answer, and it's not true anyway. It is theoretically possible for SELinux to reduce security (increased attack surface, applications failing in potentially unsettling ways, etc), even if it's not common. – forest Dec 1 '17 at 11:05

As schroeder says, it's too broad. However I'd like to add two bits of concrete comparison of the setroubleshoot plugins giving bad clues on security.

First example, network ports web server is allowed to connect. I set redis as the session store rather than files for PHP. I prefer connecting through TCP port rather than socket. Thus, the advice given by sealert is turning on httpd_can_network_connect boolean. But it is better just allow the specific port, in this case, redis_port_t, and not every port:

module httpd_connect_redis 1.0.0;

require {
    class tcp_socket { name_connect };
    type httpd_t;
    type redis_port_t;

allow httpd_t redis_port_t:tcp_socket name_connect;

Second example, a sadly not so uncommon case of Plesk configuring Apache and NginX to run in tandem, with the former as the reverse proxy. Plesk configures Apache to run on ports 7080 and 7081, without reserving that same ports in a custom policy, let's not talk right now about setting php-fpm binaries as unconfined services (Bad Plesk, very bad).

If I'd follow setroubleshoot advice, I'd allow NginX name_connect to any unreserved_port, or any other port enabling the boolean httpd_can_network_connect, and not only 7080 and 7081. Instead, it was a little more work, but as in the case of redis port, I've built a custom type to tag that two ports, and then shutting off audit messages, because I am not really using Apache at all to run my webapps and just using Plesk because my boss thinks is a way he can see how the domains are configured. Anyway, it's not so hard writing a basic policy to create custom labels for custom ports, and setting just the permissions you need and not opening everything quickly as the booleans allow, but running everything unrestricted it's not better than having SELinux disabled.

module plesk_disallowed_apache_proxy 1.1.0;

type plesk_apache_behind_proxy_port_t;
require {
    class tcp_socket { name_connect name_bind };
    attribute port_type;
    type httpd_t;
typeattribute plesk_apache_behind_proxy_port_t port_type;

dontaudit httpd_t plesk_apache_behind_proxy_port_t:tcp_socket name_connect;
dontaudit httpd_t plesk_apache_behind_proxy_port_t:tcp_socket name_bind;

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.