On 04/04/2012 12:27 PM, Mike Chan wrote:

>> *From:* Tam Nguyen <[log in to unmask]>
>> *To:* Mike Chan <[log in to unmask]>
>> *Cc:* zxq9 <[log in to unmask]>; "[log in to unmask]"
>> <[log in to unmask]>
>> *Sent:* Tuesday, April 3, 2012 2:29 PM
>> *Subject:* Re: soft link for web vhost
>>
>> Hey Mike,
>> congrat! zxq9's awesome rundown is a good start. Once you get the hang
>> of SELinux mode, your server would be secured at least couple of
>> notches. Just don't go crazy with "chconning", as zxq9 put it. For
>> practice- setup a test VM.
>>
>> Happy SELinux!
 >
 > Hi again,
 > sorry for asking many questions.
 > I mounted a remote server's nfs directory onto my local server directory
 > /mnt/NFSshare, then to create softlink of /mnt/NFSshare on vhost
 > directory, I followed the SELinux tutorial, but this time I got error:
 >
 > [root@techtle ~]# chcon -t httpd_sys_content_t /mnt/NFSshare
 > chcon: failed to change context of `/mnt/NFSshare' to
 > `system_u:object_r:httpd_sys_content_t:s0': Operation not supported

Hi Mike,

Next time put your message at the bottom, not the top -- its hard to 
read when the conversation skips like that (>.<)

Serving files from an NFS share via Apache can be a little weird. There 
are a few thinks to think about before doing this:

NFS shares are not always 100% predictable because of the way the 
protocol works sometimes. Sometimes a resource can be locked up by a 
process that indicates it is using it and never lets go (for whatever 
reason), and other times the share directory you are trying to serve 
might not be immediately available because the host system is down, the 
network has a problem (anything from address collisions to congestion to 
Godzilla), or the greater system isn't in total agreement with itself 
about what is shared and what is actually mounted at the given time.

What this means for Apache is that if Apache knows that a file is 
available and tries to serve it, but cannot pull it from the file system 
it may hang. Depending on how many worker processes you have (this is 
not the same as worker threads in this particular case) this could hang 
all web responses for all clients until the file-retrieval problem 
clears (really just an NFS problem in this case). That sucks.

Another issue is that SELinux contexts across NFS are set to "nfs_t" 
which is the blanket default for all NFS mounts. Apache is not allowed 
to look into nfs_t locations by default, for the same reason that Apache 
is not allowed to look into user_home_t locations by default: if someone 
cracks Apache or a web application running on Apache at the time 
(Drupal, Wordpress, anything else that ends in .php is a good candidate) 
then they might have access to anything that Unix file permissions would 
grant access to -- and this might not be good enough security depending 
on how you have Apache and your group permissions set up.

So the solution is a thing called SELinux booleans. These are specific 
yes/no policies which can be written per-action per-application, which 
is a handy way of permitting the system to maintain a default "no" 
policy against everything and then name just a few select actions by a 
few select processes that are exceptions to the default "deny 
everything" setting.

To see all of your SELinux booleans use the command "getsebool -a".

But that will give you a huge list. So you probably just want to see the 
ones that related to httpd (the Apache daemon). Here is mine:

[ceverett@taco ~]$ getsebool -a | grep httpd
allow_httpd_anon_write --> off
allow_httpd_mod_auth_ntlm_winbind --> off
allow_httpd_mod_auth_pam --> off
allow_httpd_sys_script_anon_write --> off
httpd_builtin_scripting --> on
httpd_can_check_spam --> off
httpd_can_network_connect --> on
httpd_can_network_connect_cobbler --> off
httpd_can_network_connect_db --> on
httpd_can_network_memcache --> off
httpd_can_network_relay --> off
httpd_can_sendmail --> off
httpd_dbus_avahi --> on
httpd_enable_cgi --> on
httpd_enable_ftp_server --> off
httpd_enable_homedirs --> off
httpd_execmem --> off
httpd_read_user_content --> off
httpd_setrlimit --> off
httpd_ssi_exec --> off
httpd_tmp_exec --> off
httpd_tty_comm --> on
httpd_unified --> on
httpd_use_cifs --> off
httpd_use_gpg --> off
httpd_use_nfs --> off

And... look at the last one there!

"httpd_use_nfs --> off" means that Apache can't read anything from an 
NFS share. So you can follow symlinks already, as per our last 
discussion, but the chain stops when you hit a "nfs_t" which you found 
already. But you can't change it easily with just "chcon"... so the 
answer is to do this:

setsebool httpd_use_nfs 1

There is one trick here, though. After boot, the default policies will 
be back in place, the same way that iptables settings would be if you 
don't save them to /etc/sysconfig/iptables.

To make an sebool change permanent, you need to use the -P switch like this:

setsebool -P httpd_use_nfs 1

The command may take a second to run, but once it has you should be able 
to mount an NFS share under /var/www/virtual/foo (or somewhere in your 
symlink chain if you have an NFS share mounted under /mnt/webstuff and a 
symlink from /var/www/virtual/foo to /mnt/webstuff) and then serve files 
from it.

That's a pretty long explanation, but the reason is SELinux. Most people 
don't understand that system well and often just turn it off or commit 
to permanent bad settings, so I think it is worth explaining at length. 
Every time I hear of a Linux web server compromise it is a web server 
running an insecure/unpatched version of a vulnerable php application 
(or sometimes just open to sql injection) with bad (read as 
"convenient") Apache settings and SELinux turned off or not installed at 
all. In every case I can recall the vulnerability was not actually in 
Linux or even in Apache, but in the app being served, and through a hole 
in that app the attacker was able to drive Apache to do his bidding or 
gain other access indirectly because Apache was not properly contained.

Hence the length of this response.

Hope this helped. Have fun!