Running the mysql command as a mortal user dies:
$ mysql -hlocalhost -u MMMMMM -p MMMMMM Enter password: ERROR 2002: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (13)
after throwing this avc message: May 24 21:34:19 pink kernel: audit(1085448859.069:0): avc: denied { search } for pid=4519 exe=/usr/bin/mysql name=mysql dev=dm-6 ino=129035 scontext=user_u:user_r:user_t tcontext=system_u:object_r:mysqld_db_t tclass=dir
It's not able to search /var/lib/mysql to find the socket...
A (slightly edited) grep shows us:
[/etc/security/selinux/src/policy]3 find . | xargs grep mysqld_var_run | more ./domains/program/apache.te:allow httpd_php_t mysqld_var_run_t:dir { search }; ./domains/program/apache.te:allow httpd_php_t mysqld_var_run_t:sock_file { write }; ./domains/program/mysqld.te:allow mysqld_t mysqld_var_run_t:sock_file create_file_perms; ./domains/program/mysqld.te:allow initrc_t mysqld_var_run_t:sock_file write; ./domains/program/mysqld.te:allow logrotate_t mysqld_var_run_t:dir search; ./domains/program/mysqld.te:allow logrotate_t mysqld_var_run_t:sock_file write; ./file_contexts/program/mysqld.fc:/var/run/mysqld(/.*)? system_u:object_r:mysqld_var_run_t ./file_contexts/file_contexts:/var/run/mysqld(/.*)? system_u:object_r:mysqld_var_run_t
Does anybody see a good reason why we don't have this too:
mysqld.te: allow mysql_cmd_t mysqld_var_run_t:dir search; mysqld.te: allow mysql_cmd_t mysqld_var_run_t:sock_file write;
and add this to mysqld.fc:
/usr/bin/mysql system_u:object_r:mysql_cmd_t
(or the correct version thereof, it's way too late to think straight.. ;)
On Tue, 25 May 2004 12:15, Valdis.Kletnieks@vt.edu wrote:
Running the mysql command as a mortal user dies:
$ mysql -hlocalhost -u MMMMMM -p MMMMMM Enter password: ERROR 2002: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (13)
after throwing this avc message: May 24 21:34:19 pink kernel: audit(1085448859.069:0): avc: denied { search } for pid=4519 exe=/usr/bin/mysql name=mysql dev=dm-6 ino=129035 scontext=user_u:user_r:user_t tcontext=system_u:object_r:mysqld_db_t tclass=dir
How should we determine who gets mysql client access? Should we have a tunable determining whether we allow userdomain?
It's not able to search /var/lib/mysql to find the socket...
A (slightly edited) grep shows us:
Does anybody see a good reason why we don't have this too:
mysqld.te: allow mysql_cmd_t mysqld_var_run_t:dir search; mysqld.te: allow mysql_cmd_t mysqld_var_run_t:sock_file write;
and add this to mysqld.fc:
/usr/bin/mysql system_u:object_r:mysql_cmd_t
Why have mysql_cmd_t instead of just allowing user_t directly? What is the benefit in having a domain for client access?
On Wed, 26 May 2004 14:17:40 +1000, Russell Coker said:
How should we determine who gets mysql client access? Should we have a tunable determining whether we allow userdomain?
That might be a good solution..
Why have mysql_cmd_t instead of just allowing user_t directly? What is the benefit in having a domain for client access?
Thinko on my part - I invented the cmd_t because I'd been fighting various issues for about 14 hours at that point, and didn't parse through mysqld.te, apache.te, and mysqld.fc sufficiently to realize that the var_run_t was identical in semantics (somehow, I was convince that var_run_t included something I didn't want in cmd_t, but that was wrong).
How do people feel about the attached patch to add a tunable?
On Thu, 27 May 2004 02:26, Valdis.Kletnieks@vt.edu wrote:
On Wed, 26 May 2004 14:17:40 +1000, Russell Coker said:
How should we determine who gets mysql client access? Should we have a tunable determining whether we allow userdomain?
That might be a good solution..
OK, I've attached a sample policy file to allow this. I put it in mysqld.te because it goes easiest there. One advantage of doing it this way is that it makes the policy simpler, another is that if an administrator wants to change the policy to allow only dba_t instead of all of userdomain then it's a much easier change for them.
On Thu, 27 May 2004 02:31, Stephen Smalley sds@epoch.ncsc.mil wrote:
Is the client program setgid or setuid presently to give it more access? If so, then a separate domain is reasonable. Regardless, there is a potential advantage in limiting access to the client program, e.g. you can ensure that only well-formed messages constructed by the client program are sent on that socket as opposed to arbitrary data from the user. Naturally, it all depends on what you are trying to protect and what threats you want to counter.
The client program is not setgid or setuid, it has no special access and merely implements the protocol.
Regarding well-formed messages, given that the authors of the client program apparently did not design it to be run as a trusted program I don't have any great expectations of it's ability to prevent itself from being exploited. This combined with the difficulties of a separate domain (redirection of stdin/stdout not working as expected etc) makes me believe that it's not worth trying such things at this stage.
Maybe at a future time if the MySql developers want to add SE Linux support to their database server we could do such things along the way.
PS There's a lot of other MySql work that needs to be done to make it work on Fedora. A quick test has revealed to me that installing it in enforcing mode does not work well.
On Wed, 2004-05-26 at 00:17, Russell Coker wrote:
Why have mysql_cmd_t instead of just allowing user_t directly? What is the benefit in having a domain for client access?
Is the client program setgid or setuid presently to give it more access? If so, then a separate domain is reasonable. Regardless, there is a potential advantage in limiting access to the client program, e.g. you can ensure that only well-formed messages constructed by the client program are sent on that socket as opposed to arbitrary data from the user. Naturally, it all depends on what you are trying to protect and what threats you want to counter.
selinux@lists.fedoraproject.org
-
Russell Coker -
Stephen Smalley -
Valdis.Kletnieks＠vt.edu