[Discuss] apache problem

[Anderson, Charles R]

On Wed, Jan 09, 2019 at 10:49:51AM -0600, Derek Martin wrote:
> On Tue, Jan 08, 2019 at 06:44:59PM -0500, James Cassell wrote:
> > Please don't disable SELinux.
> 
> Why?  Can you make a compelling case?

I'll try.

Over the years some misinformed people have suggested "fixing"
permissions by doing this (or variations), but it is not recommended:

chmod -R a+rwx /

Disabling SELinux is in the same vein.

> Though, TBH my money would be on SELinux being the problem.  I've long
> ago come to the conclusion that it's just too complicated a solution,
> and unless you're configuring services for an environment that
> requires a very high level of security, you're better off just
> disabling it outright.  It's caused me multiple days of head
> scratching over the years, and I think it's mostly just more trouble
> than it's worth outside of very specialized situations.

Maybe the SELinux coloring book would help with understanding the
basic concepts:

https://people.redhat.com/duffy/selinux/selinux-coloring-book_A4-Stapled.pdf

SELinux has come a long way towards ease of use, with most things
being correct "out of the box" as long as you don't do anything too
non-standard.  If you do want/need non-standard setups, then yes,
there is some extra work involved.  But check to see if someone else
has already provided an easy mechanism for handling your use case--it
may not be as non-standard as you think (see SELinux booleans below).
Apache serving home directories is one such case.

90% of problems with SELinux can be avoided by using standard
directory paths which already have the correct SELinux types defined:

sudo semanage fcontext -l

and relabeling the filesystem (especially if you've ever run with
SELinux completely disabled for even a single boot, you need to
relabel the entire filesystem afterwards):

touch /.autorelabel && reboot

If you need to use non-standard directory paths to store your data,
you can add a file context to cover that file path.  From the
semanage-fcontext manpage:

 remember to run restorecon after you set the file context
       Add file-context for everything under /web
       # semanage fcontext -a -t httpd_sys_content_t "/web(/.*)?"
       # restorecon -R -v /web

There are also SELinux booleans which can enable/diasble certain
features/permissions.  To list them:

getsebool -a
sudo semanage boolean -l

Many are self-explanatory. Here are the httpd-related ones:

httpd_anon_write               (off  ,  off)  Allow httpd to anon write
httpd_builtin_scripting        (on   ,   on)  Allow httpd to builtin scripting
httpd_can_check_spam           (off  ,  off)  Allow httpd to can check spam
httpd_can_connect_ftp          (off  ,  off)  Allow httpd to can connect ftp
httpd_can_connect_ldap         (off  ,  off)  Allow httpd to can connect ldap
httpd_can_connect_mythtv       (off  ,  off)  Allow httpd to can connect mythtv
httpd_can_connect_zabbix       (off  ,  off)  Allow httpd to can connect zabbix
httpd_can_network_connect      (off  ,  off)  Allow httpd to can network connect
httpd_can_network_connect_cobbler (off  ,  off)  Allow httpd to can network connect cobbler
httpd_can_network_connect_db   (off  ,  off)  Allow httpd to can network connect db
httpd_can_network_memcache     (off  ,  off)  Allow httpd to can network memcache
httpd_can_network_relay        (off  ,  off)  Allow httpd to can network relay
httpd_can_sendmail             (off  ,  off)  Allow httpd to can sendmail
httpd_dbus_avahi               (off  ,  off)  Allow httpd to dbus avahi
httpd_dbus_sssd                (off  ,  off)  Allow httpd to dbus sssd
httpd_dontaudit_search_dirs    (off  ,  off)  Allow httpd to dontaudit search dirs
httpd_enable_cgi               (on   ,   on)  Allow httpd to enable cgi
httpd_enable_ftp_server        (off  ,  off)  Allow httpd to enable ftp server
httpd_enable_homedirs          (off  ,  off)  Allow httpd to enable homedirs
httpd_execmem                  (off  ,  off)  Allow httpd to execmem
httpd_graceful_shutdown        (off  ,  off)  Allow httpd to graceful shutdown
httpd_manage_ipa               (off  ,  off)  Allow httpd to manage ipa
httpd_mod_auth_ntlm_winbind    (off  ,  off)  Allow httpd to mod auth ntlm winbind
httpd_mod_auth_pam             (off  ,  off)  Allow httpd to mod auth pam
httpd_read_user_content        (off  ,  off)  Allow httpd to read user content
httpd_run_ipa                  (off  ,  off)  Allow httpd to run ipa
httpd_run_preupgrade           (off  ,  off)  Allow httpd to run preupgrade
httpd_run_stickshift           (off  ,  off)  Allow httpd to run stickshift
httpd_serve_cobbler_files      (off  ,  off)  Allow httpd to serve cobbler files
httpd_setrlimit                (off  ,  off)  Allow httpd to setrlimit
httpd_ssi_exec                 (off  ,  off)  Allow httpd to ssi exec
httpd_sys_script_anon_write    (off  ,  off)  Allow httpd to sys script anon write
httpd_tmp_exec                 (off  ,  off)  Allow httpd to tmp exec
httpd_tty_comm                 (off  ,  off)  Allow httpd to tty comm
httpd_unified                  (off  ,  off)  Allow httpd to unified
httpd_use_cifs                 (off  ,  off)  Allow httpd to use cifs
httpd_use_fusefs               (off  ,  off)  Allow httpd to use fusefs
httpd_use_gpg                  (off  ,  off)  Allow httpd to use gpg
httpd_use_nfs                  (off  ,  off)  Allow httpd to use nfs
httpd_use_openstack            (off  ,  off)  Allow httpd to use openstack
httpd_use_sasl                 (off  ,  off)  Allow httpd to use sasl
httpd_verify_dns               (off  ,  off)  Allow httpd to verify dns
mysql_connect_http             (off  ,  off)  Allow mysql to connect http
named_tcp_bind_http_port       (off  ,  off)  Allow named to tcp bind http port
prosody_bind_http_port         (off  ,  off)  Allow prosody to bind http port

Finally, if you really can't get something working and you just need
it to work NOW you can put SELinux into Permissive mode--but that
should be temporary to allow you to troubleshoot the problem and fix
the root cause.  Using Permissive mode means you won't lose the
SELinux labels on files like you do if you completely disable SELinux:

To temporarily disable enforcement:

sudo setenforce 0

To reenable enforcement:

sudo setenforce 1

To make the setting persistent for next boot, edit
/etc/selinux/config:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of these two values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected. 
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted 

Some other basics:

To list file and process contexts, just add the "-Z" option:

ls -lZ
ps -Z

To check the logs for denials:

ausearch -m avc

or:

grep -i avc /var/log/audit/audit.log

To make sense of the logs:

ausearch -m avc | audit2why

To create a local policy module to allow something that is being denied:

https://danwalsh.livejournal.com/24750.html


> [I'm also largely of the opinion that if your system is otherwise
> secure, extended ACLs of any sort are unnecessary, and Unix
> permissions suffice just about always, excepting cases when you have a
> very large number of users with a very large number of disparate
> access needs to resources. And usually, even then.]

Well, if your system is so secure, no one else logs in, and you don't
have any kind of shared-tenancy, you don't need file permissions
either and you could just always log in as root and run all servers as
root, but again none of this is recommended.  Because no system is
totally secure.  Defense-in-depth is why we have and use separate
login/service accounts, standard Unix permissions (Discretionary
Access Control), and SELinux (Mandatory Access Control).  It is for
when something unexpected happens, like a new 0-day exploit is
discovered in Apache and you don't patch it in time.

Search google for "selinux prevented exploits" to see examples.

> Nothing I've seen or read about in my ~25 years of managing Linux
> systems has yet convinced me otherwise.

I encourage all my competitors to not run SELinux on their systems :-)