The context of init script (/etc/init.d/mysql) is system_u:object_r:mysqld_initrc_exec_t. When I run it, mysqld process has the context staff_u:sysadm_r:sysadm_t. If I change the /etc/init.d/mysql context to system_u:object_r:initrc_exec_t, mysqld process context is system_u:system_r:mysqld_t.
This is because the sysadm_t domain is quite privileged; it is allowed to execute any executable type (not always with a domain transition though). In this case, the sysadm_r role is *not* allowed to transition when executing mysqld_initrc_exec_t, so it runs the script as sysadm_t. As a result, everything that is triggered in the script will most likely remain running in sysadm_t. If mysqld is able to run in the sysadm_t domain, then that's actually a sad result of mysqld's permission requirements being a subset of what sysadm_t needs. In order to fix your issue, your best bet is to allow sysadm_t to administer mysqld service: ~# selocal -a "mysql_admin(sysadm_t)" -c "Allow sysadm admin on MySQL, bug 477752" -Lb Another approach would be to use run_init to execute the script: ~# run_init /etc/init.d/mysqld start or ~# run_init rc-service mysqld start I will later see if I can ensure that mysqld does *not* run in sysadm_t as this is, imo, a security violation.
(In reply to Sven Vermeulen from comment #1) > If mysqld is able to run in the sysadm_t domain, then that's actually a sad > result of mysqld's permission requirements being a subset of what sysadm_t > needs. Sorry I have a poor english, I don't understand very well what you would say. > In order to fix your issue, your best bet is to allow sysadm_t to administer > mysqld service: > > ~# selocal -a "mysql_admin(sysadm_t)" -c "Allow sysadm admin on MySQL, bug > 477752" -Lb I tried but I have an error : ~ # selocal -a "mysql_admin(sysadm_t)" -c "Allow sysadm admin on MySQL, bug 477752" -Lb ~/.selocal ~ Compiling strict selocal module /usr/bin/checkmodule: loading policy configuration from tmp/selocal.tmp selocal.te":10:ERROR 'syntax error' at token ';' on line 1302: role_transition { mysqlmanagerd_initrc_exec_t mysqld_initrc_exec_t } system_r; #line 10 /usr/bin/checkmodule: error(s) encountered while parsing configuration make: *** [tmp/selocal.mod] Erreur 1 ~ semodule: Failed on /root/.selocal/selocal.pp! > Another approach would be to use run_init to execute the script: > > ~# run_init /etc/init.d/mysqld start > or > ~# run_init rc-service mysqld start This approach works, mysqld runs in mysqld_t context. Also, I noticed that after a reboot, mysqld runs the good context mysqld_t. Have you a clue for the error I encountered when I try selocal ? Thanks.
I just saw, at http://www.gentoo-wiki.info/SELinux, that : ... - Gentoo prompts for a password when launch services in the /etc/init.d directory. If not asked, service may not be started in the proper domain. - Service must be (re)started in the sysadm_r role. Otherwise, the domain transition for the service may be denied, resulting in the service running in the wrong domain. ... So, when I try to launch 'rc-service mysql start', I'm root after have executed 'newrole -r sysadm_r' and 'su'. And my context is staff_u:sysadm_r:sysadm_t. Then, maybe the fact that mysqld runs with sysadm_t, when I launched it, is due to Gentoo which prompts for a password when I launch it ? As mysqld runs in the proper domain when the system boot, I don't if it's a bug or not... What do you think ?
That article makes little sense, or at least is dubious in how it can be interpreted. I tried to launch the MySQL service, as sysadm_u, but it failed: """ ~# /etc/init.d/mysql start -bash: /etc/init.d/mysql: Permission denied """ The mysql_initrc_exec_t is not an exec_type, just a file type, so sysadm_t is not allowed to execute it. The only reason I see that it might run in sysadm_t is when SELinux is in permissive mode rather than enforcing. If that is the case, then this is expected behavior: permissive mode only logs denials, it doesn't enforce them. Can you check (run "getenforce" or through "sestatus") what the SELinux state is? Also, http://www.gentoo.org/proj/en/hardened/selinux might be a better venue for documentation about SELinux and Gentoo.
Actualy, SELinux is in permissive mode until I resolve all denials... So if I understand, if I switch now in enforcing mode, I won't be able at all to launch an init script like /etc/init.d/mysql (with mysqld_initrc_exec_t) by this way : # rc-service mysql start So, I guess the good way, if I have to do it, to launch an init script is by this way : # run_init rc-service mysql start
Indeed; as long as you're in permissive mode, most of the bugs regarding the behavior are void as SELinux isn't enforcing anything. You might still see some differences between SELinux being fully disabled, and SELinux in permissive mode, but that is usually only with applications that "understand" SELinux and actively query it. On the *_initrc_exec_t scripts: it isn't that sysadm_t isn't allowed to execute any of them, only that he has only a subset of all supported daemons. A quick scan through the policy shows support for bacula, bind, nginx, ntp, openvpn, postfix, postgresql, puppet, rtorrent, samhain, cron, dovecot, rpc (nfs) and shorewall. There is no clear decision line in this though - the optimal solution would be to only support those domains that are critical for a system administrator to get the system itself working. So of the above daemons, I think only a very few make sense. In the (near) future, we might clean up those definitions (no ETA on that though, depends on how upstream tackles it). The sysadm_t user has the right to run run_init, which transitions the scripts to initrc_t anyway. So sysadm_t can always run "run_init rc-service mysql start". The other approach is to allow your SELinux user the "system_r" role (using "semanage user -m ...") and to grant the sysadm_t domain the proper _admin() interface (like the suggested "mysql_admin(sysadm_t)"). This way, sysadm_t can directly execute the scripts and they will transition to the right domain. I'll mark this bug as INVALID considering the permissive mode of SELinux; I hope the explanations above do help you understand it better. If you need more help, you can always join the gentoo-hardened@lists.gentoo.org mailinglist to discuss SELinux in Gentoo - always happy to see people wanting to secure their system more.
Thanks a lot, I better understand. I didn't see informations about this subject which is very interesting for comprehension, I think that deserves an update to the documentation. Regards.
I think the current paragraphs in the SELinux handbook suffice for now: """ Initially, SELinux is running in permissive mode, which means that SELinux will log what it would deny, but still let it through. This mode is perfect for getting the system in shape without having too much problems keeping it running. Once you think your security settings are in order, then this mode can be switched from permissive to enforcing. """ as well as the entire chapter on "Permissive, Unconfined, Disabled or What Not..."
