On Wed, Jul 10, 2013 at 12:23 PM, James Hogarth <james.hogarth@xxxxxxxxx> wrote:
>> 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...
I got from just doing 'yum install mysql' I don't have access to that
system any more to see where it got installed.
>
> 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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
