[CentOS] httpd ssl problems

[James Hogarth]

> It's always selinux ;-)
>
> If you install the selinux utilities (policycoreutils-python) then you
> can use them to set up the security polices. Look in
> /var/log/audit/audit.log for the offending lines and then use commands
> like this, for example this is what I had to do to allow mysqld to
> run:
>
>         sudo audit2allow -a -m mysqld > /tmp/mysqld.te
>         sudo checkmodule -M -m /tmp/mysqld.te -o /tmp/mysqld.mod
>         sudo semodule_package -o /tmp/mysqld.pp -m /tmp/mysqld.mod
>         sudo semodule -i /tmp/mysqld.pp
>


Well always when you step outside normal practices...

Where did you install that mysql from by the way as the base policy has
mysql contexts and policies in place...

In general your advice would work but it's bad practice...

The above assumes what you want the application is trying to do is what you
want to happen - this is probably not quite the case.

For the OP it's likely to be the context of the certificates where you put
them... copy them (not move) to somewhere like /etc/httpd so they get the
context httpd_etc_t (in the alternative make a dedicated /etc/httpd/certs
directory to support multiple certs for virtualhosts with a context of
cert_t as this howto describes
http://www.freeipa.org/page/Apache_SNI_With_Kerberos)...

The http_t domain has permission to read that context type so that will
work properly and the various bits restricted appropriately...

As for your mysql I'm guessing it installed to /opt or /usr/local or had a
version number in place such as /var/lib/mysql55 which took the files out
of the standard locations and consequently the file contexts would have
been incorrect as they would have inherited from those other locations
probably resulting in mysqld in the wrong domain too (initrc_t perhaps or
bin_t depending how it was started). Using the audit2allow -a -M etc method
outlined above would then result in mysqld having too broad access or
possibly other processes getting access to the mysql database files or
config files improperly (depending on how the auto generated rule went).

To fix that scenario given that the base selinux policy already has rules
for mysql all you need to do is ensure that the right file contexts are on
the files in the improper locations.

First use semanage fcontext -l | grep mysql to get a list of all file
contexts related to mysql.

Then for each of these (there's only about 21) check to see where you
custom install has put the equivalent file (eg /usr/libexec/mysqld might be
in /usr/local/bin/mysqld or /opt/mysql/bin/msqld).

With that knowledge in hand simply copy and paste the context to the new
file for example:

original from the list above:    /usr/libexec/mysqld            regular
file       system_u:object_r:mysqld_exec_t:s0

Add your new path:
semanage fcontext -a -t mysqld_exec_t '/usr/local/bin/mysqld' && restorecon
-Rv /usr/local/bin/mysqld

With the correct contexts on the files you should then be able start the
service and it'll be properly confined in its correct domain.