发一个关于SElinux和mysqld的问题，请牛人解答一下

大冒牌货

前提：（绝对别修改以下任一参数）
    SELINUX=Enforcing
    SELINUXTYPE=targeted
    mysqld_disable_trans=0

我的MySQL版本：4.1.12-1

启动MySQL服务时在/var/log/messages中看到：
XXXXXXXX kernel: audit(1123839660.017:0): avc:  denied  { read } for  pid=2906 exe=/usr/sbin/mysqld name=passwd dev=hda1 ino=768854 scontext=user_u:system_r:mysqld_t tcontext=system_ubject_r:shadow_t tclass=file，很明显mysqld_t域是不能操作（读）shadow_t域的文件，也就是说不能读/etc/passwd等文件。
如果编辑/etc/selinux/targeted/src/policy/domains/program/mysqld.te文件，插入一行：
allow mysqld_t shadow_t:file getattr
然后转到/etc/selinux/targeted/src/policy/执行：
make clean
make reload
又会报named.te的语法错误然后中止。
如果把mysqld_disable_trans的值改为1，那又绝对不是解决之道！因为大家一眼就能看出其中的安全隐患：
    ps -efZ|grep mysql
root:system_r:unconfined_t      root      6961     1  0 21:43 pts/0    00:00:00 /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --pid-file=/var/lib/mysql/XXXXXXXX.pid
root:system_r:unconfined_t      mysql     6982  6961  2 21:43 pts/0    00:00:00 /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-file=/var/lib/mysql/XXXXXXXX.pid --skip-locking
......
root:system_r:unconfined_t      mysql     6991  6983  0 21:43 pts/0    00:00:00 /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-file=/var/lib/mysql/XXXXXXXX.pid --skip-locking
root:system_r:unconfined_t      root      6998  3855  0 21:44 pts/0    00:00:00 grep mysql
其中的unconfined_t不是mysqld_t，这怎么能行！

其它一些相关信息：
    selinux-policy-targeted-sources-1.17.30-3.16
    selinux-policy-targeted-1.17.30-3.16
    /var/lib/mysql/中各文件属性均为rootbject_r:mysqld_db_t或system_ubject_r:mysqld_db_t
    /usr/bin/mysql*各文件属性为：system_ubject_r:bin_t
    /usr/sbin/mysqld属性：system_ubject_r:mysqld_exec_t
以上这些是绝对不应有问题的。

哪位仁兄给个解决之道（千万别给我英文的，俺的E文水平特次！），急切企盼中！

飘雪心辰

为什么不用红帽自带的mysql版本，如果要用3.23.58版本的能被SELinux罩住的，红帽也有。美国国家安全局的人也不是吃醋的，Flask相当的复杂。
你的问题偶也不知，如果你想要mysql被规则罩住，最好选用红帽提供的RPM包。我有个例子，自已从网上拉了个tomcat,SELinux的参数也为enforcing,targeted。但是令我想不到的是放到/home目录下运行报错，结果挪到/opt目录下就可以了。我只能得出一个结果在此参数下，即便是unconfined_t域也会受到一些限制，并不向红帽所说的unconfined_t域不受限制。

大冒牌货

呵呵，前几天出差刚刚回来。感觉涉及到这个问题的人是不是太少了啊！
请问楼上Mysql3.23.58在不更改上述参数的情况下能一切正常吗？和4.1.12-1安装后有什么区别？

***********************
..............行深般若波罗密多................

大冒牌货

我刚才又重新安装Mysql，装的就是红帽自带的Mysql，装完后并没有mysqld起来的迹象。
于是： service mysqld start
Timeout error occurred trying to start MySQL Daemon.
启动 MySQL：                                               [失败]

看来不像楼上所说啊！

大冒牌货

我搞错了一个问题：/etc/passwd应该是etc_t，不是shadow_t。
重新启动MySQL服务虽会在/var/lib/mysql下创建mysql.sock，但还是失败！
在/var/log/messages中会看到多行如下信息：
Aug 23 09:04:57 XXXXXXXX last message repeated 46 times
Aug 23 09:04:57 XXXXXXXX kernel: audit(1124759097.503:0): avc:  denied  { execmem } for  pid=4317 comm=mysqld scontext=root:system_r:mysqld_t tcontext=root:system_r:mysqld_t tclass=process
这又是怎么回事呢？

飘雪心辰

刚才收邮件看到有人回复。

既然是红帽自带的绝不会有问题，你先把 mysql相关的全部卸掉，再重新安装相应的包，记住把/var/lib/mysql目录也一并删除。再重新安装包。你的一个错误可看一条语句在/etc/init.d/mysqld文件中：RESPONSE=`/usr/bin/mysqladmin -uUNKNOWN_MYSQL_USER ping 2>&1` && break
大不了用root帐号试一下，我在RHEL-AS-4.0 下用红帽的3.23.58 版本也没问题，首先要得到 RPM源码包（去挑FC3的，这样能被SELinux罩住），在RHEL4.0下编译，我编译后得到的一些包为：
-rw-r--r--  1 root root 3349444 Jun 15 21:37 mysql-3.23.58-16.FC3.1.i386.rpm
-rw-r--r--  1 root root  541535 Jun 15 21:37 mysql-bench-3.23.58-16.FC3.1.i386.rpm
-rw-r--r--  1 root root 5646715 Jun 15 21:37 mysql-debuginfo-3.23.58-16.FC3.1.i386.rpm
-rw-r--r--  1 root root  579778 Jun 15 21:37 mysql-devel-3.23.58-16.FC3.1.i386.rpm
-rw-r--r--  1 root root 1393437 Jun 15 21:37 mysql-server-3.23.58-16.FC3.1.i386.rpm

stoneme

我估计自还的也有问题，
因为是：它为什么要读passwd文件呢？这不是很不安全吗？
我在FC4上安的5.0.7好着呢，网站上一般是建议你用高版本的，至少也用个4.X什么的，
再有就是你的目录不应该是mysql:.......吗？

stoneme

1，你的MYSQL没有用selinux保护，安装自带的应该也行，不过自已编译也没问题，你既然安了source进去看一下mysql.fc不就知道哪些目录或文件用哪些_t了吗？设一下不就OK了？

2，你本来要保护mysql是为了安全可又要让它读passwd这太不可思议了，只有root和特权管理员才让读，每个人都读还有什么安全性，基本的用户口令都保不住。

3，你自己既然都会去改target了，语法错的问题就应该自己能解决，不过我认识让mysql用户去读passwd和shadow应该不是语法错的范畴。（一般情况下写程序时，一句话的结尾应该加“;”）

大冒牌货

这段时间工作过分忙，以至于这个问题至今还没有解决。
等我闲了会去认真看mysql.fc的，多谢指教！
不过我认为：mysql是不会去读passwd的，而是mysqld。mysqld读passwd应该是由参数--user=mysql引发的吧。它读passwd也仅是为了验认当前系统内有没有mysql这个用户及组吧？

还请诸位对这个问题熟悉的老兄老弟老姐老妹不吝赐教！
老菜鸟（永远的老菜鸟）我在此先行谢过！

stoneme

mysqld 的--user=mysql应该去到mysql.user表里找不应该用 passwd文件的。
mysql都是自己验证的，即使退一万步---用到系统验证，它也应该把验证交给系统进程去作，绝不应该自己去作这种事情。

大冒牌货

    

# ps -efZ|grep mysql
root:system_r:unconfined_t      root      4298     1  0 20:12 ?        00:00:00 /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --pid-file=/var/lib/mysql/XXXXXXXX.pid
root:system_r:mysqld_t          mysql     4319  4298  0 20:12 ?        00:00:00 /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-file=/var/lib/mysql/XXXXXXXX.pid --skip-locking
......
root:system_r:mysqld_t          mysql     4328  4320  0 20:12 ?        00:00:00 /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-file=/var/lib/mysql/XXXXXXXX.pid --skip-locking
root:system_r:unconfined_t      root      4364  4346  0 20:12 pts/0    00:00:00 grep mysql


    

说来惭愧，没想到这个问题这么简单！这也是我今天开了窍了！
看一下我改过的/etc/selinux/targeted/src/policy/policy.conf其中的一行：

allow mysqld_t self:process { { sigchld sigkill sigstop signull signal execmem} fork };

和原来的文件有什么不同大伙看出来了吧！
然后make reload即刻搞定！

虽说飘雪心辰和stoneme两位兄弟没真正帮上忙，但我还是要真诚地说声“谢谢！”

gugong

RH 自带的 mysql-server 可以在

SELINUX=Enforcing
SELINUXTYPE=targeted
mysqld_disable_trans=0

下运行，我测试了一下。

1ball

我的fc3也遇到和楼主一样的问题

是原来默认的policy不对吗？因为定policy的人没想到？还是mysqld自身的行为不正确？

大冒牌货

当然是policy的问题了！它没定义mysqld的execmem．
再看一下policy中的unconfined_t吧！它可以做execmem的操作．