mysql issues...

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.. ;)

[Russell Coker]

On Tue, 25 May 2004 12:15, Valdis.Kletnieks(a)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?

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

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?

[Stephen Smalley]

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.

-- 
Stephen Smalley <sds(a)epoch.ncsc.mil&gt;
National Security Agency

[Russell Coker]

On Thu, 27 May 2004 02:26, Valdis.Kletnieks(a)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(a)epoch.ncsc.mil&gt; 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.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page