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(a)lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/selinux@lists.fedoraproject.org
--
Miroslav Grepl
Senior Software Engineer, SELinux Solutions
Red Hat, Inc.