mysql policy

mysql policy

[Tom]

I have a few questions about the mysql policy:

For me, starting it up via "run_init /etc/init.d/mysql start" doesn't
work. There's a lot of messages like these:

Oct 28 12:47:23 nsa2 kernel: avc:  denied  { write } for  pid=1376 exe=/usr/bin/tee path=/lib/mysql dev=03:04 ino=3014657 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:mysqld_db_t tclass=dir
Oct 28 12:47:24 nsa2 kernel: avc:  denied  { read } for  pid=1377 exe=/usr/bin/mysqladmin path=/etc/mysql/my.cnf dev=03:01 ino=32610 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:etc_mysqld_t tclass=file

Piped into newrules, it all boils down to:

allow initrc_t etc_mysqld_t:file { read };
allow initrc_t mysqld_db_t:dir { write };


Which tells me that run_init doesn't change context when it calls
mysqladmin, which is part of the "safe_mysql" script.


Is this on purpose or a mistake? If it's on purpose, what is the
workaround I'm missing to get mysql to start?


-- 
PGP/GPG key: http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: mysql policy

[Russell Coker]

On Mon, 28 Oct 2002 11:01, Tom wrote:
> I have a few questions about the mysql policy:

Firstly when discussing my policy files please CC me (otherwise I am not 
guaranteed to receive the message).

> For me, starting it up via "run_init /etc/init.d/mysql start" doesn't
> work. There's a lot of messages like these:
>
> Oct 28 12:47:23 nsa2 kernel: avc:  denied  { write } for  pid=1376
> exe=/usr/bin/tee path=/lib/mysql dev=03:04 ino=3014657
> scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:mysqld_db_t
> tclass=dir Oct 28 12:47:24 nsa2 kernel: avc:  denied  { read } for 
> pid=1377 exe=/usr/bin/mysqladmin path=/etc/mysql/my.cnf dev=03:01 ino=32610
> scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:etc_mysqld_t
> tclass=file
>
> Piped into newrules, it all boils down to:
>
> allow initrc_t etc_mysqld_t:file { read };
> allow initrc_t mysqld_db_t:dir { write };

It's not that uncommon for an init script to read the config file before 
starting a daemon.  I'll change my policy in that regard.

For the tee thing, I think that the startup scripts you use are using tee to 
redirect stdout of the daemon to a file on disk as well.  What version of the 
daemon are you using?

-- 
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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: mysql policy

[Tom]

On Mon, Oct 28, 2002 at 01:24:12PM +0100, Russell Coker wrote:
> It's not that uncommon for an init script to read the config file before 
> starting a daemon.  I'll change my policy in that regard.

Right. The thing is, this is the mysqladmin program, not mysqld -
mysqladmin is a commandline tool to administrate the database. Not sure
if they should run in the same domain. Right now, mysqladmin is just a
regular tool, i.e. bin_t.


> For the tee thing, I think that the startup scripts you use are using tee to 
> redirect stdout of the daemon to a file on disk as well.  What version of the 
> daemon are you using?

Current sid (updated today). I'm running the normal /etc/init.d/mysql
script, nothing else. The /usr/bin/safe_mysqld script started from
there does indeed contain a few tee commands.

Funny thing is, it worked flawlessly on friday. I made an update
earlier today, so maybe a recent change broke it?


-- 
PGP/GPG key: http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: mysql policy

[Russell Coker]

On Mon, 28 Oct 2002 13:58, Tom wrote:
> On Mon, Oct 28, 2002 at 01:24:12PM +0100, Russell Coker wrote:
> > It's not that uncommon for an init script to read the config file before
> > starting a daemon.  I'll change my policy in that regard.
>
> Right. The thing is, this is the mysqladmin program, not mysqld -
> mysqladmin is a commandline tool to administrate the database. Not sure
> if they should run in the same domain. Right now, mysqladmin is just a
> regular tool, i.e. bin_t.

Being in bin_t means of course that there's no domain transition.

Maybe the right thing to do would be to have a separate domain for mysql 
admin, so initrc_t transitions to mysqld_admin_t which then transitions to 
mysqld_t when it runs the database server.

I haven't got into these things in any detail, you're probably the best person 
to work on this.

> Funny thing is, it worked flawlessly on friday. I made an update
> earlier today, so maybe a recent change broke it?

That's not uncommon.  Debian/unstable changes fast.

-- 
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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: mysql policy

[Tom]

On Mon, Oct 28, 2002 at 02:47:09PM +0100, Russell Coker wrote:
> Maybe the right thing to do would be to have a separate domain for mysql 
> admin, so initrc_t transitions to mysqld_admin_t which then transitions to 
> mysqld_t when it runs the database server.

Funny thing is: It doesn't I don't understand why it's running
mysaqladmin at all. Oh, well, I'll just find out.


> I haven't got into these things in any detail, you're probably the best person 
> to work on this.

So I'm now with apache and mysql. :)

That's fine with me as I'm working on that anyways. I'm currently
fighting with apache2 and SSL. I'll get to apache1+SSL later.


-- 
PGP/GPG key: http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: mysql policy

[Tom]

[-- Attachment #1: Type: text/plain, Size: 611 bytes --]

Here's a small patch to mysqld.te which solves the startup problem for
me and lets mysqld run without any error.
I believe these changes do not open any security problems as they don't
give init access to the databases. One could do away with the
requirement to write into the /var/lib/mysql directory with a few
changes to the safe_mysqld startup script, but I don't think it would
make much of a difference, security-wise.


-- 
PGP/GPG key: http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

[-- Attachment #2: mysqld.diff --]
[-- Type: text/plain, Size: 713 bytes --]

--- default/domains/program/mysqld.te   2002-10-27 02:29:00.000000000 +0200
+++ current/domains/program/mysqld.te   2002-10-28 17:32:28.000000000 +0100
@@ -26,6 +26,8 @@
 allow initrc_t var_run_mysqld_t:sock_file write;

 allow initrc_t mysqld_log_t:file { write append setattr ioctl };
+allow initrc_t etc_mysqld_t:file { read };
+allow initrc_t mysqld_db_t:dir { write };

 allow mysqld_t self:capability { setgid setuid };
 allow mysqld_t self:process getsched;
@@ -34,7 +36,8 @@

 # Allow access to the mysqld databases
 create_dir_file(mysqld_t, mysqld_db_t)
-allow mysqld_t var_lib_t:dir search;
+allow mysqld_t var_lib_t:dir { getattr search };
+

 # read config files
 r_dir_file(mysqld_t, etc_mysqld_t)

Re: mysql policy

[Stephen Smalley]

On Mon, 28 Oct 2002, Tom wrote:

>+allow initrc_t mysqld_db_t:dir { write };

I'm not clear as to the purpose of this rule in isolation.  Without other
directory permissions (e.g. add_name, remove_name), directory write
permission is useless.  What exactly is the rc script doing to this
directory?

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: mysql policy

[Tom]

On Tue, Oct 29, 2002 at 02:16:52PM -0500, Stephen Smalley wrote:
> >+allow initrc_t mysqld_db_t:dir { write };
> 
> I'm not clear as to the purpose of this rule in isolation.  Without other
> directory permissions (e.g. add_name, remove_name), directory write
> permission is useless.  What exactly is the rc script doing to this
> directory?

If I remember correctly, it's tee'ing any errors during startup to an
error log file that is located there. I'm working on this anyway, so if
you don't feel happy with it, just wait until I have a more refined
policy to offer. For some reason, though, adding this rule makes it
work on my system.


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: mysql policy

[Stephen Smalley]

On Tue, 29 Oct 2002, Tom wrote:

> If I remember correctly, it's tee'ing any errors during startup to an
> error log file that is located there. I'm working on this anyway, so if
> you don't feel happy with it, just wait until I have a more refined
> policy to offer. For some reason, though, adding this rule makes it
> work on my system.

mysqld_db_t is assigned to /var/lib/mysql.  mysqld_log_t is assigned to
/var/log/mysql.*.   So I'm not clear as to why a log file would be
created in /var/lib/mysql.  If it is (re)creating a file in
/var/lib/mysql, then it should require search, write, and add_name
permission to mysqld_db_t:dir as well as create permission to
mysqld_db_t:file.  If it is merely appending to an existing file, it
should only need search permission to the directory and append permission
to the file.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com






--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: mysql policy

[Tom]

On Tue, Oct 29, 2002 at 03:07:08PM -0500, Stephen Smalley wrote:
> mysqld_db_t is assigned to /var/lib/mysql.  mysqld_log_t is assigned to
> /var/log/mysql.*.   So I'm not clear as to why a log file would be
> created in /var/lib/mysql.  

Neither am I. As I said: For some reason it works for me with this
line, and it doesn't without. I will be checking this in more detail
over the next days and submit a better patch.


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: mysql policy

[Tom]

What is the best-practice on labelling script files? Should they be
treated with more care than binaries?

I'm asking because I have largely tossed Russell's mysqld domain and
started a new one from scratch, not because Russell's was in any way
bad but because doing so allows me to better understand what is
happening and what permissions it needs.
This way I found out that the wrapper (safe_mysqld) that the init
script uses to start mysqld requires some more and other permissions
than the daemon itself, so I'm thinking about putting it into a
different domain so that the daemon, once running, doesn't have all
those unneeded priviledges.

safe_mysqld is a shell script. I can't see a problem with that from the
pure "hacking" perspective (modifying a shell script is not that much
easier than modifying a binary), but maybe its reliance on /bin/sh
makes it a different game?


-- 
PGP/GPG key: http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: mysql policy

[Tom]

[-- Attachment #1: Type: text/plain, Size: 1408 bytes --]

On Tue, Oct 29, 2002 at 02:16:52PM -0500, Stephen Smalley wrote:
> >+allow initrc_t mysqld_db_t:dir { write };
> 
> I'm not clear as to the purpose of this rule in isolation.  

I understand it now, and I've attached a new mysql policy. There are
some other weirdnesses in it, due to the specific way that mysqld
works, especially all the wrapper scripts or the fact that mysqld
(running in mysqld_t) is shut down by a call to mysqladmin (bin_t).

I've put more comments into this policy to make it more transparent why
some rules are there.
This is not a patch since I've changed almost everything. I've decided
to post full files instead for the discussion. I will test this policy
for a few days before submitting it, then in patch form.


mysqld is a weird beast, especially with the wrapper script, and some
tools that can't quite decide whether they want to be part of the
server or not.
I've gone back and forth between defining new domains for the
safe_mysqld wrapper or not (deciding on not for now), and I'm not yet
sure whether it may be a good idea to put make the mysqladmin a
mysqld_exec_t, too.

That's why I post this now - to get some feedback. This policy works
for me, but I'm sure it can be improved.



-- 
PGP/GPG key: http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

[-- Attachment #2: mysqld.te --]
[-- Type: text/plain, Size: 3230 bytes --]

#DESC mysql database server
#
# Authors:  Russell Coker <russell@coker.com.au>
#           Tom Vogt <tom@lemuria.org>
#

#################################
#
# Rules for the mysqld_t domain.
#
# mysqld_t is the type of the mysql daemon
#
daemon_domain(mysqld)
domain_auto_trans(initrc_t, mysqld_exec_t, mysqld_t)

type etc_mysqld_t, file_type, sysadmfile;
type mysqld_db_dir_t, file_type, sysadmfile;
type mysqld_db_t, file_type, sysadmfile;
type mysqld_log_t, file_type, sysadmfile, logfile;

#
# Permissions required by the initrc script and safe_mysqld wrapper
# (both running in initrc_t)
#
allow initrc_t etc_mysqld_t:file { read };

# create error startup log in /var/lib/mysql
allow initrc_t mysqld_db_dir_t:dir { write };
file_type_auto_trans(initrc_t, mysqld_db_dir_t, mysqld_db_t)

# touch /var/log/mysql and chown it to the mysql user
allow initrc_t mysqld_log_t:dir rw_dir_perms;
allow initrc_t mysqld_log_t:file create_file_perms;

# mysqladmin wants to talk to mysqld
allow initrc_t var_run_mysqld_t:sock_file { write };
allow initrc_t mysqld_t:unix_stream_socket { connectto };

#
# Permissions for the daemon itself (mysqld)
#
general_proc_read_access(mysqld_t)
general_file_read_access(mysqld_t)
allow mysqld_t self:unix_stream_socket create_stream_socket_perms;
allow mysqld_t self:fifo_file rw_file_perms;
allow mysqld_t self:process { getsched };

# read config files
allow mysqld_t etc_mysqld_t:dir r_dir_perms;
allow mysqld_t etc_t:lnk_file r_file_perms;
allow mysqld_t etc_t:file r_file_perms;
allow mysqld_t etc_mysqld_t:file r_file_perms;

# temp and log files
allow mysqld_t var_log_t:dir { search };
allow mysqld_t var_log_t:file { append };
allow mysqld_t mysqld_log_t:file { create append };
file_type_auto_trans(mysqld_t, var_log_t, mysqld_log_t)
allow mysqld_t tmp_t:dir r_dir_perms;

# drop uid/gid
allow mysqld_t self:capability { setgid setuid };

# read /etc/mtab
allow mysqld_t etc_runtime_t:file r_file_perms;

# access the console
allow mysqld_t admin_tty_type:chr_file { read write };


#
# The databases
#
file_type_auto_trans(mysqld_t, mysqld_db_dir_t, mysqld_db_t)
allow mysqld_t mysqld_db_dir_t:dir create_dir_perms;
allow mysqld_t mysqld_db_t:dir create_dir_perms;
allow mysqld_t mysqld_db_t:file create_file_perms;

# Let dpkg install the default DB correctly and start/stop the server
ifdef(`dpkg.te', `
allow dpkg_t mysqld_exec_t:file { execute };
domain_auto_trans(dpkg_t, mysqld_exec_t, mysqld_t)
file_type_auto_trans(dpkg_t, mysqld_db_dir_t, mysqld_db_t)
')


#
# Client tools, for the sysadm role, this is easy:
#
allow sysadm_t mysqld_t:unix_stream_socket { connectto };

# for normal users, we need to give them some other
# access rights, too:
allow user_t mysqld_t:unix_stream_socket { connectto };
allow user_t var_run_mysqld_t:sock_file { write };
allow user_t etc_mysqld_t:dir { search };
allow user_t etc_mysqld_t:file { read };
allow user_t mysqld_db_dir_t:dir { search };
allow user_t var_run_mysqld_t:dir { search };


ifdef(`logrotate.te', `
r_dir_file(logrotate_t, etc_mysqld_t)
allow logrotate_t mysqld_db_dir_t:dir search;
allow logrotate_t var_run_mysqld_t:dir search;
allow logrotate_t var_run_mysqld_t:sock_file write;
can_unix_connect(logrotate_t, mysqld_t)
')

[-- Attachment #3: mysqld.fc --]
[-- Type: text/plain, Size: 382 bytes --]

# mysql database server
/usr/sbin/mysqld		system_u:object_r:mysqld_exec_t
/var/run/mysqld(/.*)?		system_u:object_r:var_run_mysqld_t
/var/log/mysql.*		system_u:object_r:mysqld_log_t
/var/lib/mysql	        	system_u:object_r:mysqld_db_dir_t
/var/lib/mysql/.*		system_u:object_r:mysqld_db_t
/etc/my.cnf			system_u:object_r:etc_mysqld_t
/etc/mysql(/.*)?		system_u:object_r:etc_mysqld_t