On 04/15/2016 07:50 PM, Michael Stephenson wrote: >> Hello Michael, >> >> the httpd_unified boolean is very powerfull boolean and basically turns >> SELinux protection off for httpd. I would go with a context which can be >> written by httpd_t - httpd_sys_rw_content for example. > > Thanks for the reply Miroslav! > > Your comment about using the http_unified boolean is very helpful. To be honest I was just using the recommendation from audit2allow based the input from the /var/log/audit/audit.log. I am not familiar with the httpd_sys_rw_content context. I will start reading up on that one now. > >> Also you specify local customizations, the semanage tool should be used >> and *.local file contexts will be updated. >> >> semanage fcontext -a -t httpd_sys_rw_content_t "/www/sites(/.*)?" >> > > About the .local file contexts, yes I used the semanage tool. Thanks for confirming the usage was the correct way to go about it. Looking at the content of the file it is easy to see how one could want to edit that file manually and skip using the tool, but I'm not that brave :) > > Here are my notes from how I used semanage, just for context. > > [...] > # We need to tell SELinux about the new location, grant permission and then recursive restorecon > semanage fcontext -a -t mysqld_db_t "/www/mysql(/.*)?" > > # Confirm the write to local selinux policy > grep -i mysql /etc/selinux/targeted/contexts/files/file_contexts.local > > # Might as well add the web directory too for httpd_sys > semanage fcontext -a -t httpd_sys_content_t "/www/sites(/.*)?" > > # Restore perms > restorecon -R -v /www > [...] > >> Also the question is if we need to add this label for the entire >> /www/sites directory and subdirectories or it just needs to access a >> subdirectory. > > This is a great question. To be honest, I was just looking for the all-encompassing rule to make sure that none of the websites that we plan on running from that location would not get blocked. I'm totally open to suggestion on how to improve. > > Here is a little more on the application/server. This is not a shared server, only primary business sites will be running on the box so there will not be many local user accounts - probably just one admin/root and the necessary nginx and mysql accounts. > > My plan to place everything in /www was a first draft just to get things moving. I wanted to have a small OS disk mount and a larger DATA disk mounted to streamline operations (e.g. backups/snapshots, new system clones, etc.). A second draft will probably be one that has 3 disks - OS, DB, DATA, but not ready to cross that bridge yet until I get everything going. > > That said, my current /web mount will store all the data necessary for our web applications - mysql db and application code. > > I have chose to organize all the domain web roots in the /www/sites directory in the following way: > > /www/sites/domain_one/html > /www/sites/domain_two/html > ... > /www/sites/domain_ten/html > > nginx will have permission over all 'html' dir in each domain folder. > > The applications we are running are common CMS and eCommerce app - Wordpress, Magento, Drupal, etc. > > Going back to answer your question "do we need to add this label for the entire www/sites directory and subdirectories, or can it be just the subdirectories," I'm not sure. Being that the domain names are random, I did not know if there was a way I could make sure the apps didn't get blocked each time we add a new domain - forcing us to revisit the *.local rules and add another exception. The logic I used to justify adding the label to all /www/sites was because root owns everything up to /html, and my thinking was that even if httpd_sys_content_t was allowed on all below /www/sites, it could not however, step into folders outside nginx ownership. I may completely wrong so please offer some guidance here. I am not linux security expert and I appreciate expert opinion and recommendations. > We can say something like "/www/sites/*/html(/.*)?" but the question is how they are created? If they are created by hand, we can restore labeling. If they are created on the fly, it is more complicated to make sure all labeling is correct. So I would go with labeling how I described above. > Thanks again for all your help so far. This is a great community! > > > > -- > selinux mailing list > selinux@xxxxxxxxxxxxxxxxxxxxxxx > http://lists.fedoraproject.org/admin/lists/selinux@xxxxxxxxxxxxxxxxxxxxxxx > -- Miroslav Grepl Senior Software Engineer, SELinux Solutions Red Hat, Inc. -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/selinux@xxxxxxxxxxxxxxxxxxxxxxx
