mwic

Please Note: this is kinda tongue-in-cheek. If you have sensitive data on a machine, you need to learn SELinux. Sorry. Jeff’s Article “Stop Disabling SELinux!” is a good way to start. That said..

Dear Jeff,

As to your question: “why would you throw out the extra security by disabling it completely rather than configuring it to work with your application?”, you may find the answer right here in your own post:

“If you’re in a hurry to figure out how to configure SELinux for this particular type of setup… “

Being in a hurry is relative, of course, but to a certain extent we are *all* in a hurry with respect to this task.

The task I actually want to take time on and make sure to get right is:
Prototype the frontend for a nodeJS application. I am not in a hurry with respect to that task.

But here comes SELinux with another task for me:
"type=AVC msg=audit(1365516156.929:3050): avc: denied { getattr } for pid=20263 comm="httpd" path="/home/mwic" dev="sda7" ino=16384001 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=dir"

This, of course, is “SELinux giberish language” (Jeff’s words) for “apache can’t do stuff with that directory”

Now, I’ve *already* (starting in 2009 or so) paid some of my SELinux noob dues:
chmod +x /home/mwic
chgrp -R apache /home/mwic/devSites
chmod -R 755 /home/mwic/devSites/FEPrototype

… which are the sorts of things you started with in 2009 when you got “403 Forbidden”s on new virtual hosts. Then you learned what SELinux was, kinda, and began including “setenforce 0″ into your routine.

Now, in 2013, you feel bad about that. You also have an unsettling feeling that you’re going to get an STD or something without SELinux wrapped around your you-know-what.

You have learned that restorecon and getsebool/setsebool are (part of) the right way to do stuff like this, and you want the SELinux gibberish equivalent of the chmod/chgrp that you’re used to.

Though your virtual host docRoot is /home/mwic/devSites/FEPrototype, that’s not the dir that /var/log/audit/audit.log is complaining about, so you start at the top.

You offer a quick prayer that systemd is not involved.

Besides “/home/mwic”, the only other clues you get from the audit log are “getattr” and “httpd”

cd /home/mwic
getsebool -a | grep attr
selinuxuser_rw_noexattrfile --> on


At first glance, you’re like “I doubt it.” But you’re *really* trying to do the right thing here, so you doublecheck and find

“If you want to allow user to r/w files on filesystems that do not have extended attributes (FAT, CDROM, FLOPPY), you must turn on the selinuxuser_rw_noexattrfile boolean.”

Sweet. That is, um, probably not what’s wrong with your VHost. Next:


getsebool -a | grep http

httpd_anon_write --> off
httpd_builtin_scripting --> on
httpd_can_check_spam --> off
httpd_can_connect_ftp --> off
httpd_can_connect_ldap --> off
httpd_can_connect_zabbix --> off
httpd_can_network_connect --> off
httpd_can_network_connect_cobbler --> off
httpd_can_network_connect_db --> off
httpd_can_network_memcache --> off
httpd_can_network_relay --> off
httpd_can_sendmail --> off
httpd_dbus_avahi --> off
httpd_enable_cgi --> on
httpd_enable_ftp_server --> off
httpd_enable_homedirs --> off
httpd_execmem --> off
httpd_graceful_shutdown --> on
httpd_manage_ipa --> off
httpd_mod_auth_ntlm_winbind --> off
httpd_mod_auth_pam --> off
httpd_read_user_content --> off
httpd_run_stickshift --> off
httpd_setrlimit --> off
httpd_ssi_exec --> off
httpd_sys_script_anon_write --> off
httpd_tmp_exec --> off
httpd_tty_comm --> off
httpd_unified --> off
httpd_use_cifs --> off
httpd_use_fusefs --> off
httpd_use_gpg --> off
httpd_use_nfs --> off
httpd_use_oddjob --> off
httpd_use_openstack --> off
httpd_verify_dns --> off

Have fun. Those of you who already know the answer are, of course, smiling. You already know that audit.log is not really where you want to be. /var/log/messages will guide you:

“SELinux is preventing /usr/sbin/httpd from getattr access on the directory /home/mwic. For complete SELinux messages. run sealert -l 2b2fc258-fae7-4f15-809e-a9a504f4240f”

and that command feels like a friendly voice who knows you very well:

“If you want to allow httpd to read user content
Then you must tell SELinux about this by enabling the ‘httpd_read_user_content’ boolean.”

There is, unfortunately, nothing in here about the apparent need for the “-P” option.

setsebool httpd_read_user_content 1

didn’t work, so I googled and found that most posts had

setsebool -P httpd_read_user_content 1

as their example. This also did not work, for me. Maybe it works for you.

I threw in the towel. I moved the devSites/FFPrototype/ directory into /var/www , symlinked it “html”, and got on with my life. Now I have a single virtual host setup.

Close readers will notice that I did *not* disable SELinux! When I feel like wasting another couple hours on this, I will move the directory back into my /home and try restorecon commands and stuff like that, but my feeling is that there’s now something wrong with the actual httpd.conf and the VirtualHost in question. This VHost block was copied from Fedora 17 to Fedora 18, and that is evidently not a clean migration.

For people who are “in a hurry”, I recommend this:

Disable SELinux