New Apache policy

New Apache policy

[Tom]

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

The attached patch includes the earlier one, fixes what Russell
commented on and thus should get apache working in both the 1.x and 2.x
versions. No guarantees for PHP, CGI and other modules, I will tackle
that next.

However, I have also included my very first own from-scratch policy
file, for Subversion. Subversion is a CVS replacement and the server
runs under Apache2 using DAV.
My policy file tackles both the client tools and the server side,
allowing a server and both remote and local repository access.

Since this is my first from-scratch policy file, please take a look and
comment on it. It works for me, but I may have granted too much
permissions somewhere, even though I tried hard not to.


Finally, there is also a tiny fix for postfix that is required on my
system to silence pickup. No idea if this was just missed elsewhere or
if pickup works without and a simple dontaudit would've done it.


Is it OK to submit this stuff in one patch or should I have made
several?


-- 
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: apache-svn.diff --]
[-- Type: text/plain, Size: 6360 bytes --]

diff -urN default/domains/program/apache.te current/domains/program/apache.te
--- default/domains/program/apache.te	2002-10-17 01:24:36.000000000 +0200
+++ current/domains/program/apache.te	2002-10-24 14:29:59.000000000 +0200
@@ -367,14 +367,14 @@
 
 ########################################
 # When the admin starts the server, the server wants to acess
-# the TTY or PTY associated with the session. The httpd appears
-# to run correctly without this permission, so the permission
-# are commented out here. If you decide that access is needed,
-# then uncomment, but be aware that this will grant httpd access
-# to all sysadm_r TTYs and PTYs.
+# 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 write;
-dontaudit httpd_t admin_tty_type:chr_file { read write };
+allow httpd_t admin_tty_type:chr_file { read write };
+
 
 ###########################
 # Allow httpd to receive messages from the network card
@@ -401,6 +401,7 @@
 ###################################################
 allow httpd_t httpd_config_t:file r_file_perms;
 allow httpd_t httpd_config_t:dir r_dir_perms;
+allow httpd_t httpd_config_t:lnk_file r_file_perms;
 # allow logrotate to read the config files for restart
 ifdef(`logrotate.te', `
 r_dir_file(logrotate_t, httpd_config_t)
diff -urN default/domains/program/postfix.te current/domains/program/postfix.te
--- default/domains/program/postfix.te	2002-10-17 01:24:36.000000000 +0200
+++ current/domains/program/postfix.te	2002-10-24 14:29:41.000000000 +0200
@@ -225,6 +225,8 @@
 allow postfix_pickup_t postfix_spool_maildrop_t:file r_file_perms;
 allow postfix_pickup_t postfix_spool_maildrop_t:file unlink;
 allow postfix_pickup_t self:tcp_socket create_socket_perms;
+allow postfix_pickup_t postfix_pickup_t:capability { sys_chroot };
+
 
 postfix_public_domain(qmgr)
 allow postfix_qmgr_t postfix_public_t:fifo_file rw_file_perms;
diff -urN default/domains/program/svn.te current/domains/program/svn.te
--- default/domains/program/svn.te	1970-01-01 01:00:00.000000000 +0100
+++ current/domains/program/svn.te	2002-10-24 17:40:13.000000000 +0200
@@ -0,0 +1,92 @@
+#DESC Subversion revision control system
+#
+# Author:  Tom Vogt <tom@lemuria.org>
+#
+
+#################################
+#
+# Rules for the subversion domains
+#
+# svn_t is the domain for the subversion client programs.
+# svn_sysadm_t is the domain for the subversion client programs if run by the sysadmin.
+# svn_exec_t is the type of the corresponding programs.
+# svn_admin_t is the domain for the subversion admin program.
+# svn_admin_t is the domain for the subversion admin program.
+# svn_admin_exec_t is the type of the corresponding programs.
+# svn_repos_t is the type of the repository files.
+#
+#
+type svn_t, domain, privlog;
+type svn_sysadm_t, domain, privlog;
+type svn_admin_t, domain, privlog;
+type svn_repos_t, file_type, sysadmfile;
+role user_r types svn_t;
+role sysadm_r types svn_sysadm_t;
+role system_r types svn_sysadm_t;
+role sysadm_r types svn_admin_t;
+every_domain(svn_t)
+every_domain(svn_sysadm_t)
+every_domain(svn_admin_t)
+type svn_exec_t, file_type, sysadmfile, exec_type;
+type svn_admin_exec_t, file_type, sysadmfile, exec_type;
+
+# allow network access to repositories
+# the first two lines allow regular networking, while
+# the second two take care of labeled or local networking
+can_network(svn_t)
+can_network(svn_sysadm_t)
+can_tcp_connect(svn_t,httpd_t)
+can_tcp_connect(svn_sysadm_t,httpd_t)
+
+# Transition into this domain when you run these programs.
+domain_auto_trans(user_t, svn_exec_t, svn_t)
+domain_auto_trans(sysadm_t, svn_exec_t, svn_sysadm_t)
+domain_auto_trans(initrc_t, svn_exec_t, svn_t)
+domain_auto_trans(sysadm_t, svn_admin_exec_t, svn_admin_t)
+
+# allow svnadmin full access to the repositories
+allow svn_admin_t svn_repos_t:dir create_dir_perms; 
+allow svn_admin_t svn_repos_t:file create_file_perms; 
+
+# allow sysadm direct access to the repository.
+# this is required for import via the file:// method
+allow svn_sysadm_t svn_repos_t:dir rw_dir_perms;
+allow svn_sysadm_t svn_repos_t:file rw_file_perms;
+
+
+# Create, access, and remove files in home directory.
+# (needed to read and possibly create our config file)
+file_type_auto_trans(svn_t, user_home_dir_t, user_home_t)
+file_type_auto_trans(svn_sysadm_t, sysadm_home_dir_t, sysadm_home_t)
+
+# the log/history is written using an external editor,
+# so we need permissions to execute it. we remain in our
+# domain, however, to ensure the confidentiality of the
+# change information
+allow svn_sysadm_t shell_exec_t:file { execute execute_no_trans };
+allow svn_sysadm_t bin_t:file { execute execute_no_trans };
+
+# Access the terminal.
+allow svn_t user_tty_device_t:chr_file rw_file_perms;
+allow svn_t user_devpts_t:chr_file rw_file_perms;
+ifdef(`gnome-pty-helper.te', `allow svn_t user_gph_t:fd use;')
+
+allow svn_sysadm_t sysadm_tty_device_t:chr_file rw_file_perms;
+allow svn_sysadm_t sysadm_devpts_t:chr_file rw_file_perms;
+ifdef(`gnome-pty-helper.te', `allow svn_sysadm_t sysadm_gph_t:fd use;')
+
+allow svn_admin_t sysadm_tty_device_t:chr_file rw_file_perms;
+allow svn_admin_t sysadm_devpts_t:chr_file rw_file_perms;
+ifdef(`gnome-pty-helper.te', `allow svn_admin_t sysadm_gph_t:fd use;')
+
+
+###############################################################################
+#
+# If we are running a server, the apache daemon needs access to the 
+# repositories
+ifdef(`apache.te', `
+allow httpd_t svn_repos_t:dir create_dir_perms;
+allow httpd_t svn_repos_t:file create_file_perms;
+')
+
+
diff -urN default/file_contexts/program/svn.fc current/file_contexts/program/svn.fc
--- default/file_contexts/program/svn.fc	1970-01-01 01:00:00.000000000 +0100
+++ current/file_contexts/program/svn.fc	2002-10-24 14:52:29.000000000 +0200
@@ -0,0 +1,5 @@
+# types for subversion version control system
+/usr/bin/svn			system_u:object_r:svn_exec_t
+/usr/bin/svnlook		system_u:object_r:svn_exec_t
+/usr/bin/svnadmin		system_u:object_r:svn_admin_exec_t
+/var/svn(/.*)?			system_u:object_r:svn_repos_t

Re: New Apache policy

[Russell Coker]

On Thu, 24 Oct 2002 16:06, Tom wrote:
> The attached patch includes the earlier one, fixes what Russell
> commented on and thus should get apache working in both the 1.x and 2.x
> versions. No guarantees for PHP, CGI and other modules, I will tackle
> that next.

The problem with PHP is that it requires giving the httpd_t domain more access 
than you might otherwise want.

I am thinking of addressing this by having some macros file doing define() 
statements for what functionality you want.  So you could do the following if 
you want PHP:
define(`use_http_php')

Your comment about sysadm terminal access is inaccurate.  Apache2 should work 
perfectly when started from system boot!

I suggest using r_dir_file() for the config entries, it means 1 line of policy 
instead of 3 and makes it easier to read.

> However, I have also included my very first own from-scratch policy
> file, for Subversion. Subversion is a CVS replacement and the server
> runs under Apache2 using DAV.
> My policy file tackles both the client tools and the server side,
> allowing a server and both remote and local repository access.
>
> Since this is my first from-scratch policy file, please take a look and
> comment on it. It works for me, but I may have granted too much
> permissions somewhere, even though I tried hard not to.

+# svn_t is the domain for the subversion client programs.
+# svn_sysadm_t is the domain for the subversion client programs if run by the 
sysadmin.

Why not use a macro for this as is done for the user_irc_t, user_ssh_t, etc?

I think that using a macro will give better security and also make the policy 
easier to read and manage.

> Finally, there is also a tiny fix for postfix that is required on my
> system to silence pickup. No idea if this was just missed elsewhere or
> if pickup works without and a simple dontaudit would've done it.

The thing to do with Postfix is to configure it to not use chroot.  I think 
that configuring Postfix with chroot on SE Linux actually decreases security 
as the types of the files for the chroot environment (which are re-copied at 
every system boot) are difficult to manage.

If you have chroot with Postfix you will have to do MUCH more than 1 line of 
changes to get it working properly!

-- 
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: New Apache policy

[Tom]

On Thu, Oct 24, 2002 at 04:43:38PM +0200, Russell Coker wrote:
> The problem with PHP is that it requires giving the httpd_t domain more access 
> than you might otherwise want.

Yes, I know. I will work on a cgi version first and leave the module
version for later, when I feel comfortable with it.


> I am thinking of addressing this by having some macros file doing define() 
> statements for what functionality you want.  So you could do the following if 
> you want PHP:
> define(`use_http_php')

Absolutely, yes.



> Your comment about sysadm terminal access is inaccurate.  Apache2 should work 
> perfectly when started from system boot!

It seems to start up fine at boot. But I need it to work from run_init,
too. No good rebooting the machine each time you change some apache
config.



> I suggest using r_dir_file() for the config entries, it means 1 line of policy 
> instead of 3 and makes it easier to read.

Will do that.



> +# svn_t is the domain for the subversion client programs.
> +# svn_sysadm_t is the domain for the subversion client programs if run by the 
> sysadmin.
> 
> Why not use a macro for this as is done for the user_irc_t, user_ssh_t, etc?

I will check those out and see if I can use them.



> The thing to do with Postfix is to configure it to not use chroot.  I think 
> that configuring Postfix with chroot on SE Linux actually decreases security 
> as the types of the files for the chroot environment (which are re-copied at 
> every system boot) are difficult to manage.
> 
> If you have chroot with Postfix you will have to do MUCH more than 1 line of 
> changes to get it working properly!

Hm, weird. It seems to work just fine with this single line. But I'm
not really using it for now, so that may be the reason.


-- 
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: New Apache policy

[Tom]

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

On Thu, Oct 24, 2002 at 04:43:38PM +0200, Russell Coker wrote:
> I am thinking of addressing this by having some macros file doing define() 
> statements for what functionality you want.  So you could do the following if 
> you want PHP:
> define(`use_http_php')

I don't yet feel comfortable with these defines, so I've left them out
for now. However, it definitely is a good idea.

I've also thought about writing a php.te file instead of including PHP
stuff in apache.te, which is pretty large as it is. Maybe I'll still do
that later, reorganizing apache into apache.te, apache-cgi.te, etc.
Advantage: With the Debian install process you could choose right there
which options to include.


I have attached two diff files, both against the latest default policy.
One is for apache, taking into account your comments and adding a
section for running PHP as a CGI, but with its own type.
I did this because I believe many people will want to give PHP scripts
more access than they would other scripts. It also helps me to seperate
out the PHP stuff from the other CGI and suexec parts.

The second diff is a new subversion policy, using a macro as you
suggested. It was a lot of work to get it right initially, but I do
agree that it's the better way to do it.


Again, if anyone has comments or suggestions, please don't hesitate. I
feel more comfortable with writing SELinux policies every day, but I'm
still just beginning.



-- 
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: apache.diff --]
[-- Type: text/plain, Size: 4248 bytes --]

diff -urN default/domains/program/apache.te current/domains/program/apache.te
--- default/domains/program/apache.te	2002-10-17 01:24:36.000000000 +0200
+++ current/domains/program/apache.te	2002-10-25 18:26:35.000000000 +0200
@@ -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
 #
@@ -367,14 +364,14 @@
 
 ########################################
 # When the admin starts the server, the server wants to acess
-# the TTY or PTY associated with the session. The httpd appears
-# to run correctly without this permission, so the permission
-# are commented out here. If you decide that access is needed,
-# then uncomment, but be aware that this will grant httpd access
-# to all sysadm_r TTYs and PTYs.
+# 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 write;
-dontaudit httpd_t admin_tty_type:chr_file { read write };
+allow httpd_t admin_tty_type:chr_file { read write };
+
 
 ###########################
 # Allow httpd to receive messages from the network card
@@ -387,8 +384,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 };
 
 ############################################################################
@@ -399,8 +395,7 @@
 #################################################
 # Allow the httpd_t to read the web servers config files
 ###################################################
-allow httpd_t httpd_config_t:file r_file_perms;
-allow httpd_t httpd_config_t:dir r_dir_perms;
+r_dir_file(httpd_t, httpd_config_t)
 # allow logrotate to read the config files for restart
 ifdef(`logrotate.te', `
 r_dir_file(logrotate_t, httpd_config_t)
@@ -489,3 +484,41 @@
 # 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 };
+')
+
diff -urN default/file_contexts/program/apache.fc current/file_contexts/program/apache.fc
--- default/file_contexts/program/apache.fc	2002-10-17 01:24:36.000000000 +0200
+++ current/file_contexts/program/apache.fc	2002-10-25 17:45:24.000000000 +0200
@@ -3,6 +3,7 @@
 /var/www/mrtg(/.*)?		system_u:object_r:httpd_sys_content_t
 /var/www/cgi-bin(/.*)?		system_u:object_r:httpd_sys_script_t
 /usr/lib/cgi-bin(/.*)?		system_u:object_r:httpd_sys_script_t
+/usr/lib/cgi-bin/php(3|4)?	system_u:object_r:httpd_php_exec_t
 /var/www/perl(/.*)?		system_u:object_r:httpd_sys_script_t
 /var/www/icons(/.*)?		system_u:object_r:httpd_sys_content_t
 /var/cache/httpd(/.*)?		system_u:object_r:httpd_cache_t

[-- Attachment #3: svn.diff --]
[-- Type: text/plain, Size: 4469 bytes --]

diff -urN default/domains/program/svn.te current/domains/program/svn.te
--- default/domains/program/svn.te	1970-01-01 01:00:00.000000000 +0100
+++ current/domains/program/svn.te	2002-10-25 14:17:41.000000000 +0200
@@ -0,0 +1,28 @@
+#DESC Subversion revision control system
+#
+# Author:  Tom Vogt <tom@lemuria.org>
+#
+
+#################################
+#
+# Rules for the subversion domains
+#
+# The client programs (svn_exec_t) have a domain defined in
+# macros/program/svn_macros.te
+# 
+# svn_repos_t is the type of the repository files.
+#
+type svn_exec_t, file_type, sysadmfile, exec_type;
+type svn_repos_t, file_type;
+
+###############################################################################
+#
+# Rules for the server
+#
+# Subversion server runs as an apache2 module
+#
+ifdef(`apache.te', `
+allow httpd_t svn_repos_t:dir create_dir_perms;
+allow httpd_t svn_repos_t:file create_file_perms;
+')
+
diff -urN default/file_contexts/program/svn.fc current/file_contexts/program/svn.fc
--- default/file_contexts/program/svn.fc	1970-01-01 01:00:00.000000000 +0100
+++ current/file_contexts/program/svn.fc	2002-10-25 14:19:01.000000000 +0200
@@ -0,0 +1,5 @@
+# types for subversion version control system
+/usr/bin/svn			system_u:object_r:svn_exec_t
+/usr/bin/svnlook		system_u:object_r:svn_exec_t
+/usr/bin/svnadmin		system_u:object_r:svn_exec_t
+/var/svn(/.*)?			system_u:object_r:svn_repos_t
diff -urN default/macros/program/svn_macros.te current/macros/program/svn_macros.te
--- default/macros/program/svn_macros.te	1970-01-01 01:00:00.000000000 +0100
+++ current/macros/program/svn_macros.te	2002-10-25 15:49:05.000000000 +0200
@@ -0,0 +1,81 @@
+#
+# Macros for subversion domains.
+#
+# Author:  Tom Vogt <tom@lemuria.org>
+#
+
+#
+# svn_domain(domain_prefix)
+#
+# Define a derived domain for the svn programs when executed
+# by a user domain.
+#
+# The type declaration for the executable type for this program is
+# provided separately in domains/program/svn.te. 
+#
+undefine(`svn_domain')
+ifdef(`svn.te', `
+define(`svn_domain',`
+# Derived domain based on the calling user domain and the program.
+type $1_svn_t, domain;
+
+# Transition from the user domain to this domain.
+domain_auto_trans($1_t, svn_exec_t, $1_svn_t)
+
+# The user role is authorized for this domain.
+role $1_r types $1_svn_t;
+
+# Inherit and use descriptors from gnome-pty-helper.
+ifdef(`gnome-pty-helper.te',
+`allow $1_svn_t $1_gph_t:fd use;
+allow $1_t $1_gph_t:fd use;')
+
+# Inherit and use descriptors from newrole.
+ifdef(`newrole.te', `allow $1_svn_t newrole_t:fd use;')
+
+# allow ps to show svn
+allow $1_t $1_svn_t:dir { search getattr read };
+allow $1_t $1_svn_t:{ file lnk_file } { read getattr };
+allow $1_t $1_svn_t:process signal;
+
+# access to the repository
+allow $1_svn_t svn_repos_t:dir create_dir_perms;
+allow $1_svn_t svn_repos_t:file create_file_perms;
+
+# Use the network.
+# 2nd line is for local or labeled networking
+can_network($1_svn_t)
+can_tcp_connect($1_svn_t,httpd_t)
+
+uses_shlib($1_svn_t)
+general_domain_access($1_svn_t)
+general_file_read_access($1_svn_t)
+allow $1_svn_t proc_t:dir { search };
+
+# ignore this stuff, svn works just fine without
+dontaudit $1_svn_t devtty_t:chr_file { read write };
+dontaudit $1_svn_t sysctl_kernel_t:dir { search };
+dontaudit $1_svn_t sysctl_t:dir { search };
+
+
+# Write to the user domain tty.
+allow $1_svn_t $1_tty_device_t:chr_file rw_file_perms;
+allow $1_svn_t $1_devpts_t:chr_file rw_file_perms;
+
+
+# Create, access, and remove files in home directory.
+file_type_auto_trans($1_svn_t, $1_home_dir_t, $1_home_t)
+allow $1_svn_t $1_home_t:dir_file_class_set { relabelfrom relabelto };
+allow $1_svn_t $1_home_dir_t:dir { search };
+allow $1_svn_t $1_home_t:dir create_file_perms;
+allow $1_svn_t $1_home_t:file create_file_perms;
+
+# access files under /tmp
+file_type_auto_trans($1_svn_t, tmp_t, $1_tmp_t)
+')
+
+', `
+
+define(`svn_domain',`')
+
+')
diff -urN default/macros/user_macros.te current/macros/user_macros.te
--- default/macros/user_macros.te	2002-10-17 01:24:36.000000000 +0200
+++ current/macros/user_macros.te	2002-10-25 17:31:15.000000000 +0200
@@ -133,6 +133,7 @@
 ifdef(`sendmail.te', `sendmail_user_domain($1)')
 ifdef(`crontab.te', `crontab_domain($1)')
 ifdef(`ssh.te', `ssh_domain($1)')
+ifdef(`svn.te', `svn_domain($1)')
 ifdef(`irc.te', `irc_domain($1)')
 ifdef(`clamav.te', `user_clamscan_domain($1)')
 ifdef(`fingerd.te', `fingerd_macro($1)')

Re: New Apache policy

[Stephen Smalley]

On Fri, 25 Oct 2002, Tom wrote:

> The second diff is a new subversion policy, using a macro as you
> suggested. It was a lot of work to get it right initially, but I do
> agree that it's the better way to do it.

A couple of questions about your Subversion policy, at least partly due to
my ignorance of Subversion:

1) Is there any way to run the server in a separate domain from httpd_t?
Would this be possible via a domain transition on the module, or is the
module not truly executed?  Alternatively, you might want to explicitly
run the httpd that you use for SubVersion in a separate domain from any
other instances of httpd so that there is no risk of the other daemons
tampering with your repository.

2) How worthwhile is it to retain a separate domain for the client?  At
present, the only important difference between the client domain and the
ordinary user domain would appear to be the permissions to the repository.
Does this correspond with the Linux protections (e.g. is the client
program a setuid or setgid program for a user or group that has
permissions to the repository, and ordinary users do not have any direct
access to the repository)?  Why does the client need direct permissions to
the repository at all if the server is used?  Is this for the local
repository case?

--
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: New Apache policy

[Tom]

On Tue, Oct 29, 2002 at 11:03:11AM -0500, Stephen Smalley wrote:
> A couple of questions about your Subversion policy, at least partly due to
> my ignorance of Subversion:
> 
> 1) Is there any way to run the server in a separate domain from httpd_t?
> Would this be possible via a domain transition on the module, or is the
> module not truly executed?  

Subversion is using an Apache module as the server, so it's run
entirely within Apache with no exec anywhere in sight. Same problem as
with PHP, which is why my current Apache/PHP policy is only for
PHP-as-CGI. 


> Alternatively, you might want to explicitly
> run the httpd that you use for SubVersion in a separate domain from any
> other instances of httpd so that there is no risk of the other daemons
> tampering with your repository.

Yes, that is definitely an option. However, all the tools assume a
regular webserver, e.g. the clients all assume port 80 for remote
access, etc.
How about offering this as an option, selectable via a define?
(only-svn-server, integrated-svn-server, seperated-svn-server)


> 2) How worthwhile is it to retain a separate domain for the client?  At
> present, the only important difference between the client domain and the
> ordinary user domain would appear to be the permissions to the repository.
> Does this correspond with the Linux protections (e.g. is the client
> program a setuid or setgid program for a user or group that has
> permissions to the repository, and ordinary users do not have any direct
> access to the repository)?  Why does the client need direct permissions to
> the repository at all if the server is used?  Is this for the local
> repository case?

Yes, Subversion offers both direct filesystem access and remote access
via the Apache/WebDAV_SVN server. For local access, it needs the
appropriate permission. I figured that the case of having a local
repository that your users shall _not_ access, while at the same time
having a remote one that they should is sufficiently rare that the
admin in that case should write his own policy.
Also, svnadmin requires local access to create new repositories. I'm 
not sure if this is intentional behaviour, but I've not been able to 
create a repository via remote access.

The main reason for giving the client tools a domain was to unify
server and client access, i.e. set up the repository so that it can
only be accessed by the proper tools. As with CVS, tampering directly
with the repository will corrupt it.
Also, this leaves the option of restricting access to the repository by
restricting access to the tools by using either unix or SELinux
permissions. I believe this consistency is worth the additional domain.


-- 
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: New Apache policy

[Stephen Smalley]

On Tue, 29 Oct 2002, Tom wrote:

> The main reason for giving the client tools a domain was to unify
> server and client access, i.e. set up the repository so that it can
> only be accessed by the proper tools. As with CVS, tampering directly
> with the repository will corrupt it.

It would offer some limited integrity protection in terms of ensuring that
the transactions on the repository are well-formed (i.e. only permitting
transactions implemented via svn, svnlock, or svnadmin commands).  But it
doesn't prevent the user domain from wreaking havoc on the repository
using these client programs, unless the programs implement their own
access controls.

> Also, this leaves the option of restricting access to the repository by
> restricting access to the tools by using either unix or SELinux
> permissions.

With a client program domain, this would take the form of only specifying
svn_domain() for certain user domains as opposed to all of them.  Without
a client program domain, it would simply consist of only allowing certain
user domains to directly access the repository type.

--
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: New Apache policy

[Tom]

On Tue, Oct 29, 2002 at 12:09:30PM -0500, Stephen Smalley wrote:
> > The main reason for giving the client tools a domain was to unify
> > server and client access, i.e. set up the repository so that it can
> > only be accessed by the proper tools. As with CVS, tampering directly
> > with the repository will corrupt it.
> 
> It would offer some limited integrity protection in terms of ensuring that
> the transactions on the repository are well-formed (i.e. only permitting
> transactions implemented via svn, svnlock, or svnadmin commands).  But it

Correct. It protects from mistakes, not malicious intent.

I still see the value in it, especially given that Subversion is still
in development - who knows what kinds of access controls and other fine
print the team might still add? Running in its own domain, the policy
is ready for whatever they come up with.

Also, I may think about restricting _local_ access for these tools,
because they are connecting outwards to potentially hacked and/or
malicious servers.


> > Also, this leaves the option of restricting access to the repository by
> > restricting access to the tools by using either unix or SELinux
> > permissions.
> 
> With a client program domain, this would take the form of only specifying
> svn_domain() for certain user domains as opposed to all of them.  Without
> a client program domain, it would simply consist of only allowing certain
> user domains to directly access the repository type.

You're right, it doesn't make much of a difference.


-- 
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: New Apache policy

[Russell Coker]

On Tue, 29 Oct 2002 18:45, Tom wrote:
> On Tue, Oct 29, 2002 at 12:09:30PM -0500, Stephen Smalley wrote:
> > > The main reason for giving the client tools a domain was to unify
> > > server and client access, i.e. set up the repository so that it can
> > > only be accessed by the proper tools. As with CVS, tampering directly
> > > with the repository will corrupt it.
> >
> > It would offer some limited integrity protection in terms of ensuring
> > that the transactions on the repository are well-formed (i.e. only
> > permitting transactions implemented via svn, svnlock, or svnadmin
> > commands).  But it
>
> Correct. It protects from mistakes, not malicious intent.
>
> I still see the value in it, especially given that Subversion is still
> in development - who knows what kinds of access controls and other fine
> print the team might still add? Running in its own domain, the policy
> is ready for whatever they come up with.

I suggest that you contact the Subversion developers and ask their opinion on 
what the security policy should be.  Of course we won't necessarily accept 
what they say, but it will be useful to get some input from them.

> Also, I may think about restricting _local_ access for these tools,
> because they are connecting outwards to potentially hacked and/or
> malicious servers.

True.  Of course if you download, compile, and run code from a potentially 
hacked server then an exploit of a Subversion bug is the least of your 
worries...

-- 
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: New Apache policy

[Tom]

On Tue, Oct 29, 2002 at 07:37:10PM +0100, Russell Coker wrote:
> I suggest that you contact the Subversion developers and ask their opinion on 
> what the security policy should be.  Of course we won't necessarily accept 
> what they say, but it will be useful to get some input from them.

That is a good idea, I will try it.


> > Also, I may think about restricting _local_ access for these tools,
> > because they are connecting outwards to potentially hacked and/or
> > malicious servers.
> 
> True.  Of course if you download, compile, and run code from a potentially 
> hacked server then an exploit of a Subversion bug is the least of your 
> worries...

Yes, but you might either not intend to run it (it may not even be
something executable, I keep documentation in CVS, for example) or 
you may execute it in a chroot or other restricted environment (simply 
labeling the resulting binary with some special bin_untrusted_t might 
be what you prefer).

One way or the other, this is the larger question of how to deal with
foreign executables and for now I'd like to leave that to the local 
sysadmin. He may already have a good policy in place.


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