Posts tagged selinux
I recently ran into a situation where I needed to grant access to certain /home dirs in order to get puppetmaster started with SELinux enforcing. And I had to do it in such a way that I could keep the resulting “type enforcement” (.te) file in version control, this would allow me to track human readable changes.
$ -> cd ~ $ -> echo > /var/log/audit/audit.log # this ensures a clean log for analysis $ -> /etc/init.d/puppetmaster start # should fail $ -> audit2allow -i /var/log/audit/audit.log -m puppetmaster # this will output the perms necessary for puppetmaster to access needed resources, copy and paste this into the file you are using in version control $ -> checkmodule -M -m -o puppetmaster.mod /path/to/your/version/controlled/puppetmaster.te # this will create a .mod file $ -> semodule_package -m puppetmaster.mod -o puppetmaster.pp # this will create a compiled semodule $ -> semodule -i puppetmaster.pp # this will install the module
At this point, you have added a custom puppetmaster selinux module which will allow you to get through the first issue discovered when trying to start the service. From here there are one of two course of action, depending on whether the service starts or not. If the service starts, you are done. If the service does not start, you will need to repeat the above steps to determine which new permissions are required to allow the service to start, rinse and repeat until your service starts.
Currently I am working on a project to centralize all syslog entries into one server and have been running into issues due to the fact that I run SELinux and store the rsyslog.conf file in version control. By default you can tail the /var/log/audit/audit.log to see what’s going on, but the message is fairly encrypted and not easily understood. After some research there is an executable sealert which will parse the audit log and convert the messages into human readable format. sealert does not get installed by default on CentOS systems, so you have to do:
yum install setroubleshoot-server
After the install is completed, you can then analyze the audit log by issuing the following command:
sealert -a /var/log/audit/audit.log > /var/log/audit/audit_human_readable.log
It took a few seconds to analyze, but upon completion I was able to open the human readable version, and see entries like:
-------------------------------------------------------------------------------- SELinux is preventing /sbin/rsyslogd from search access on the directory /home. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that rsyslogd should be allowed search access on the home directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep rsyslogd /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp
So I was able to create the audit policy to allow rsyslogd the access it needed to the config file in order to run properly.
As mentioned in an earlier post, I have been actively working on melikedrinks.com, as such I am constantly adding new drink inventory which means I have to generate a new sitemap on a fairly regular basis. Today I generated a new sitemap and tried to submit it via Google Webmaster Tools, but upon submission I received a 403 (forbidden error). At first I couldn’t figure out why this was happening, the permission on the sitemap file (and associated dirs) was 664 (775), so apache definitely had access to the file. So I check the apache error log and noticed the; Permission denied: file permissions deny server access: entry. So after a few minutes of rechecking the file permissions, I remembered that I have SELinux enabled and enforcing, so I do a `ls -lZa` and sure enough, the permission type was user_tmp_t when it should have been httpd_sys_rw_content_t. Then I had the aha moment, when the sitemap file is generated it is dropped in the /tmp dir, so I just did a copy from /tmp to the production path, but forgot to change the permission type.
Heres the command I ran to change the permission type:
$ -> sudo chcon -R -v -t httpd_sys_rw_content_t sitemap.xml
Now when I do `ls -lZa`, the permission type is correctly set to httpd_sys_rw_content_t, and when I resubmitted the sitemap to Google Webmaster Tools, everything worked as expected.
If you are attempting to start apache (httpd) and get permission denied errors, chances are your SELinux is enabled, and not configured to allow httpd connections. Use the following commands to get your httpd working.
# To view current selinux settings related to httpd: getsebool -a | fgrep -i httpd # To "pinhole" SELinux to allow httpd to start correctly: setsebool -P httpd_can_network_connect 1 setsebool -P httpd_enable_homedirs 1