Apache/mysql policy status ?

Apache/mysql policy status ?

[Tom]

I'm a bit confused about the current state of the two policies I've
worked on. Are they merged with
a) the CVS tree
b) the Debian default policy?

I'm asking because I just noticed that the woody default policy doesn't
seem to use them. Was it only merged with sid?


-- 
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: Apache/mysql policy status ?

[Russell Coker]

On Mon, 20 Jan 2003 12:12, Tom wrote:
> I'm a bit confused about the current state of the two policies I've
> worked on. Are they merged with
> a) the CVS tree

Yes.

> b) the Debian default policy?
>
> I'm asking because I just noticed that the woody default policy doesn't
> seem to use them. Was it only merged with sid?

The policy for woody as packaged by Brian should be the same as my policy.  
Brian has been sending patches to me which I include in my policy.  Brian 
periodically updates his policy package to my latest package.

Incidentally I've already packaged the new NSA release, Brian, have you 
back-ported it yet?

-- 
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: Apache/mysql policy status ?

[Stephen D. Smalley]

> I'm a bit confused about the current state of the two policies I've
> worked on. Are they merged with
> a) the CVS tree
> b) the Debian default policy?
> 
> I'm asking because I just noticed that the woody default policy doesn't
> seem to use them. Was it only merged with sid?

As I recall, we were still waiting final forms of patches for merging
from you.  Your last message about the mysql policy appears to have
been http://marc.theaimsgroup.com/?l=selinux&m=103598879429279&w=2,
where you posted full files for comments and said that you would
followup with a patch after further testing.  I don't recall seeing
any comments or a followup patch.  Since it was a major rewrite of
Russell's original domain, I was also looking for an ACK from him.

With regard to the Apache policy diff, I think it might have been
dropped accidentally.  Sorry.  Was the final form of that patch
contained in http://marc.theaimsgroup.com/?l=selinux&m=103555821217807&w=2?
Note to Wayne:  Please make sure that the apache diff (but not the
SubVersion diff) is in the queue of policy patches for review. 

--
Stephen Smalley, NSA
sds@epoch.ncsc.mil


--
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: Apache/mysql policy status ?

[Russell Coker]

On Tue, 21 Jan 2003 19:48, Stephen D. Smalley wrote:
> > I'm a bit confused about the current state of the two policies I've
> > worked on. Are they merged with
> > a) the CVS tree
> > b) the Debian default policy?
> >
> > I'm asking because I just noticed that the woody default policy doesn't
> > seem to use them. Was it only merged with sid?
>
> As I recall, we were still waiting final forms of patches for merging
> from you.  Your last message about the mysql policy appears to have
> been http://marc.theaimsgroup.com/?l=selinux&m=103598879429279&w=2,
> where you posted full files for comments and said that you would
> followup with a patch after further testing.  I don't recall seeing
> any comments or a followup patch.  Since it was a major rewrite of
> Russell's original domain, I was also looking for an ACK from him.

The policy as last shown to me did not entirely work in a fashion that I 
liked.

mysqld was permitted to write to var_log_t files and initrc_t was permitted to 
write to mysqld_log_t files.

>From memory I think I got some ideas for policy improvements from the policy 
Tom posted, but didn't have the time to completely go through it.  Also I now 
have a mysql server running fine with the policy I've got and haven't had a 
great incentive to change it.

Tom, I would be happy to look into this again if you send me an updated 
policy.

-- 
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: Apache/mysql policy status ?

[Tom]

On Tue, Jan 21, 2003 at 01:48:43PM -0500, Stephen D. Smalley wrote:
> As I recall, we were still waiting final forms of patches for merging
> from you.  Your last message about the mysql policy appears to have
> been http://marc.theaimsgroup.com/?l=selinux&m=103598879429279&w=2,
> where you posted full files for comments and said that you would
> followup with a patch after further testing.  

Hm, it may have been lost in general chaos (my company is restructuring
itself. I still hope they come to the "structure" part soon).


> I don't recall seeing
> any comments or a followup patch.  Since it was a major rewrite of
> Russell's original domain, I was also looking for an ACK from him.

After Russells comment - I will post my last state here and we can
discuss the differences between the two policies.


> With regard to the Apache policy diff, I think it might have been
> dropped accidentally.  Sorry.  Was the final form of that patch
> contained in http://marc.theaimsgroup.com/?l=selinux&m=103555821217807&w=2?
> Note to Wayne:  Please make sure that the apache diff (but not the
> SubVersion diff) is in the queue of policy patches for review. 

Then again, I was just starting on a total rewrite anyway. I have some
interesting things that I've done for virtual hosting right now, and
I've always wanted to seperate stuff further (e.g. the CGI and suexec
rules).


What was it with the subversion policy? I tried getting some comments
from the subversion dev team, but they never replied to my message.

-- 
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: Apache/mysql policy status ?

[Tom]

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

On Tue, Jan 21, 2003 at 08:42:11PM +0100, Russell Coker wrote:
> mysqld was permitted to write to var_log_t files and initrc_t was permitted to 
> write to mysqld_log_t files.

As I recall, the later is necessary because the wrapper script insists
on putting some startup information into the mysql logfiles. I don't
remember the reason for the prior one, but I'm fairly sure I didn't
just put random stuff in there. :)

I have the policy attached. Check it and tell me which parts make you
unhappy.


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

Re: Apache/mysql policy status ?

[Wayne Salamon]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 663 bytes --]

On Tue, 21 Jan 2003, Tom wrote:

>
>
> Then again, I was just starting on a total rewrite anyway. I have some
> interesting things that I've done for virtual hosting right now, and
> I've always wanted to seperate stuff further (e.g. the CGI and suexec
> rules).
>

  Tom, I've attached a diff file that brings your patch from October up to
date with the current CVS tree. But are you working on a new version of
the apache policy, or should this patch be applied?

  Note that I've added back in the admin TTY rule/comments that were
eliminated after your first patch. Is this access still needed for Apache
2.0?

Thanks,

 --
Wayne Salamon
wsalamon@tislabs.com

[-- Attachment #2: Type: TEXT/PLAIN, Size: 2810 bytes --]

--- apache.te.orig	Fri Jan  3 13:28:24 2003
+++ apache.te	Wed Jan 22 09:18:34 2003
@@ -55,9 +55,6 @@
 domain_auto_trans(initrc_t, httpd_exec_t, httpd_t)
 type_transition init_t httpd_exec_t:process httpd_t;
 
-# for php
-tmp_domain(httpd)
-
 #
 # A type for files in /var/run specific to httpd
 #
@@ -365,6 +362,16 @@
 allow httpd_t httpd_user_script_rw_t:file r_file_perms;
 allow httpd_t httpd_user_script_rw_t:dir r_dir_perms;
 
+########################################
+# When the admin starts the server, the server wants to acess
+# the TTY or PTY associated with the session. This is very bad
+# behaviour as it allows the server access to the sysadm_r TTYs
+# and PTYs, but apache2 doesn't work without.
+# If you run apache 1.x.x, try disabling this. For apache2,
+# this is currently the only solution.
+##################################################
+allow httpd_t admin_tty_type:chr_file { read write };
+
 ###########################
 # Allow httpd to receive messages from the network card
 ########################################
@@ -376,8 +383,7 @@
 allow httpd_t home_root_t:dir { getattr search };
 allow httpd_t user_home_dir_type:dir { getattr search };
 allow httpd_t user_home_type:dir { getattr search read };
-# need ioctl for php3
-allow httpd_t user_home_type:{ file lnk_file } { getattr read ioctl };
+allow httpd_t user_home_type:{ file lnk_file } { getattr read };
 dontaudit httpd_t sysadm_home_dir_t:dir { getattr search };
 
 ############################################################################
@@ -478,3 +484,40 @@
 # Uncomment the following line to enable:
 #can_exec(httpd_t, shell_exec_t)
 
+##################################################
+#
+# PHP Directives
+##################################################
+
+type httpd_php_exec_t, file_type, exec_type;
+type httpd_php_t, domain;
+
+# Transition from the user domain to this domain.
+domain_auto_trans(httpd_t, httpd_php_exec_t, httpd_php_t)
+
+# The user role is authorized for this domain.
+role system_r types httpd_php_t;
+
+general_domain_access(httpd_php_t)
+general_file_read_access(httpd_php_t)
+uses_shlib(httpd_php_t)
+can_exec(httpd_php_t, lib_t)
+
+# allow php to read and append to apache logfiles
+allow httpd_php_t httpd_log_files_t:file ra_file_perms;
+
+# access to /tmp
+type httpd_php_tmp_t, file_type, sysadmfile, tmpfile;
+file_type_auto_trans(httpd_php_t, tmp_t, httpd_php_tmp_t)
+
+# ignore these things, PHP seems to work fine without
+dontaudit httpd_php_t httpd_sys_script_t:dir { search };
+
+
+# connect to mysql
+ifdef(`mysqld.te', `
+can_unix_connect(httpd_php_t, mysqld_t)
+allow httpd_php_t var_run_mysqld_t:dir { search };
+allow httpd_php_t var_run_mysqld_t:sock_file { write };
+')
+

Re: Apache/mysql policy status ?

[Russell Coker]

On Wed, 22 Jan 2003 14:49, Wayne Salamon wrote:
>   Tom, I've attached a diff file that brings your patch from October up to
> date with the current CVS tree. But are you working on a new version of
> the apache policy, or should this patch be applied?
>
>   Note that I've added back in the admin TTY rule/comments that were
> eliminated after your first patch. Is this access still needed for Apache
> 2.0?

For apache2 putting the following on the apache command line should allow it 
to start:
< /dev/null > /dev/null 2>&1

Therefore the change to allow apache access to the admin_tty_type should not 
be absolutely required.

The comment "The user role is authorized for this domain" doesn't match the 
"role system_r" on the next line...

Regarding the can_exec(httpd_php_t, lib_t) line, perhaps something should be 
re-labelled from lib_t to some other type instead?

For access to /tmp there's the tmp_domain() macro.

For the mysql access we probably need a can_mysql_connect() macro which can be 
used on demand.  It's likely that there are people who have mysql and PHP on 
the same machine and don't want them to communicate with each other.  So I 
think it's best to have that access denied and easy to allow on demand.

-- 
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: Apache/mysql policy status ?

[Wayne Salamon]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 772 bytes --]

On Wed, 22 Jan 2003, Russell Coker wrote:

>
> For apache2 putting the following on the apache command line should allow it
> to start:
> < /dev/null > /dev/null 2>&1
>
> Therefore the change to allow apache access to the admin_tty_type should not
> be absolutely required.
>

  OK, I've commented out the rule, and placed the above text in the
comment.

> The comment "The user role is authorized for this domain" doesn't match the
> "role system_r" on the next line...
>

  Fixed.

>
> For access to /tmp there's the tmp_domain() macro.
>

  Changed for httpd_php. I didn't change the user_script and sys_script
tmp file transitions however.

  Attached is the new patch. I haven't addressed the MySQL or PHP issues.

  Thanks,


-- 
Wayne Salamon
wsalamon@tislabs.com


[-- Attachment #2: Type: TEXT/PLAIN, Size: 2867 bytes --]

--- apache.te.orig	Fri Jan  3 13:28:24 2003
+++ apache.te	Wed Jan 22 12:00:42 2003
@@ -55,9 +55,6 @@
 domain_auto_trans(initrc_t, httpd_exec_t, httpd_t)
 type_transition init_t httpd_exec_t:process httpd_t;
 
-# for php
-tmp_domain(httpd)
-
 #
 # A type for files in /var/run specific to httpd
 #
@@ -365,6 +362,18 @@
 allow httpd_t httpd_user_script_rw_t:file r_file_perms;
 allow httpd_t httpd_user_script_rw_t:dir r_dir_perms;
 
+########################################
+# When the admin starts the server, the server wants to acess
+# the TTY or PTY associated with the session. This is very bad
+# behaviour as it allows the server access to the sysadm_r TTYs
+# and PTYs, but apache2 doesn't work without.
+# If you run apache 1.x.x, leave it commented out.
+# For apache2 putting the following on the apache command line 
+# should allow it to start: < /dev/null > /dev/null 2>&1
+# If this approach fails, then you may want to uncomment this line.
+##################################################
+#allow httpd_t admin_tty_type:chr_file { read write };
+
 ###########################
 # Allow httpd to receive messages from the network card
 ########################################
@@ -376,8 +385,7 @@
 allow httpd_t home_root_t:dir { getattr search };
 allow httpd_t user_home_dir_type:dir { getattr search };
 allow httpd_t user_home_type:dir { getattr search read };
-# need ioctl for php3
-allow httpd_t user_home_type:{ file lnk_file } { getattr read ioctl };
+allow httpd_t user_home_type:{ file lnk_file } { getattr read };
 dontaudit httpd_t sysadm_home_dir_t:dir { getattr search };
 
 ############################################################################
@@ -478,3 +486,39 @@
 # Uncomment the following line to enable:
 #can_exec(httpd_t, shell_exec_t)
 
+##################################################
+#
+# PHP Directives
+##################################################
+
+type httpd_php_exec_t, file_type, exec_type;
+type httpd_php_t, domain;
+
+# Transition from the user domain to this domain.
+domain_auto_trans(httpd_t, httpd_php_exec_t, httpd_php_t)
+
+# The system role is authorized for this domain.
+role system_r types httpd_php_t;
+
+general_domain_access(httpd_php_t)
+general_file_read_access(httpd_php_t)
+uses_shlib(httpd_php_t)
+can_exec(httpd_php_t, lib_t)
+
+# allow php to read and append to apache logfiles
+allow httpd_php_t httpd_log_files_t:file ra_file_perms;
+
+# access to /tmp
+tmp_domain(httpd_php);
+
+# ignore these things, PHP seems to work fine without
+dontaudit httpd_php_t httpd_sys_script_t:dir { search };
+
+
+# connect to mysql
+ifdef(`mysqld.te', `
+can_unix_connect(httpd_php_t, mysqld_t)
+allow httpd_php_t var_run_mysqld_t:dir { search };
+allow httpd_php_t var_run_mysqld_t:sock_file { write };
+')
+

Re: Apache/mysql policy status ?

[Russell Coker]

On Wed, 22 Jan 2003 17:06, Wayne Salamon wrote:
>   Attached is the new patch. I haven't addressed the MySQL or PHP issues.

Apart from the MySql issue it all looks fine to me.  I'll merge it into my 
tree now while awaiting a better solution to the MySql issue.

-- 
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: Apache/mysql policy status ?

[Tom]

On Wed, Jan 22, 2003 at 05:22:03PM +0100, Russell Coker wrote:
> On Wed, 22 Jan 2003 17:06, Wayne Salamon wrote:
> >   Attached is the new patch. I haven't addressed the MySQL or PHP issues.
> 
> Apart from the MySql issue it all looks fine to me.  I'll merge it into my 
> tree now while awaiting a better solution to the MySql issue.

I'll start working on one, for both mysql and apache. I was very busy
with other stuff today, and will likely be for the rest of the week, so
it'll be a while.


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