patch: add can_create() macro, allow file_type_auto_trans(a,b,c, { file dir })

patch: add can_create() macro, allow file_type_auto_trans(a,b,c, { file dir })

[Thomas Bleher]

[-- Attachment #1.1: Type: text/plain, Size: 803 bytes --]

After the boring cleanup stuff, now for something a little bit more
interesting :-)

The goal of the following patch is to allow one to write
file_type_auto_trans(foo_t, var_run_t, foo_var_run_t, { dir file sock_file }) 

This makes it much easier to eg lock down /tmp (this will follow later
as a separate patch)

How does it work? The m4 magic inside can_create() parses its last 
parameter via a regex into separate tokens which it passes to 
can_create_internal() one by one and recurses over the rest.

The interface to file_type_{,auto_}trans() is unchanged, except that the
fourth parameter can now contain multiple object classes.

Thomas

-- 
http://www.cip.ifi.lmu.de/~bleher/selinux/ - my SELinux pages
GPG-Fingerprint: BC4F BB16 30D6 F253 E3EA  D09E C562 2BAE B2F4 ABE7

[-- Attachment #1.2: can_create.patch --]
[-- Type: text/plain, Size: 1977 bytes --]

--- orig/macros/core_macros.te
+++ mod/macros/core_macros.te
@@ -445,6 +445,31 @@
 allow $1 $2:file { rx_file_perms execute_no_trans };
 ')
 
+# this is an internal macro used by can_create
+define(`can_create_internal', `
+ifelse(`$3', `dir', `
+allow $1 $2:$3 create_dir_perms;
+', `$3', `lnk_file', `
+allow $1 $2:$3 create_lnk_perms;
+', `
+allow $1 $2:$3 create_file_perms;
+')dnl end if dir
+')dnl end can_create_internal
+
+
+#################################
+#
+# can_create(domain, file_type, object_class)
+#
+# Permissions for creating files of the specified type and class
+#
+define(`can_create', `
+ifelse(regexp($3, `\w'), -1, `', `
+can_create_internal($1, $2, regexp($3, `\(\w+\)', `\1'))
+
+can_create($1, $2, regexp($3, `\w+\(.*\)', `\1'))
+')
+')
 #################################
 #
 # file_type_trans(domain, dir_type, file_type)
@@ -463,19 +488,9 @@
 # Allow the process to create the file.
 #
 ifelse(`$4', `', `
-allow $1 $3:{ file sock_file fifo_file } create_file_perms;
-allow $1 $3:lnk_file create_lnk_perms;
-allow $1 $3:dir create_dir_perms;
+can_create($1, $3, `{ file lnk_file sock_file fifo_file dir }')
 ', `
-ifelse(`$4', `dir', `
-allow $1 $3:$4 create_dir_perms;
-', `
-ifelse(`$4', `lnk_file', `
-allow $1 $3:$4 create_lnk_perms;
-', `
-allow $1 $3:$4 create_file_perms;
-')dnl end ifelse lnk_file
-')dnl end if dir
+can_create($1, $3, $4)
 ')dnl end if param 4 specified
 
 ')
--- orig/macros/program/crontab_macros.te
+++ mod/macros/program/crontab_macros.te
@@ -45,8 +45,7 @@
 dontaudit $1_crontab_t selinux_config_t:dir search;
 
 # Type for temporary files.
-file_type_auto_trans($1_crontab_t, tmp_t, $1_tmp_t, file)
-file_type_auto_trans($1_crontab_t, tmp_t, $1_tmp_t, dir)
+file_type_auto_trans($1_crontab_t, tmp_t, $1_tmp_t, { dir file })
 
 # Use the type when creating files in /var/spool/cron.
 allow sysadm_crontab_t $1_cron_spool_t:file { getattr read };

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: patch: add can_create() macro, allow file_type_auto_trans(a,b,c, { file dir })

[James Carter]

Nice.  Merged.

On Mon, 2004-12-06 at 19:08, Thomas Bleher wrote:
> After the boring cleanup stuff, now for something a little bit more
> interesting :-)
> 
> The goal of the following patch is to allow one to write
> file_type_auto_trans(foo_t, var_run_t, foo_var_run_t, { dir file sock_file }) 
> 
> This makes it much easier to eg lock down /tmp (this will follow later
> as a separate patch)
> 
> How does it work? The m4 magic inside can_create() parses its last 
> parameter via a regex into separate tokens which it passes to 
> can_create_internal() one by one and recurses over the rest.
> 
> The interface to file_type_{,auto_}trans() is unchanged, except that the
> fourth parameter can now contain multiple object classes.
> 
> Thomas
-- 
James Carter <jwcart2@epoch.ncsc.mil>
National Security Agency

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

Some more fixes

[Daniel J Walsh]

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

Many fixes for initrc required by turning off unlimitedRC

Fixes for ipsec

Fixes for ifdefs of targeted policy

Added new booleans to replace tunables

allow_user_mysql_connect &  allow_user_postgresql_connect &  pppd_for_user

Fixed some can_network_* calls.

Added support for winbindd

Added a portmap_helper domain for pmap_dump and pmap_set.  Not sure if I 
like this?  Looking for comments.

Remove user_can_mount tunable



[-- Attachment #2: policy-small.patch --]
[-- Type: text/x-patch, Size: 28070 bytes --]

diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/initrc.te policy-1.19.12/domains/program/initrc.te
--- nsapolicy/domains/program/initrc.te	2004-12-09 10:26:08.583499181 -0500
+++ policy-1.19.12/domains/program/initrc.te	2004-12-09 11:03:11.335553650 -0500
@@ -12,7 +12,7 @@
 # initrc_exec_t is the type of the init program.
 #
 # do not use privmail for sendmail as it creates a type transition conflict
-type initrc_t, ifdef(`unlimitedRC', `admin, etc_writer, fs_domain, privmem, auth_write, unrestricted, ') domain, privlog, privowner, privmodule, ifdef(`sendmail.te', `', `privmail,') ifdef(`distro_debian', `etc_writer, ') sysctl_kernel_writer;
+type initrc_t, ifdef(`unlimitedRC', `admin, etc_writer, fs_domain, privmem, auth_write, unrestricted, ') domain, privlog, privowner, privmodule, ifdef(`sendmail.te', `', `privmail,') ifdef(`distro_debian', `etc_writer, ') sysctl_kernel_writer, nscd_client_domain;
 ifdef(`sendmail.te', `
 allow system_mail_t initrc_t:fd use;
 allow system_mail_t initrc_t:fifo_file write;
@@ -20,6 +20,7 @@
 
 role system_r types initrc_t;
 uses_shlib(initrc_t);
+can_network(initrc_t)
 can_ypbind(initrc_t)
 type initrc_exec_t, file_type, sysadmfile, exec_type;
 
@@ -217,6 +218,9 @@
 allow initrc_t tmpfs_t:chr_file rw_file_perms;
 allow initrc_t tmpfs_t:dir r_dir_perms;
 
+# Allow initrc domain to set the enforcing flag.
+can_setenforce(initrc_t)
+
 #
 # readahead asks for these
 #
@@ -362,3 +366,4 @@
 # Gentoo integrated run_init+open_init_pty-runscript:
 domain_auto_trans(sysadm_t,initrc_exec_t,run_init_t)
 ')
+allow initrc_t self:netlink_route_socket r_netlink_socket_perms;
diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/ldconfig.te policy-1.19.12/domains/program/ldconfig.te
--- nsapolicy/domains/program/ldconfig.te	2004-12-09 10:26:08.603496932 -0500
+++ policy-1.19.12/domains/program/ldconfig.te	2004-12-09 11:05:48.845841826 -0500
@@ -44,3 +44,4 @@
 ')
 
 allow ldconfig_t proc_t:file read;
+dontaudit ldconfig_t unconfined_t:tcp_socket { read write };
diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/login.te policy-1.19.12/domains/program/login.te
--- nsapolicy/domains/program/login.te	2004-12-09 10:26:08.614495695 -0500
+++ policy-1.19.12/domains/program/login.te	2004-12-09 11:03:11.336553537 -0500
@@ -183,6 +183,10 @@
 # Allow setting of attributes on power management devices.
 allow local_login_t power_device_t:chr_file { getattr setattr };
 
+ifdef(`hide_broken_symptoms', `
+dontaudit local_login_t init_t:fd use;
+')
+
 #################################
 #
 # Rules for the remote_login_t domain.
diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/unused/apache.te policy-1.19.12/domains/program/unused/apache.te
--- nsapolicy/domains/program/unused/apache.te	2004-12-03 14:42:06.000000000 -0500
+++ policy-1.19.12/domains/program/unused/apache.te	2004-12-09 11:09:45.666211688 -0500
@@ -297,8 +297,7 @@
 # This is a bug but it still exists in FC2
 #
 type httpd_runtime_t, file_type, sysadmfile;
-file_type_auto_trans(httpd_t, httpd_log_t, httpd_runtime_t, file)
-allow httpd_sys_script_t httpd_runtime_t:file { getattr append };
+allow { httpd_t httpd_sys_script_t } httpd_runtime_t:file { getattr append };
 ') dnl distro_redhat
 #
 # Customer reported the following
@@ -308,11 +307,14 @@
 dontaudit httpd_t snmpd_var_lib_t:file { getattr write read };
 ')
 
-#
-# The following is needed to make squirrelmail work
 type httpd_squirrelmail_t, file_type, sysadmfile;
 create_dir_file(httpd_t, httpd_squirrelmail_t)
 allow httpd_sys_script_t httpd_squirrelmail_t:file { append read };
+# File Type of squirrelmail attachments
+type squirrelmail_spool_t, file_type, sysadmfile;
+allow httpd_t var_spool_t:dir { getattr search };
+create_dir_file(httpd_t, squirrelmail_spool_t)
+
 ifdef(`mta.te', `
 dontaudit system_mail_t httpd_log_t:file { append getattr };
 allow system_mail_t httpd_squirrelmail_t:file { append read };
diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/unused/cups.te policy-1.19.12/domains/program/unused/cups.te
--- nsapolicy/domains/program/unused/cups.te	2004-12-03 14:42:07.000000000 -0500
+++ policy-1.19.12/domains/program/unused/cups.te	2004-12-09 11:03:11.338553312 -0500
@@ -149,6 +149,7 @@
 allow ptal_t self:fifo_file rw_file_perms;
 allow ptal_t device_t:dir read;
 allow ptal_t printer_device_t:chr_file { ioctl read write };
+allow initrc_t printer_device_t:chr_file getattr;
 allow ptal_t { etc_t etc_runtime_t }:file { getattr read };
 r_dir_file(ptal_t, usbdevfs_t)
 r_dir_file(ptal_t, usbfs_t)
diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/unused/dhcpc.te policy-1.19.12/domains/program/unused/dhcpc.te
--- nsapolicy/domains/program/unused/dhcpc.te	2004-12-02 14:11:41.000000000 -0500
+++ policy-1.19.12/domains/program/unused/dhcpc.te	2004-12-09 11:03:11.359550951 -0500
@@ -136,3 +136,4 @@
 allow initrc_t dhcpc_state_t:file { getattr read };
 dontaudit dhcpc_t var_lock_t:dir search;
 dontaudit dhcpc_t selinux_config_t:dir search;
+allow dhcpc_t self:netlink_route_socket r_netlink_socket_perms;
diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/unused/ipsec.te policy-1.19.12/domains/program/unused/ipsec.te
--- nsapolicy/domains/program/unused/ipsec.te	2004-12-02 14:11:42.000000000 -0500
+++ policy-1.19.12/domains/program/unused/ipsec.te	2004-12-09 11:03:11.360550839 -0500
@@ -51,7 +51,7 @@
 allow ipsec_mgmt_t ipsec_conf_file_t:file { getattr read ioctl };
 rw_dir_create_file(ipsec_mgmt_t, ipsec_key_file_t)
 
-allow ipsec_t self:key_socket { create write read };
+allow ipsec_t self:key_socket { create write read setopt };
 
 # for lsof
 allow sysadm_t ipsec_t:key_socket getattr;
@@ -225,3 +225,5 @@
 allow ipsec_mgmt_t self:{ tcp_socket udp_socket } create_socket_perms;
 allow ipsec_mgmt_t sysctl_net_t:file { getattr read };
 rw_dir_create_file(ipsec_mgmt_t, ipsec_var_run_t)
+rw_dir_create_file(initrc_t, ipsec_var_run_t)
+allow initrc_t ipsec_conf_file_t:file { getattr read ioctl };
diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/unused/kerberos.te policy-1.19.12/domains/program/unused/kerberos.te
--- nsapolicy/domains/program/unused/kerberos.te	2004-12-02 14:11:42.000000000 -0500
+++ policy-1.19.12/domains/program/unused/kerberos.te	2004-12-09 11:03:11.361550726 -0500
@@ -89,4 +89,4 @@
 # Allow user programs to talk to KDC
 allow krb5kdc_t userdomain:udp_socket recvfrom;
 allow userdomain krb5kdc_t:udp_socket recvfrom;
-
+allow initrc_t krb5_conf_t:file ioctl;
diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/unused/kudzu.te policy-1.19.12/domains/program/unused/kudzu.te
--- nsapolicy/domains/program/unused/kudzu.te	2004-12-09 10:26:09.150435429 -0500
+++ policy-1.19.12/domains/program/unused/kudzu.te	2004-12-09 11:03:11.362550614 -0500
@@ -16,6 +16,7 @@
 
 allow kudzu_t ramfs_t:dir search;
 allow kudzu_t ramfs_t:sock_file write;
+allow kudzu_t etc_t:file { getattr read };
 allow kudzu_t self:capability { dac_override sys_admin sys_rawio net_admin sys_tty_config mknod };
 allow kudzu_t modules_conf_t:file { getattr read };
 allow kudzu_t modules_object_t:dir r_dir_perms;
diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/unused/mailman.te policy-1.19.12/domains/program/unused/mailman.te
--- nsapolicy/domains/program/unused/mailman.te	2004-11-30 05:59:38.000000000 -0500
+++ policy-1.19.12/domains/program/unused/mailman.te	2004-12-09 11:03:11.362550614 -0500
@@ -15,7 +15,7 @@
 role system_r types mailman_$1_t;
 file_type_auto_trans(mailman_$1_t, var_log_t, mailman_log_t, file)
 allow mailman_$1_t mailman_log_t:dir rw_dir_perms;
-rw_dir_create_file(mailman_$1_t, mailman_data_t)
+create_dir_file(mailman_$1_t, mailman_data_t)
 uses_shlib(mailman_$1_t)
 can_exec_any(mailman_$1_t)
 allow mailman_$1_t { proc_t sysctl_t sysctl_kernel_t }:dir search;
@@ -96,6 +96,7 @@
 system_crond_entry(mailman_queue_exec_t, mailman_queue_t)
 allow mailman_queue_t devtty_t:chr_file { read write };
 allow mailman_queue_t self:process { fork signal sigchld };
+allow mailman_queue_t self:netlink_route_socket r_netlink_socket_perms;
 
 # so MTA can access /var/lib/mailman/mail/wrapper
 allow mta_delivery_agent var_lib_t:dir search;
diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/unused/mta.te policy-1.19.12/domains/program/unused/mta.te
--- nsapolicy/domains/program/unused/mta.te	2004-11-20 22:29:09.000000000 -0500
+++ policy-1.19.12/domains/program/unused/mta.te	2004-12-09 11:03:11.363550501 -0500
@@ -20,7 +20,7 @@
 # "mail user@domain"
 mail_domain(system)
 
-ifelse(`targeted-policy', `', `
+ifdef(`targeted_policy', `', `
 ifdef(`sendmail.te', `
 # sendmail has an ugly design, the one process parses input from the user and
 # then does system things with it.
@@ -75,3 +75,4 @@
 allow system_mail_t { var_t var_spool_t }:dir getattr;
 create_dir_file( system_mail_t, mqueue_spool_t)
 ')
+allow system_mail_t etc_runtime_t:file { getattr read };
diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/unused/mysqld.te policy-1.19.12/domains/program/unused/mysqld.te
--- nsapolicy/domains/program/unused/mysqld.te	2004-12-02 14:11:42.000000000 -0500
+++ policy-1.19.12/domains/program/unused/mysqld.te	2004-12-09 11:03:11.364550389 -0500
@@ -35,7 +35,7 @@
 
 allow initrc_t mysqld_log_t:file { write append setattr ioctl };
 
-allow mysqld_t self:capability { dac_override setgid setuid };
+allow mysqld_t self:capability { dac_override setgid setuid net_bind_service };
 allow mysqld_t self:process getsched;
 
 allow mysqld_t proc_t:file { getattr read };
@@ -70,11 +70,6 @@
 can_unix_connect(logrotate_t, mysqld_t)
 ')
 
-ifdef(`user_db_connect', `
-allow userdomain mysqld_var_run_t:dir search;
-allow userdomain mysqld_var_run_t:sock_file write;
-')
-
 ifdef(`daemontools.te', `
 domain_auto_trans( svc_run_t, mysqld_exec_t, mysqld_t)
 allow svc_start_t mysqld_t:process signal;
@@ -87,3 +82,12 @@
 # because Fedora has the sock_file in the database directory
 file_type_auto_trans(mysqld_t, mysqld_db_t, mysqld_var_run_t, sock_file)
 ')
+ifdef(`targeted_policy', `', `
+bool allow_user_mysql_connect false;
+
+if (allow_user_mysql_connect) {
+allow userdomain mysqld_var_run_t:dir search;
+allow userdomain mysqld_var_run_t:sock_file write;
+}
+')
+
diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/unused/nscd.te policy-1.19.12/domains/program/unused/nscd.te
--- nsapolicy/domains/program/unused/nscd.te	2004-12-02 14:11:42.000000000 -0500
+++ policy-1.19.12/domains/program/unused/nscd.te	2004-12-09 11:03:11.364550389 -0500
@@ -67,5 +67,4 @@
 allow nscd_t self:netlink_route_socket r_netlink_socket_perms;
 allow nscd_t tmp_t:dir { search getattr };
 allow nscd_t tmp_t:lnk_file read;
-
-
+allow nscd_t urandom_device_t:chr_file { getattr read };
diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/unused/portmap.te policy-1.19.12/domains/program/unused/portmap.te
--- nsapolicy/domains/program/unused/portmap.te	2004-12-02 14:11:42.000000000 -0500
+++ policy-1.19.12/domains/program/unused/portmap.te	2004-12-09 11:03:11.365550277 -0500
@@ -13,7 +13,7 @@
 #
 daemon_domain(portmap, `, nscd_client_domain')
 
-can_network_server(portmap_t)
+can_network(portmap_t)
 can_ypbind(portmap_t)
 allow portmap_t self:unix_dgram_socket create_socket_perms;
 allow portmap_t self:unix_stream_socket create_stream_socket_perms;
@@ -54,3 +54,14 @@
 allow portmap_t self:capability { net_bind_service setuid setgid };
 allow portmap_t self:netlink_route_socket r_netlink_socket_perms;
 
+application_domain(portmap_helper)
+domain_auto_trans(initrc_t, portmap_helper_exec_t, portmap_helper_t)
+dontaudit portmap_helper_t self:capability { net_admin };
+allow portmap_helper_t { var_run_t initrc_var_run_t } :file rw_file_perms;
+allow portmap_helper_t self:netlink_route_socket r_netlink_socket_perms;
+can_network(portmap_helper_t)
+can_ypbind(portmap_helper_t)
+dontaudit portmap_helper_t admin_tty_type:chr_file rw_file_perms;
+allow portmap_helper_t etc_t:file { getattr read };
+dontaudit portmap_helper_t userdomain:fd use;
+allow portmap_helper_t reserved_port_t:udp_socket name_bind;
diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/unused/postgresql.te policy-1.19.12/domains/program/unused/postgresql.te
--- nsapolicy/domains/program/unused/postgresql.te	2004-12-02 14:11:42.000000000 -0500
+++ policy-1.19.12/domains/program/unused/postgresql.te	2004-12-09 11:03:11.366550164 -0500
@@ -60,13 +60,16 @@
 
 allow postgresql_t self:shm create_shm_perms;
 
-ifdef(`user_db_connect', `
+ifdef(`targeted_policy', `', `
+bool allow_user_postgresql_connect false;
+
+if (allow_user_postgresql_connect) {
 # allow any user domain to connect to the database server
 can_tcp_connect(userdomain, postgresql_t)
 allow userdomain postgresql_t:unix_stream_socket connectto;
 allow userdomain postgresql_var_run_t:sock_file write;
+}
 ')
-
 ifdef(`consoletype.te', `
 can_exec(postgresql_t, consoletype_exec_t)
 ')
@@ -85,8 +88,7 @@
 
 # because postgresql start scripts are broken and put the pid file in the DB
 # directory
-allow initrc_t postgresql_db_t:dir { write remove_name };
-allow initrc_t postgresql_db_t:file rw_file_perms;
+rw_dir_file(initrc_t, postgresql_db_t)
 
 # read config files
 allow postgresql_t { etc_t etc_runtime_t }:{ file lnk_file } { read getattr };
diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/unused/pppd.te policy-1.19.12/domains/program/unused/pppd.te
--- nsapolicy/domains/program/unused/pppd.te	2004-12-02 14:11:42.000000000 -0500
+++ policy-1.19.12/domains/program/unused/pppd.te	2004-12-09 11:03:11.366550164 -0500
@@ -12,6 +12,8 @@
 # pppd_exec_t is the type of the pppd executable.
 # pppd_secret_t is the type of the pap and chap password files
 #
+bool pppd_for_user false;
+
 daemon_domain(pppd, `, privmail')
 type pppd_secret_t, file_type, sysadmfile;
 
@@ -80,13 +82,12 @@
 # for ~/.ppprc - if it actually exists then you need some policy to read it
 allow pppd_t { sysadm_home_dir_t home_root_t user_home_dir_type }:dir search;
 
-ifdef(`pppd_for_user', `
-# Run pppd in pppd_t by default for user
-domain_auto_trans(userdomain, pppd_exec_t, pppd_t)
 in_user_role(pppd_t)
-role sysadm_r types pppd_t;
-allow userdomain pppd_t:process signal;
-')
+if (pppd_for_user)  {
+# Run pppd in pppd_t by default for user
+domain_auto_trans(unpriv_userdomain, pppd_exec_t, pppd_t)
+allow unpriv_userdomain pppd_t:process signal;
+}
 
 # for pppoe
 can_create_pty(pppd)
diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/unused/rhgb.te policy-1.19.12/domains/program/unused/rhgb.te
--- nsapolicy/domains/program/unused/rhgb.te	2004-12-02 14:11:42.000000000 -0500
+++ policy-1.19.12/domains/program/unused/rhgb.te	2004-12-09 11:03:11.367550052 -0500
@@ -39,7 +39,7 @@
 allow rhgb_t self:capability { sys_admin sys_tty_config };
 dontaudit rhgb_t var_run_t:dir search;
 
-can_network_server(rhgb_t)
+can_network_client(rhgb_t)
 can_ypbind(rhgb_t)
 
 # for fonts
@@ -91,3 +91,5 @@
 ifdef(`fsadm.te', `
 dontaudit fsadm_t ramfs_t:fifo_file write;
 ')
+allow rhgb_t xdm_xserver_tmp_t:file { getattr read };
+dontaudit rhgb_t default_t:file read;
diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/unused/samba.te policy-1.19.12/domains/program/unused/samba.te
--- nsapolicy/domains/program/unused/samba.te	2004-12-02 14:11:42.000000000 -0500
+++ policy-1.19.12/domains/program/unused/samba.te	2004-12-09 11:03:11.368549939 -0500
@@ -115,3 +115,5 @@
 ifdef(`cups.te', `
 allow smbd_t cupsd_rw_etc_t:file { getattr read };
 ')
+# Needed for winbindd
+allow smbd_t { samba_var_t smbd_var_run_t }:sock_file create_file_perms;
diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/unused/slapd.te policy-1.19.12/domains/program/unused/slapd.te
--- nsapolicy/domains/program/unused/slapd.te	2004-10-19 16:03:06.000000000 -0400
+++ policy-1.19.12/domains/program/unused/slapd.te	2004-12-09 11:03:11.368549939 -0500
@@ -59,3 +59,4 @@
 
 allow slapd_t usr_t:file { read getattr };
 allow slapd_t urandom_device_t:chr_file { getattr read };
+allow slapd_t self:netlink_route_socket r_netlink_socket_perms;
diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/unused/squid.te policy-1.19.12/domains/program/unused/squid.te
--- nsapolicy/domains/program/unused/squid.te	2004-12-02 14:11:43.000000000 -0500
+++ policy-1.19.12/domains/program/unused/squid.te	2004-12-09 11:03:11.369549827 -0500
@@ -21,6 +21,7 @@
 allow squid_t squid_conf_t:lnk_file read;
 
 logdir_domain(squid)
+rw_dir_create_file(initrc_t, squid_log_t)
 
 allow squid_t usr_t:file { getattr read };
 
diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/unused/vpnc.te policy-1.19.12/domains/program/unused/vpnc.te
--- nsapolicy/domains/program/unused/vpnc.te	2004-11-20 22:29:09.000000000 -0500
+++ policy-1.19.12/domains/program/unused/vpnc.te	2004-12-09 11:03:11.369549827 -0500
@@ -38,3 +38,4 @@
 allow vpnc_t sbin_t:dir search;
 allow vpnc_t bin_t:dir search;
 allow vpnc_t bin_t:lnk_file read;
+r_dir_file(vpnc_t, proc_net_t)
diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/unused/ypbind.te policy-1.19.12/domains/program/unused/ypbind.te
--- nsapolicy/domains/program/unused/ypbind.te	2004-11-18 08:13:58.000000000 -0500
+++ policy-1.19.12/domains/program/unused/ypbind.te	2004-12-09 11:03:11.370549714 -0500
@@ -39,3 +39,4 @@
 allow ypbind_t self:netlink_route_socket r_netlink_socket_perms;
 allow ypbind_t reserved_port_t:tcp_socket name_bind;
 allow ypbind_t reserved_port_t:udp_socket name_bind;
+dontaudit ypbind_t reserved_port_type:udp_socket name_bind;
diff --exclude-from=exclude -N -u -r nsapolicy/file_contexts/program/apache.fc policy-1.19.12/file_contexts/program/apache.fc
--- nsapolicy/file_contexts/program/apache.fc	2004-12-09 10:26:09.571388094 -0500
+++ policy-1.19.12/file_contexts/program/apache.fc	2004-12-09 11:13:56.287029708 -0500
@@ -29,16 +29,17 @@
 /var/lib/httpd(/.*)?		system_u:object_r:httpd_var_lib_t
 /var/lib/php/session(/.*)?	system_u:object_r:httpd_var_run_t
 /etc/apache-ssl(2)?(/.*)?	system_u:object_r:httpd_config_t
-/usr/lib/apache-ssl/.+ --	system_u:object_r:httpd_exec_t
+/usr/lib/apache-ssl/.+	 --	system_u:object_r:httpd_exec_t
 /usr/sbin/apache-ssl(2)? --	system_u:object_r:httpd_exec_t
 /var/log/apache-ssl(2)?(/.*)?	system_u:object_r:httpd_log_t
 /var/run/apache-ssl(2)?\.pid.* -- system_u:object_r:httpd_var_run_t
 /var/run/gcache_port	-s	system_u:object_r:httpd_var_run_t
 ifdef(`distro_suse', `
 # suse puts shell scripts there :-(
-/usr/share/apache2/[^/]*	--	system_u:object_r:bin_t
+/usr/share/apache2/[^/]*       --      system_u:object_r:bin_t
 ')
 /var/lib/squirrelmail/prefs(/.*)?	system_u:object_r:httpd_squirrelmail_t
+/var/spool/squirrelmail(/.*)?	system_u:object_r:squirrelmail_spool_t
 /usr/bin/htsslpass --	system_u:object_r:httpd_helper_exec_t
 /usr/share/htdig(/.*)?		system_u:object_r:httpd_sys_content_t
 /var/lib/htdig(/.*)?		system_u:object_r:httpd_sys_content_t
diff --exclude-from=exclude -N -u -r nsapolicy/file_contexts/program/ipsec.fc policy-1.19.12/file_contexts/program/ipsec.fc
--- nsapolicy/file_contexts/program/ipsec.fc	2004-11-09 13:35:13.000000000 -0500
+++ policy-1.19.12/file_contexts/program/ipsec.fc	2004-12-09 11:03:11.371549602 -0500
@@ -3,6 +3,7 @@
 /etc/ipsec\.secrets	--	system_u:object_r:ipsec_key_file_t
 /etc/ipsec\.conf	--	system_u:object_r:ipsec_conf_file_t
 /etc/ipsec\.d(/.*)?		system_u:object_r:ipsec_key_file_t
+/etc/ipsec\.d/examples(/.*)?		system_u:object_r:etc_t
 /usr/lib(64)?/ipsec/.*	--	system_u:object_r:sbin_t
 /usr/lib(64)?/ipsec/_plutoload -- 	system_u:object_r:ipsec_mgmt_exec_t
 /usr/lib(64)?/ipsec/_plutorun  --	system_u:object_r:ipsec_mgmt_exec_t
@@ -24,6 +25,7 @@
 # Kame
 /usr/sbin/racoon	--	system_u:object_r:ipsec_exec_t
 /usr/sbin/setkey	--	system_u:object_r:ipsec_exec_t
+/sbin/setkey		--	system_u:object_r:ipsec_exec_t
 /etc/racoon(/.*)?		system_u:object_r:ipsec_conf_file_t
 /etc/racoon/certs(/.*)?	system_u:object_r:ipsec_key_file_t
 /etc/racoon/psk\.txt	--	system_u:object_r:ipsec_key_file_t
diff --exclude-from=exclude -N -u -r nsapolicy/file_contexts/program/portmap.fc policy-1.19.12/file_contexts/program/portmap.fc
--- nsapolicy/file_contexts/program/portmap.fc	2003-11-26 13:01:08.000000000 -0500
+++ policy-1.19.12/file_contexts/program/portmap.fc	2004-12-09 11:03:11.371549602 -0500
@@ -1,3 +1,4 @@
 # portmap
 /sbin/portmap		--	system_u:object_r:portmap_exec_t
-/sbin/pmap_dump		--	system_u:object_r:portmap_exec_t
+/usr/sbin/pmap_dump	--	system_u:object_r:portmap_helper_exec_t
+/usr/sbin/pmap_set	--	system_u:object_r:portmap_helper_exec_t
diff --exclude-from=exclude -N -u -r nsapolicy/file_contexts/program/samba.fc policy-1.19.12/file_contexts/program/samba.fc
--- nsapolicy/file_contexts/program/samba.fc	2004-06-16 13:33:37.000000000 -0400
+++ policy-1.19.12/file_contexts/program/samba.fc	2004-12-09 11:03:11.372549490 -0500
@@ -19,3 +19,5 @@
 /var/run/samba/smbd\.pid --	system_u:object_r:smbd_var_run_t
 /var/run/samba/nmbd\.pid --	system_u:object_r:nmbd_var_run_t
 /var/spool/samba(/.*)?		system_u:object_r:samba_var_t
+/usr/sbin/winbindd		--	system_u:object_r:smbd_exec_t
+/var/run/winbindd(/.*)?		system_u:object_r:smbd_var_run_t
diff --exclude-from=exclude -N -u -r nsapolicy/file_contexts/types.fc policy-1.19.12/file_contexts/types.fc
--- nsapolicy/file_contexts/types.fc	2004-12-03 14:42:07.000000000 -0500
+++ policy-1.19.12/file_contexts/types.fc	2004-12-09 11:03:11.373549377 -0500
@@ -278,7 +278,7 @@
 /etc/shadow.*		--	system_u:object_r:shadow_t
 /etc/gshadow.*		--	system_u:object_r:shadow_t
 /var/db/shadow.*	--	system_u:object_r:shadow_t
-/etc/blkid\.tab		--	system_u:object_r:etc_runtime_t
+/etc/blkid\.tab.*	--	system_u:object_r:etc_runtime_t
 /etc/fstab\.REVOKE	--	system_u:object_r:etc_runtime_t
 /etc/HOSTNAME		--	system_u:object_r:etc_runtime_t
 /etc/ioctl\.save	--	system_u:object_r:etc_runtime_t
diff --exclude-from=exclude -N -u -r nsapolicy/macros/program/apache_macros.te policy-1.19.12/macros/program/apache_macros.te
--- nsapolicy/macros/program/apache_macros.te	2004-11-29 10:24:17.000000000 -0500
+++ policy-1.19.12/macros/program/apache_macros.te	2004-12-09 11:03:11.375549152 -0500
@@ -41,9 +41,9 @@
 read_locale(httpd_$1_script_t)
 allow httpd_$1_script_t fs_t:filesystem getattr;
 allow httpd_$1_script_t self:unix_stream_socket create_socket_perms;
-allow httpd_$1_script_t proc_t:file { getattr read };
 allow httpd_$1_script_t httpd_t:unix_stream_socket { read write };
 
+allow httpd_$1_script_t { self proc_t }:file { getattr read };
 allow httpd_$1_script_t { self proc_t }:dir r_dir_perms;
 allow httpd_$1_script_t { self proc_t }:lnk_file read;
 
@@ -92,6 +92,7 @@
 #########################################################################
 can_exec_any(httpd_$1_script_t)
 allow httpd_$1_script_t etc_t:file { getattr read };
+dontaudit httpd_$1_script_t selinux_config_t:dir search;
 
 ############################################################################
 # Allow the script process to search the cgi directory, and users directory
@@ -183,4 +184,7 @@
 #########################################
 allow httpd_$1_script_t httpd_log_t:file { getattr append };
 
+# apache should set close-on-exec
+dontaudit  httpd_$1_script_t httpd_t:unix_stream_socket { read write };
+
 ')
diff --exclude-from=exclude -N -u -r nsapolicy/macros/program/inetd_macros.te policy-1.19.12/macros/program/inetd_macros.te
--- nsapolicy/macros/program/inetd_macros.te	2004-12-02 14:11:43.000000000 -0500
+++ policy-1.19.12/macros/program/inetd_macros.te	2004-12-09 11:03:11.376549040 -0500
@@ -61,4 +61,5 @@
 allow inetd_t $1_port_t:udp_socket name_bind;
 allow $1_t inetd_t:udp_socket rw_socket_perms;
 ')
+r_dir_file($1_t, proc_net_t)
 ')
diff --exclude-from=exclude -N -u -r nsapolicy/macros/program/mta_macros.te policy-1.19.12/macros/program/mta_macros.te
--- nsapolicy/macros/program/mta_macros.te	2004-12-02 14:11:43.000000000 -0500
+++ policy-1.19.12/macros/program/mta_macros.te	2004-12-09 11:03:11.378548815 -0500
@@ -34,6 +34,7 @@
 
 uses_shlib($1_mail_t)
 can_network_client_tcp($1_mail_t)
+can_resolve($1_mail_t)
 can_ypbind($1_mail_t)
 allow $1_mail_t self:unix_dgram_socket create_socket_perms;
 allow $1_mail_t self:unix_stream_socket create_socket_perms;
diff --exclude-from=exclude -N -u -r nsapolicy/macros/user_macros.te policy-1.19.12/macros/user_macros.te
--- nsapolicy/macros/user_macros.te	2004-12-09 10:26:10.334302305 -0500
+++ policy-1.19.12/macros/user_macros.te	2004-12-09 11:03:11.384548140 -0500
@@ -134,6 +140,7 @@
 attribute $1_file_type;
 # Grant read/search permissions to some of /proc.
 r_dir_file($1_t, proc_t)
+r_dir_file($1_t, proc_net_t)
 
 base_file_read_access($1_t)
 
@@ -215,27 +222,11 @@
 dontaudit $1_t init_t:fd use;
 dontaudit $1_t initrc_t:fd use;
 allow $1_t initrc_t:fifo_file write;
-ifdef(`user_can_mount', `
-#
-#  Allow users to mount file systems like floppies and cdrom
-#
-mount_domain($1, $1_mount, `, fs_domain')
-r_dir_file($1_t, mnt_t)
-allow $1_mount_t device_t:lnk_file read;
-allow $1_mount_t removable_device_t:blk_file read;
-allow $1_mount_t iso9660_t:filesystem relabelfrom;
-allow $1_mount_t removable_t:filesystem { mount relabelto };
-allow $1_mount_t removable_t:dir mounton;
-ifdef(`xdm.te', `
-allow $1_mount_t xdm_t:fd use;
-allow $1_mount_t xdm_t:fifo_file { read write };
-')
-')
 
 #
 # Rules used to associate a homedir as a mountpoint
 #
-allow $1_home_t self:filesystem associate;
+allow $1_home_t $1_home_t:filesystem associate;
 allow $1_file_type $1_home_t:filesystem associate;
 ')
 
diff --exclude-from=exclude -N -u -r nsapolicy/net_contexts policy-1.19.12/net_contexts
--- nsapolicy/net_contexts	2004-12-02 14:11:41.000000000 -0500
+++ policy-1.19.12/net_contexts	2004-12-09 11:03:11.385548028 -0500
@@ -115,6 +115,8 @@
 ')
 portcon tcp 88 system_u:object_r:kerberos_port_t
 portcon udp 88 system_u:object_r:kerberos_port_t
+portcon tcp 464 system_u:object_r:kerberos_admin_port_t
+portcon udp 464 system_u:object_r:kerberos_admin_port_t
 portcon tcp 749 system_u:object_r:kerberos_admin_port_t
 portcon tcp 750 system_u:object_r:kerberos_port_t
 portcon udp 750 system_u:object_r:kerberos_port_t
diff --exclude-from=exclude -N -u -r nsapolicy/tunables/distro.tun policy-1.19.12/tunables/distro.tun
--- nsapolicy/tunables/distro.tun	2004-08-20 13:57:29.000000000 -0400
+++ policy-1.19.12/tunables/distro.tun	2004-12-09 11:03:11.385548028 -0500
@@ -5,7 +5,7 @@
 # appropriate ifdefs.
 
 
-dnl define(`distro_redhat')
+define(`distro_redhat')
 
 dnl define(`distro_suse')
 
diff --exclude-from=exclude -N -u -r nsapolicy/tunables/tunable.tun policy-1.19.12/tunables/tunable.tun
--- nsapolicy/tunables/tunable.tun	2004-11-09 13:35:13.000000000 -0500
+++ policy-1.19.12/tunables/tunable.tun	2004-12-09 11:17:03.670958633 -0500
@@ -1,29 +1,31 @@
-# Allow users to execute the mount command
-dnl define(`user_can_mount')
-
 # Allow rpm to run unconfined.
-dnl define(`unlimitedRPM')
+define(`unlimitedRPM')
 
 # Allow privileged utilities like hotplug and insmod to run unconfined.
-dnl define(`unlimitedUtils')
+define(`unlimitedUtils')
 
 # Allow rc scripts to run unconfined, including any daemon
 # started by an rc script that does not have a domain transition
 # explicitly defined.
-dnl define(`unlimitedRC')
+define(`unlimitedRC')
 
 # Allow sysadm_t to directly start daemons
 define(`direct_sysadm_daemon')
 
 # Do not audit things that we know to be broken but which
 # are not security risks
-dnl define(`hide_broken_symptoms')
+define(`hide_broken_symptoms')
 
 # Allow user_r to reach sysadm_r via su, sudo, or userhelper.
 # Otherwise, only staff_r can do so.
-dnl define(`user_canbe_sysadm')
+define(`user_canbe_sysadm')
 
 # Allow xinetd to run unconfined, including any services it starts
 # that do not have a domain transition explicitly defined.
 dnl define(`unlimitedInetd')
 
+# for ndc_t to be used for restart shell scripts
+dnl define(`ndc_shell_script')
+
+# To allow staff and user to share the same homedirectory file labels
+dnl define(`single_user_file_type')

Re: Some more fixes

[Thomas Bleher]

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

A few comments:

* Daniel J Walsh <dwalsh@redhat.com> [2004-12-09 19:01]:
> diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/ldconfig.te policy-1.19.12/domains/program/ldconfig.te
> --- nsapolicy/domains/program/ldconfig.te	2004-12-09 10:26:08.603496932 -0500
> +++ policy-1.19.12/domains/program/ldconfig.te	2004-12-09 11:05:48.845841826 -0500
> @@ -44,3 +44,4 @@
>  ')
>  
>  allow ldconfig_t proc_t:file read;
> +dontaudit ldconfig_t unconfined_t:tcp_socket { read write };

This needs an ifdef(`unconfined.te' around it.

> diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/unused/kudzu.te policy-1.19.12/domains/program/unused/kudzu.te
> --- nsapolicy/domains/program/unused/kudzu.te	2004-12-09 10:26:09.150435429 -0500
> +++ policy-1.19.12/domains/program/unused/kudzu.te	2004-12-09 11:03:11.362550614 -0500
> @@ -16,6 +16,7 @@
>  
>  allow kudzu_t ramfs_t:dir search;
>  allow kudzu_t ramfs_t:sock_file write;
> +allow kudzu_t etc_t:file { getattr read };

I just sent in a patch to remove this, because on line 54, there's
already rw_dir_create_file(kudzu_t, etc_t)

> diff --exclude-from=exclude -N -u -r nsapolicy/macros/user_macros.te policy-1.19.12/macros/user_macros.te
> --- nsapolicy/macros/user_macros.te	2004-12-09 10:26:10.334302305 -0500
> +++ policy-1.19.12/macros/user_macros.te	2004-12-09 11:03:11.384548140 -0500
> @@ -215,27 +222,11 @@
>  dontaudit $1_t init_t:fd use;
>  dontaudit $1_t initrc_t:fd use;
>  allow $1_t initrc_t:fifo_file write;
> -ifdef(`user_can_mount', `
> -#
> -#  Allow users to mount file systems like floppies and cdrom
> -#
> -mount_domain($1, $1_mount, `, fs_domain')
> -r_dir_file($1_t, mnt_t)
> -allow $1_mount_t device_t:lnk_file read;
> -allow $1_mount_t removable_device_t:blk_file read;
> -allow $1_mount_t iso9660_t:filesystem relabelfrom;
> -allow $1_mount_t removable_t:filesystem { mount relabelto };
> -allow $1_mount_t removable_t:dir mounton;
> -ifdef(`xdm.te', `
> -allow $1_mount_t xdm_t:fd use;
> -allow $1_mount_t xdm_t:fifo_file { read write };
> -')
> -')

I don't think this should be removed. No idea how Fedora handles this
but at least on my system I still need it because I neither use udev nor
hal. As it's already in a tunable, I think you can just disable this
tunable on Fedora.

>  
>  #
>  # Rules used to associate a homedir as a mountpoint
>  #
> -allow $1_home_t self:filesystem associate;
> +allow $1_home_t $1_home_t:filesystem associate;
>  allow $1_file_type $1_home_t:filesystem associate;
>  ')

Ahh, this was just fixed in a patch from me. Should be left as it is.

Thomas

-- 
http://www.cip.ifi.lmu.de/~bleher/selinux/ - my SELinux pages
GPG-Fingerprint: BC4F BB16 30D6 F253 E3EA  D09E C562 2BAE B2F4 ABE7

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Some more fixes

[James Carter]

Merged with some changes.

On Thu, 2004-12-09 at 11:31, Daniel J Walsh wrote:
> Many fixes for initrc required by turning off unlimitedRC
> 
> Fixes for ipsec
> 
> Fixes for ifdefs of targeted policy
> 
> Added new booleans to replace tunables
> 
> allow_user_mysql_connect &  allow_user_postgresql_connect &  pppd_for_user
> 
> Fixed some can_network_* calls.
> 
> Added support for winbindd
> 
> Added a portmap_helper domain for pmap_dump and pmap_set.  Not sure if I 
> like this?  Looking for comments.
> 
> Remove user_can_mount tunable
> 
> 
> 
> ______________________________________________________________________
> diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/initrc.te policy-1.19.12/domains/program/initrc.te
> --- nsapolicy/domains/program/initrc.te	2004-12-09 10:26:08.583499181 -0500
> +++ policy-1.19.12/domains/program/initrc.te	2004-12-09 11:03:11.335553650 -0500
> @@ -217,6 +218,9 @@
>  allow initrc_t tmpfs_t:chr_file rw_file_perms;
>  allow initrc_t tmpfs_t:dir r_dir_perms;
>  
> +# Allow initrc domain to set the enforcing flag.
> +can_setenforce(initrc_t)
> +
>  #
>  # readahead asks for these
>  #

I put an ifdef(`distro_redhat' around this.

> diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/ldconfig.te policy-1.19.12/domains/program/ldconfig.te
> --- nsapolicy/domains/program/ldconfig.te	2004-12-09 10:26:08.603496932 -0500
> +++ policy-1.19.12/domains/program/ldconfig.te	2004-12-09 11:05:48.845841826 -0500
> @@ -44,3 +44,4 @@
>  ')
>  
>  allow ldconfig_t proc_t:file read;
> +dontaudit ldconfig_t unconfined_t:tcp_socket { read write };

As Thomas Bleher mentioned, I put a ifdef(`unconfined.te' around this.


> diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/unused/kudzu.te policy-1.19.12/domains/program/unused/kudzu.te
> --- nsapolicy/domains/program/unused/kudzu.te	2004-12-09 10:26:09.150435429 -0500
> +++ policy-1.19.12/domains/program/unused/kudzu.te	2004-12-09 11:03:11.362550614 -0500
> @@ -16,6 +16,7 @@
>  
>  allow kudzu_t ramfs_t:dir search;
>  allow kudzu_t ramfs_t:sock_file write;
> +allow kudzu_t etc_t:file { getattr read };
>  allow kudzu_t self:capability { dac_override sys_admin sys_rawio net_admin sys_tty_config mknod };
>  allow kudzu_t modules_conf_t:file { getattr read };
>  allow kudzu_t modules_object_t:dir r_dir_perms;

As Thomas Bleher mentioned, this rule is redudant.

> diff --exclude-from=exclude -N -u -r nsapolicy/macros/user_macros.te policy-1.19.12/macros/user_macros.te
> --- nsapolicy/macros/user_macros.te	2004-12-09 10:26:10.334302305 -0500
> +++ policy-1.19.12/macros/user_macros.te	2004-12-09 11:03:11.384548140 -0500
> @@ -134,6 +140,7 @@
>  attribute $1_file_type;
>  # Grant read/search permissions to some of /proc.
>  r_dir_file($1_t, proc_t)
> +r_dir_file($1_t, proc_net_t)
>  
>  base_file_read_access($1_t)
>  
> @@ -215,27 +222,11 @@
>  dontaudit $1_t init_t:fd use;
>  dontaudit $1_t initrc_t:fd use;
>  allow $1_t initrc_t:fifo_file write;
> -ifdef(`user_can_mount', `
> -#
> -#  Allow users to mount file systems like floppies and cdrom
> -#
> -mount_domain($1, $1_mount, `, fs_domain')
> -r_dir_file($1_t, mnt_t)
> -allow $1_mount_t device_t:lnk_file read;
> -allow $1_mount_t removable_device_t:blk_file read;
> -allow $1_mount_t iso9660_t:filesystem relabelfrom;
> -allow $1_mount_t removable_t:filesystem { mount relabelto };
> -allow $1_mount_t removable_t:dir mounton;
> -ifdef(`xdm.te', `
> -allow $1_mount_t xdm_t:fd use;
> -allow $1_mount_t xdm_t:fifo_file { read write };
> -')
> -')
>  
>  #
>  # Rules used to associate a homedir as a mountpoint
>  #
> -allow $1_home_t self:filesystem associate;
> +allow $1_home_t $1_home_t:filesystem associate;
>  allow $1_file_type $1_home_t:filesystem associate;
>  ')
>  

I didn't remove this, since there still seems to be interest in it. 
Perhaps it should be moved to a distro_tunable?

> diff --exclude-from=exclude -N -u -r nsapolicy/tunables/tunable.tun policy-1.19.12/tunables/tunable.tun
> --- nsapolicy/tunables/tunable.tun	2004-11-09 13:35:13.000000000 -0500
> +++ policy-1.19.12/tunables/tunable.tun	2004-12-09 11:17:03.670958633 -0500
> @@ -1,29 +1,31 @@
> -# Allow users to execute the mount command
> -dnl define(`user_can_mount')
> -
>  # Allow rpm to run unconfined.
> -dnl define(`unlimitedRPM')
> +define(`unlimitedRPM')
>  
>  # Allow privileged utilities like hotplug and insmod to run unconfined.
> -dnl define(`unlimitedUtils')
> +define(`unlimitedUtils')
>  
>  # Allow rc scripts to run unconfined, including any daemon
>  # started by an rc script that does not have a domain transition
>  # explicitly defined.
> -dnl define(`unlimitedRC')
> +define(`unlimitedRC')
>  
>  # Allow sysadm_t to directly start daemons
>  define(`direct_sysadm_daemon')
>  
>  # Do not audit things that we know to be broken but which
>  # are not security risks
> -dnl define(`hide_broken_symptoms')
> +define(`hide_broken_symptoms')
>  
>  # Allow user_r to reach sysadm_r via su, sudo, or userhelper.
>  # Otherwise, only staff_r can do so.
> -dnl define(`user_canbe_sysadm')
> +define(`user_canbe_sysadm')
>  
>  # Allow xinetd to run unconfined, including any services it starts
>  # that do not have a domain transition explicitly defined.
>  dnl define(`unlimitedInetd')
>  
> +# for ndc_t to be used for restart shell scripts
> +dnl define(`ndc_shell_script')
> +
> +# To allow staff and user to share the same homedirectory file labels
> +dnl define(`single_user_file_type')

I did not remove the user_can_mount tunable.
I did not add the single_user_file_type tunable.

-- 
James Carter <jwcart2@epoch.ncsc.mil>
National Security Agency

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

Single home directory type for all roles.

[Daniel J Walsh]

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

One of the things that we de-emphasized in the Fedora Releases of 
SELinux up til not is the RBAC support.  We
have basically made staff_r and user_r almost equivalent.  The reason we 
did this, is that we felt the system was
unmanagable for a normal administrators and would just result in SELinux 
getting a bad name and being turned off.
So for the first release of FC2 we turned off alot of the handling of 
roles.  Now that we have developed targeted policy
we are reviting some of the decisions we made around strict policy and 
working to make it "stricter".  

One problem I still have with RBAC though is the labeling of files based 
on the role of the user.  IE (staff_home_t versus
user_home_t).  I believe this causes many problems, without much benefit.

1.  Causes problems with sharing files between users,   IE a staff user 
coping a file to tmp and then the user
can't read it, because it has the wrong type. 
2.  Requirement that selinux-policy-strict-sources be installed and a 
rebuild of policy in order to change the roles of a user.
3.  But the number one problem I have is with relabeling files.  If I 
were to implement roles management in
system-config-securitylevel/adduser, I would need to trigger a relabel 
any time a role of a user was changed.  This
relabel would have to be inteligent enough to figure out not only the 
home directories, but also the files in /tmp and potentially
files in html files scattered over the system.  I find this an 
unworkable situation.

So yesterday I went though the policy and created a new tunable 
single_user_file_type, that causes the policy to share a common
filetypes between staff and users.  (Haven't completed this for http yet). 

With this tunable and the new SELinux Policy Modules.  I believe we can 
begin to implement a sane mechanism for handling roles
without causing the problems addressed above.

With SELinux Policy Modules, can I build an system-config-user/adduser 
that would modify a file under /etc/selinux/strict/roles/
(the users file) and then reload just that policy?

Comments????

Dan

[-- Attachment #2: diff --]
[-- Type: text/plain, Size: 10130 bytes --]

diff --exclude-from=exclude -N -u -r policy-1.19.12/macros/global_macros.te policy-1.19.12.new/macros/global_macros.te
--- policy-1.19.12/macros/global_macros.te	2004-12-09 11:01:28.000000000 -0500
+++ policy-1.19.12.new/macros/global_macros.te	2004-12-09 11:03:11.374549265 -0500
@@ -573,3 +573,19 @@
 ')
 
 ')dnl end unconfined_domain
+
+define(`create_user_file_type', `
+ifdef(`single_user_file_type', `
+ifelse($1, user, `
+type $1_$2, file_type, sysadmfile $3;
+', `
+ifelse($1, sysadm, `
+type $1_$2, file_type, sysadmfile $3;
+', `
+typealias user_$2 alias $1_$2;
+') dnl ifelse sysadm
+') dnl ifelse user
+', `
+type $1_$2, file_type, sysadmfile $3;
+') dnl ifdef single_user_file_type
+') dnl define create_user_file_type
diff --exclude-from=exclude -N -u -r policy-1.19.12/macros/program/fingerd_macros.te policy-1.19.12.new/macros/program/fingerd_macros.te
--- policy-1.19.12/macros/program/fingerd_macros.te	2004-12-09 11:01:28.000000000 -0500
+++ policy-1.19.12.new/macros/program/fingerd_macros.te	2004-12-09 11:03:11.375549152 -0500
@@ -10,6 +10,6 @@
 # allow fingerd to create a fingerlog file in the user home dir
 #
 define(`fingerd_macro', `
-type $1_home_fingerlog_t, file_type, sysadmfile, $1_file_type;
+create_user_file_type($1, `home_fingerlog_t', `, $1_file_type')
 file_type_auto_trans(fingerd_t, $1_home_dir_t, $1_home_fingerlog_t)
 ')
diff --exclude-from=exclude -N -u -r policy-1.19.12/macros/program/gpg_macros.te policy-1.19.12.new/macros/program/gpg_macros.te
--- policy-1.19.12/macros/program/gpg_macros.te	2004-12-09 11:01:28.000000000 -0500
+++ policy-1.19.12.new/macros/program/gpg_macros.te	2004-12-09 11:03:11.376549040 -0500
@@ -19,7 +19,7 @@
 define(`gpg_domain', `
 # Derived domain based on the calling user domain and the program.
 type $1_gpg_t, domain, privlog;
-type $1_gpg_secret_t, file_type, $1_file_type, sysadmfile, $1_file_type;
+create_user_file_type($1, `gpg_secret_t', `, $1_file_type')
 
 # Transition from the user domain to the derived domain.
 domain_auto_trans($1_t, gpg_exec_t, $1_gpg_t)
diff --exclude-from=exclude -N -u -r policy-1.19.12/macros/program/irc_macros.te policy-1.19.12.new/macros/program/irc_macros.te
--- policy-1.19.12/macros/program/irc_macros.te	2004-12-09 11:01:28.000000000 -0500
+++ policy-1.19.12.new/macros/program/irc_macros.te	2004-12-09 11:03:11.377548927 -0500
@@ -20,7 +20,7 @@
 define(`irc_domain',`
 # Derived domain based on the calling user domain and the program.
 type $1_irc_t, domain;
-type $1_home_irc_t, file_type, $1_file_type, sysadmfile;
+create_user_file_type($1, `home_irc_t', `, $1_file_type')
 type $1_irc_exec_t, file_type, sysadmfile;
 
 ifdef(`slocate.te', `
diff --exclude-from=exclude -N -u -r policy-1.19.12/macros/program/mount_macros.te policy-1.19.12.new/macros/program/mount_macros.te
--- policy-1.19.12/macros/program/mount_macros.te	2004-12-09 11:01:28.000000000 -0500
+++ policy-1.19.12.new/macros/program/mount_macros.te	2004-12-09 11:03:11.377548927 -0500
@@ -83,7 +83,7 @@
 # mount domain. 
 #
 define(`mount_loopback_privs',`
-type $1_$2_source_t, file_type, sysadmfile, $1_file_type;
+create_user_file_type($1, `$2_source_t', `, $1_file_type')
 allow $1_t $1_$2_source_t:file create_file_perms;
 allow $1_t $1_$2_source_t:file { relabelto relabelfrom };
 allow $2_t $1_$2_source_t:file rw_file_perms;
diff --exclude-from=exclude -N -u -r policy-1.19.12/macros/program/screen_macros.te policy-1.19.12.new/macros/program/screen_macros.te
--- policy-1.19.12/macros/program/screen_macros.te	2004-12-09 11:01:28.000000000 -0500
+++ policy-1.19.12.new/macros/program/screen_macros.te	2004-12-09 11:03:11.378548815 -0500
@@ -22,7 +22,7 @@
 define(`screen_domain',`
 # Derived domain based on the calling user domain and the program.
 type $1_screen_t, domain, privlog, privfd;
-type $1_home_screen_t, file_type, $1_file_type, sysadmfile;
+create_user_file_type($1, `home_screen_t', `, $1_file_type')
 
 # Transition from the user domain to this domain.
 domain_auto_trans($1_t, screen_exec_t, $1_screen_t)
diff --exclude-from=exclude -N -u -r policy-1.19.12/macros/program/spamassassin_macros.te policy-1.19.12.new/macros/program/spamassassin_macros.te
--- policy-1.19.12/macros/program/spamassassin_macros.te	2004-12-09 11:01:28.000000000 -0500
+++ policy-1.19.12.new/macros/program/spamassassin_macros.te	2004-12-09 11:03:11.379548702 -0500
@@ -80,7 +80,7 @@
 dontaudit $1_spamassassin_t { sysctl_t sysctl_kernel_t }:dir search;
 
 # The type of ~/.spamassassin
-type $1_home_spamassassin_t, file_type, $1_file_type, sysadmfile;
+create_user_file_type($1, `home_spamassassin_t', `, $1_file_type')
 create_dir_file($1_t, $1_home_spamassassin_t)
 allow $1_t $1_home_spamassassin_t:notdevfile_class_set { relabelfrom relabelto };
 allow $1_t $1_home_spamassassin_t:dir { relabelfrom relabelto };
diff --exclude-from=exclude -N -u -r policy-1.19.12/macros/program/ssh_macros.te policy-1.19.12.new/macros/program/ssh_macros.te
--- policy-1.19.12/macros/program/ssh_macros.te	2004-12-09 11:01:28.000000000 -0500
+++ policy-1.19.12.new/macros/program/ssh_macros.te	2004-12-09 11:03:11.380548590 -0500
@@ -22,7 +22,7 @@
 define(`ssh_domain',`
 # Derived domain based on the calling user domain and the program.
 type $1_ssh_t, domain, privlog, nscd_client_domain;
-type $1_home_ssh_t, file_type, $1_file_type, sysadmfile;
+create_user_file_type($1, `home_ssh_t', `, $1_file_type')
 
 ifdef(`automount.te', `
 allow $1_ssh_t autofs_t:dir { search getattr };
diff --exclude-from=exclude -N -u -r policy-1.19.12/macros/program/tvtime_macros.te policy-1.19.12.new/macros/program/tvtime_macros.te
--- policy-1.19.12/macros/program/tvtime_macros.te	2004-12-09 11:01:28.000000000 -0500
+++ policy-1.19.12.new/macros/program/tvtime_macros.te	2004-12-09 11:03:11.381548478 -0500
@@ -19,7 +19,7 @@
 ifdef(`tvtime.te', `
 define(`tvtime_domain',`
 # Derived domain based on the calling user domain and the program.
-type $1_home_tvtime_t, file_type, $1_file_type, sysadmfile;
+create_user_file_type($1, `home_tvtime_t', `, $1_file_type')
 
 x_client_domain($1, tvtime)
 
diff --exclude-from=exclude -N -u -r policy-1.19.12/macros/program/uml_macros.te policy-1.19.12.new/macros/program/uml_macros.te
--- policy-1.19.12/macros/program/uml_macros.te	2004-12-09 11:01:28.000000000 -0500
+++ policy-1.19.12.new/macros/program/uml_macros.te	2004-12-09 11:03:11.381548478 -0500
@@ -22,8 +22,8 @@
 # Derived domain based on the calling user domain and the program.
 type $1_uml_t, domain;
 type $1_uml_exec_t, file_type, sysadmfile, $1_file_type;
-type $1_uml_ro_t, file_type, sysadmfile, $1_file_type;
-type $1_uml_rw_t, file_type, sysadmfile, $1_file_type;
+create_user_file_type($1, `uml_ro_t', `, $1_file_type')
+create_user_file_type($1, `uml_rw_t', `, $1_file_type')
 
 can_ptrace($1_t, $1_uml_t)
 
diff --exclude-from=exclude -N -u -r policy-1.19.12/macros/program/vmware_macros.te policy-1.19.12.new/macros/program/vmware_macros.te
--- policy-1.19.12/macros/program/vmware_macros.te	2004-12-09 11:01:28.000000000 -0500
+++ policy-1.19.12.new/macros/program/vmware_macros.te	2004-12-09 11:03:11.382548365 -0500
@@ -23,10 +23,10 @@
 role $1_r types $1_vmware_t;
 
 # The user file type is for files created when the user is running VMWare
-type $1_vmware_file_t, $1_file_type, file_type, sysadmfile;
+create_user_file_type($1, `vmware_file_t', `, $1_file_type')
 
 # The user file type for the VMWare configuration files
-type $1_vmware_conf_t, $1_file_type, file_type, sysadmfile;
+type $1_vmware_conf_t, $1_file_type, file_type, sysadmfile, $1_file_type;
 
 # for compatibility with older policy versions
 typealias $1_vmware_t alias vmware_$1_t;
diff --exclude-from=exclude -N -u -r policy-1.19.12/macros/program/xauth_macros.te policy-1.19.12.new/macros/program/xauth_macros.te
--- policy-1.19.12/macros/program/xauth_macros.te	2004-12-09 11:01:28.000000000 -0500
+++ policy-1.19.12.new/macros/program/xauth_macros.te	2004-12-09 11:15:54.468740331 -0500
@@ -20,7 +20,8 @@
 define(`xauth_domain',`
 # Derived domain based on the calling user domain and the program.
 type $1_xauth_t, domain;
-type $1_home_xauth_t, file_type, $1_file_type, sysadmfile;
+
+create_user_file_type($1, `home_xauth_t', `, $1_file_type')
 
 allow $1_xauth_t self:process signal;
 
diff --exclude-from=exclude -N -u -r policy-1.19.12/macros/program/x_client_macros.te policy-1.19.12.new/macros/program/x_client_macros.te
--- policy-1.19.12/macros/program/x_client_macros.te	2004-12-09 11:01:28.000000000 -0500
+++ policy-1.19.12.new/macros/program/x_client_macros.te	2004-12-09 11:16:14.973434606 -0500
@@ -25,9 +25,9 @@
 # Derived domain based on the calling user domain and the program.
 type $1_$2_t, domain $3;
 # Type for files that are writeable by this domain.
-type $1_$2_rw_t, file_type, $1_file_type, sysadmfile, tmpfile;
+create_user_file_type($1, `$2_rw_t', `, tmpfile, $1_file_type')
 # Type for files that are read-only for this domain
-type $1_$2_ro_t, file_type, $1_file_type, sysadmfile;
+create_user_file_type($1, `$2_ro_t', `, $1_file_type')
 
 # Transition from the user domain to the derived domain.
 ifelse($2, games, `
diff --exclude-from=exclude -N -u -r policy-1.19.12/macros/user_macros.te policy-1.19.12.new/macros/user_macros.te
--- policy-1.19.12/macros/user_macros.te	2004-12-09 11:22:43.634730157 -0500
+++ policy-1.19.12.new/macros/user_macros.te	2004-12-09 11:03:11.384548140 -0500
@@ -18,8 +18,8 @@
 # Use capabilities
 
 # Type for home directory.
-type $1_home_dir_t, file_type, sysadmfile, home_dir_type, home_type, user_home_dir_type;
-type $1_home_t, file_type, sysadmfile, home_type, user_home_type, $1_file_type;
+create_user_file_type($1, `home_dir_t', `, home_dir_type, home_type, user_home_dir_type')
+create_user_file_type($1, `home_t', `, home_type, user_home_type, $1_file_type')
 
 tmp_domain($1, `, user_tmpfile, $1_file_type')
 
@@ -109,7 +109,13 @@
 
 ifdef(`ftpd.te', `
 if (ftp_home_dir) {
+ifdef(`single_user_file_type', `
+ifelse($1, user, `
 file_type_auto_trans(ftpd_t, $1_home_dir_t, $1_home_t)
+')
+', `
+file_type_auto_trans(ftpd_t, $1_home_dir_t, $1_home_t)
+')
 }
 ')dnl end ifdef ftpd
 

Re: Single home directory type for all roles.

[Stephen Smalley]

On Thu, 2004-12-09 at 11:50, Daniel J Walsh wrote:
> One problem I still have with RBAC though is the labeling of files based 
> on the role of the user.  IE (staff_home_t versus
> user_home_t).  I believe this causes many problems, without much benefit.

The benefit is providing separation among the roles.  If user_t can
write to staff_home_t, then the only thing preventing a user_t process
from injecting arbitrary commands into a staff user's .bashrc file or
otherwise corrupting a staff user's data or reading arbitrary files
created by the staff user is DAC.    

> 1.  Causes problems with sharing files between users,   IE a staff user 
> coping a file to tmp and then the user
> can't read it, because it has the wrong type. 

If you want to share files, you just need to define a file type that is
accessible to both domains and label the shared directory with it.  Then
users from both roles can create and modify content under that shared
directory without losing protection on their own data.  Note that
unifying the home directory type doesn't solve #1 for you, because cp
/home/user/foo /tmp/foo will create /tmp/foo in the default type, e.g.
staff_tmp_t; cp only preserves contexts when explicitly told to do so. 
And unifying the temporary types would again open a vulnerability
between the roles, classical insecure tmp file issues.

> 2.  Requirement that selinux-policy-strict-sources be installed and a 
> rebuild of policy in order to change the roles of a user.

You mean to update the file_contexts?  One could certainly build a tool
to apply selective modifications to an existing file_contexts
configuration without requiring the full sources.

> 3.  But the number one problem I have is with relabeling files.  If I 
> were to implement roles management in
> system-config-securitylevel/adduser, I would need to trigger a relabel 
> any time a role of a user was changed.  This
> relabel would have to be inteligent enough to figure out not only the 
> home directories, but also the files in /tmp and potentially
> files in html files scattered over the system.  I find this an 
> unworkable situation.

Not clear that such relabeling should be automatic anyway.  Some
review/sanitization may be necessary.

> With SELinux Policy Modules, can I build an system-config-user/adduser 
> that would modify a file under /etc/selinux/strict/roles/
> (the users file) and then reload just that policy?

You can actually do that today without policy modules.  Recall that I
created a genpolusers utility a while back that takes an existing binary
policy and a new users text configuration and generates a new binary
policy that is identical except it has the new user declarations.  So
you only need a copy of the users source file on the machine, and you
can then modify it, use genpolusers to rebuild the binary policy against
it, and then load the new binary policy.
 
-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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: Single home directory type for all roles.

[Stephen Smalley]

On Thu, 2004-12-09 at 12:20, Stephen Smalley wrote:
> You can actually do that today without policy modules.  Recall that I
> created a genpolusers utility a while back that takes an existing binary
> policy and a new users text configuration and generates a new binary
> policy that is identical except it has the new user declarations.  So
> you only need a copy of the users source file on the machine, and you
> can then modify it, use genpolusers to rebuild the binary policy against
> it, and then load the new binary policy.

BTW, note that the copy of the users source on the machine would need to
be a post-processed copy, after m4 has processed it.  For example,
during policy build, you could do:
	m4 tunables/*.tun tmp/program_used_flags.te users serviceusers > users.final

And then install that users.final file as part of the policy package, for use by
genpolusers, e.g.
	genpolusers policy.18 users.final policy-new.18
	mv policy-new.18 policy.18

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


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

Manipulating user roles without policy-sources installed

[Daniel J Walsh]

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

Take a look at this patch that will install the users file on the system 
and allow local admins to manipulate  a local.users file.
We still need to handle file context though, perhaps include filecontext 
file pre genhomedircon.

I want to change genpolusers syntax to be

genpolusers inpolicy outpolicy userfile1 [userfile2 ... ]

So if I add a user to /etc/selinux/strict/users/local.users I execute

genpolusers /etc/selinux/strict/policy/policy.18 
/etc/selinux/strict/policy/policy.18.new 
/etc/selinux/strict/users/system.users \ 
/etc/selinux/strict/users/local.users
mv -f /etc/selinux/strict/policy/policy.18.new 
/etc/selinux/strict/policy/policy.18
load_policy /etc/selinux/strict/policy/policy.18

Tools like useradd and system-config-users can start to manipulate 
/etc/selinux/strict/users/local.users, to setup roles.


[-- Attachment #2: policy-users.patch --]
[-- Type: text/x-patch, Size: 3540 bytes --]

diff --exclude-from=exclude -N -u -r nsapolicy/local.users policy-1.19.12/local.users
--- nsapolicy/local.users	1969-12-31 19:00:00.000000000 -0500
+++ policy-1.19.12/local.users	2004-12-10 10:59:20.750916770 -0500
@@ -0,0 +1,25 @@
+##################################
+#
+# User configuration.
+#
+# This file defines additional users recognized by the system security policy.
+# Only the user identities defined in this file and the users.system file
+# may be used as the user attribute in a security context.
+#
+# Each user has a set of roles that may be entered by processes
+# with the users identity.  The syntax of a user declaration is:
+#
+# 	user username roles role_set [ ranges MLS_range_set ];
+#
+# The MLS range set should only be specified if MLS was enabled
+# for the module and checkpolicy.
+
+# sample for administrative user
+#user jadmin roles { staff_r sysadm_r };
+
+# or if you want to be able to directly start daemons 
+
+#user jadmin roles { staff_r sysadm_r system_r };
+
+# sample for regular user
+#user jdoe roles { user_r }; 
diff --exclude-from=exclude -N -u -r nsapolicy/Makefile policy-1.19.12/Makefile
--- nsapolicy/Makefile	2004-10-25 14:01:13.000000000 -0400
+++ policy-1.19.12/Makefile	2004-12-10 10:54:18.524901686 -0500
@@ -26,6 +26,7 @@
 INSTALLDIR = $(DESTDIR)/etc/selinux/strict
 POLICYPATH = $(INSTALLDIR)/policy
 SRCPATH = $(INSTALLDIR)/src
+USERPATH = $(INSTALLDIR)/users
 CONTEXTPATH = $(INSTALLDIR)/contexts
 LOADPATH = $(POLICYPATH)/$(POLICYVER)
 FCPATH = $(CONTEXTPATH)/files/file_contexts
@@ -37,13 +38,13 @@
 ALLTEFILES := attrib.te tmp/program_used_flags.te $(ALL_MACROS) $(ALL_TYPES) $(ALL_DOMAINS) assert.te 
 TE_RBAC_FILES := $(ALLTEFILES) rbac
 ALL_TUNABLES := $(wildcard tunables/*.tun )
-
+USER_FILES := users serviceusers
 POLICYFILES = $(addprefix $(FLASKDIR),security_classes initial_sids access_vectors)
 ifeq ($(MLS),y)
 POLICYFILES += mls
 endif
 POLICYFILES += $(ALL_TUNABLES) $(TE_RBAC_FILES)
-POLICYFILES += users serviceusers
+POLICYFILES += $(USER_FILES)
 POLICYFILES += constraints initial_sid_contexts fs_use genfs_contexts net_contexts
 
 UNUSED_TE_FILES := $(wildcard domains/program/unused/*.te)
@@ -54,9 +55,23 @@
 APPDIR=$(CONTEXTPATH)
 APPFILES = $(addprefix $(APPDIR)/,default_contexts default_type initrc_context failsafe_context userhelper_context removable_context dbus_contexts) $(CONTEXTPATH)/files/media
 
+$(USERPATH)/system.users: $(ALL_TUNABLES) $(USER_FILES) policy.conf
+	@mkdir -p $(USERPATH)
+	@echo "# " > tmp/system.users
+	@echo "# Do not edit this file. " >> tmp/system.users
+	@echo "# This file is replaced on reinstalls of this policy." >> tmp/system.users
+	@echo "# Please edit users.custom to make local changes." >> tmp/system.users
+	@echo "#" >> tmp/system.users
+	m4 $(ALL_TUNABLES) tmp/program_used_flags.te $(USER_FILES) | grep -h -v "^#" | grep [a-zA-Z] >> tmp/system.users
+	install -m 644 tmp/system.users $@
+
+$(USERPATH)/local.users: local.users
+	@mkdir -p $(USERPATH)
+	install -m 644 $< $@
+
 ROOTFILES = $(addprefix $(APPDIR)/users/,root)
 
-install: $(APPFILES) $(ROOTFILES) $(LOADPATH) $(FCPATH) 
+install: $(APPFILES) $(ROOTFILES) $(LOADPATH) $(FCPATH) $(USERPATH)/system.users $(USERPATH)/local.users
 	@echo "Validating file_contexts ..."	
 	$(SETFILES) -q -c $(LOADPATH) $(FCPATH)
 
@@ -99,6 +114,7 @@
 $(LOADPATH):  policy.conf $(CHECKPOLICY)
 	mkdir -p $(POLICYPATH)
 	$(CHECKPOLICY) -o $@ policy.conf
+
 # Note: Can't use install, so not sure how to deal with mode, user, and group
 #	other than by default.
 

Re: Manipulating user roles without policy-sources installed

[Stephen Smalley]

On Fri, 2004-12-10 at 11:23, Daniel J Walsh wrote:
> I want to change genpolusers syntax to be
> 
> genpolusers inpolicy outpolicy userfile1 [userfile2 ... ]

Yes, that's easy enough to do, and as no one has used genpolusers to
date AFAIK, changing the interface is ok with me.

________________________________________________________________________
> diff --exclude-from=exclude -N -u -r nsapolicy/local.users policy-1.19.12/local.users
> --- nsapolicy/local.users	1969-12-31 19:00:00.000000000 -0500
> +++ policy-1.19.12/local.users	2004-12-10 10:59:20.750916770 -0500
> +# or if you want to be able to directly start daemons 
> +
> +#user jadmin roles { staff_r sysadm_r system_r };

Rather than just have this as a comment in the file, why not use an
ifdef in the source file here and apply m4 to it as well so that there
is a single line in the installed file that either includes system_r or
does not based on what tunables were set when the policy was built? 
Reduces user confusion, particularly since you are always enabling
direct_sysadm_daemon for FC and it is also needed for rpm %post
scriptlet processing in a number of cases.

> diff --exclude-from=exclude -N -u -r nsapolicy/Makefile policy-1.19.12/Makefile
> --- nsapolicy/Makefile	2004-10-25 14:01:13.000000000 -0400
> +++ policy-1.19.12/Makefile	2004-12-10 10:54:18.524901686 -0500
> +$(USERPATH)/system.users: $(ALL_TUNABLES) $(USER_FILES) policy.conf
> +	@mkdir -p $(USERPATH)
> +	@echo "# " > tmp/system.users
> +	@echo "# Do not edit this file. " >> tmp/system.users
> +	@echo "# This file is replaced on reinstalls of this policy." >> tmp/system.users
> +	@echo "# Please edit users.custom to make local changes." >> tmp/system.users
> +	@echo "#" >> tmp/system.users
> +	m4 $(ALL_TUNABLES) tmp/program_used_flags.te $(USER_FILES) | grep -h -v "^#" | grep [a-zA-Z] >> tmp/system.users
> +	install -m 644 tmp/system.users $@

The comment says "users.custom", but you've named it "local.users".
I'm also unclear on the purpose of the grep's - just to make it more
readable?  If you just want the user statement, you could just grep for
lines beginning with user unless you are worried about multi-line user
statements in the base policy (which is allowed by checkpolicy, since it
uses a semicolon terminator).

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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: Manipulating user roles without policy-sources installed

[Daniel J Walsh]

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

Stephen Smalley wrote:

>On Fri, 2004-12-10 at 11:23, Daniel J Walsh wrote:
>  
>
>>I want to change genpolusers syntax to be
>>
>>genpolusers inpolicy outpolicy userfile1 [userfile2 ... ]
>>    
>>
>
>Yes, that's easy enough to do, and as no one has used genpolusers to
>date AFAIK, changing the interface is ok with me.
>
>________________________________________________________________________
>  
>
>>diff --exclude-from=exclude -N -u -r nsapolicy/local.users policy-1.19.12/local.users
>>--- nsapolicy/local.users	1969-12-31 19:00:00.000000000 -0500
>>+++ policy-1.19.12/local.users	2004-12-10 10:59:20.750916770 -0500
>>+# or if you want to be able to directly start daemons 
>>+
>>+#user jadmin roles { staff_r sysadm_r system_r };
>>    
>>
>
>Rather than just have this as a comment in the file, why not use an
>ifdef in the source file here and apply m4 to it as well so that there
>is a single line in the installed file that either includes system_r or
>does not based on what tunables were set when the policy was built? 
>Reduces user confusion, particularly since you are always enabling
>direct_sysadm_daemon for FC and it is also needed for rpm %post
>scriptlet processing in a number of cases.
>
>  
>
Ok, I did that, but had to hack a little to get it to work.   Basically 
had to uncomment it in the original source and
sed it back to a comment for the final version.

>>diff --exclude-from=exclude -N -u -r nsapolicy/Makefile policy-1.19.12/Makefile
>>--- nsapolicy/Makefile	2004-10-25 14:01:13.000000000 -0400
>>+++ policy-1.19.12/Makefile	2004-12-10 10:54:18.524901686 -0500
>>+$(USERPATH)/system.users: $(ALL_TUNABLES) $(USER_FILES) policy.conf
>>+	@mkdir -p $(USERPATH)
>>+	@echo "# " > tmp/system.users
>>+	@echo "# Do not edit this file. " >> tmp/system.users
>>+	@echo "# This file is replaced on reinstalls of this policy." >> tmp/system.users
>>+	@echo "# Please edit users.custom to make local changes." >> tmp/system.users
>>+	@echo "#" >> tmp/system.users
>>+	m4 $(ALL_TUNABLES) tmp/program_used_flags.te $(USER_FILES) | grep -h -v "^#" | grep [a-zA-Z] >> tmp/system.users
>>+	install -m 644 tmp/system.users $@
>>    
>>
>
>The comment says "users.custom", but you've named it "local.users".
>  
>
Fixed

>I'm also unclear on the purpose of the grep's - just to make it more
>readable?  
>
Yes, but more importantly to get rid of misleading comments.  I removed 
the last grep since that could eliminate some info,  So now it is a
hard to read file, but at least it does not have bad comments.

>If you just want the user statement, you could just grep for
>lines beginning with user unless you are worried about multi-line user
>statements in the base policy (which is allowed by checkpolicy, since it
>uses a semicolon terminator).
>  
>
Yes so I will just remove lines that begin with #.

Dan

[-- Attachment #2: policy-users.patch --]
[-- Type: text/x-patch, Size: 3347 bytes --]

diff --exclude-from=exclude -N -u -r nsapolicy/local.users policy-1.19.12/local.users
--- nsapolicy/local.users	1969-12-31 19:00:00.000000000 -0500
+++ policy-1.19.12/local.users	2004-12-10 12:22:56.485903999 -0500
@@ -0,0 +1,21 @@
+##################################
+#
+# User configuration.
+#
+# This file defines additional users recognized by the system security policy.
+# Only the user identities defined in this file and the users.system file
+# may be used as the user attribute in a security context.
+#
+# Each user has a set of roles that may be entered by processes
+# with the users identity.  The syntax of a user declaration is:
+#
+# 	user username roles role_set [ ranges MLS_range_set ];
+#
+# The MLS range set should only be specified if MLS was enabled
+# for the module and checkpolicy.
+
+# sample for administrative user
+user jadmin roles { staff_r sysadm_r ifdef(`direct_sysadm_daemon', `system_r') };
+
+# sample for regular user
+#user jdoe roles { user_r }; 
diff --exclude-from=exclude -N -u -r nsapolicy/Makefile policy-1.19.12/Makefile
--- nsapolicy/Makefile	2004-10-25 14:01:13.000000000 -0400
+++ policy-1.19.12/Makefile	2004-12-10 12:25:23.282396928 -0500
@@ -26,6 +26,7 @@
 INSTALLDIR = $(DESTDIR)/etc/selinux/strict
 POLICYPATH = $(INSTALLDIR)/policy
 SRCPATH = $(INSTALLDIR)/src
+USERPATH = $(INSTALLDIR)/users
 CONTEXTPATH = $(INSTALLDIR)/contexts
 LOADPATH = $(POLICYPATH)/$(POLICYVER)
 FCPATH = $(CONTEXTPATH)/files/file_contexts
@@ -37,13 +38,13 @@
 ALLTEFILES := attrib.te tmp/program_used_flags.te $(ALL_MACROS) $(ALL_TYPES) $(ALL_DOMAINS) assert.te 
 TE_RBAC_FILES := $(ALLTEFILES) rbac
 ALL_TUNABLES := $(wildcard tunables/*.tun )
-
+USER_FILES := users serviceusers
 POLICYFILES = $(addprefix $(FLASKDIR),security_classes initial_sids access_vectors)
 ifeq ($(MLS),y)
 POLICYFILES += mls
 endif
 POLICYFILES += $(ALL_TUNABLES) $(TE_RBAC_FILES)
-POLICYFILES += users serviceusers
+POLICYFILES += $(USER_FILES)
 POLICYFILES += constraints initial_sid_contexts fs_use genfs_contexts net_contexts
 
 UNUSED_TE_FILES := $(wildcard domains/program/unused/*.te)
@@ -54,9 +55,24 @@
 APPDIR=$(CONTEXTPATH)
 APPFILES = $(addprefix $(APPDIR)/,default_contexts default_type initrc_context failsafe_context userhelper_context removable_context dbus_contexts) $(CONTEXTPATH)/files/media
 
+$(USERPATH)/system.users: $(ALL_TUNABLES) $(USER_FILES) policy.conf
+	@mkdir -p $(USERPATH)
+	@echo "# " > tmp/system.users
+	@echo "# Do not edit this file. " >> tmp/system.users
+	@echo "# This file is replaced on reinstalls of this policy." >> tmp/system.users
+	@echo "# Please edit local.users to make local changes." >> tmp/system.users
+	@echo "#" >> tmp/system.users
+	m4 $(ALL_TUNABLES) tmp/program_used_flags.te $(USER_FILES) | grep -v "^#" >> tmp/system.users
+	install -m 644 tmp/system.users $@
+
+$(USERPATH)/local.users: local.users
+	@mkdir -p $(USERPATH)
+	m4 $(ALL_TUNABLES) tmp/program_used_flags.te $(USERPATH)/local.users | sed 's/^user/#user/g' >> tmp/local.users
+	install -m 644 tmp/local.users $@
+
 ROOTFILES = $(addprefix $(APPDIR)/users/,root)
 
-install: $(APPFILES) $(ROOTFILES) $(LOADPATH) $(FCPATH) 
+install: $(APPFILES) $(ROOTFILES) $(LOADPATH) $(FCPATH) $(USERPATH)/system.users $(USERPATH)/local.users
 	@echo "Validating file_contexts ..."	
 	$(SETFILES) -q -c $(LOADPATH) $(FCPATH)
 

Re: Manipulating user roles without policy-sources installed

[Stephen Smalley]

On Fri, 2004-12-10 at 11:37, Stephen Smalley wrote:
> On Fri, 2004-12-10 at 11:23, Daniel J Walsh wrote:
> > I want to change genpolusers syntax to be
> > 
> > genpolusers inpolicy outpolicy userfile1 [userfile2 ... ]
> 
> Yes, that's easy enough to do, and as no one has used genpolusers to
> date AFAIK, changing the interface is ok with me.

Patch below should do it.

Index: checkpolicy/genpolusers.c
===================================================================
RCS file: /nfshome/pal/CVS/selinux-usr/checkpolicy/genpolusers.c,v
retrieving revision 1.5
diff -u -r1.5 genpolusers.c
--- checkpolicy/genpolusers.c	11 Aug 2004 14:03:19 -0000	1.5
+++ checkpolicy/genpolusers.c	10 Dec 2004 18:31:49 -0000
@@ -1,8 +1,8 @@
 /*
- * genpolusers old-policy new-users new-policy
+ * genpolusers inpolicy outpolicy users1 [users2 ... ]
  *
- * Given an existing binary policy configuration and a new source users 
- * configuration (post-processed), generate a new binary policy 
+ * Given an existing binary policy configuration and a set of source users 
+ * configurations (post-processed), generate a new binary policy 
  * configuration that is identical to the old one except that it has
  * the new user declarations.  User declarations from the old binary
  * policy are replaced if they also exist in the new source users 
@@ -39,7 +39,7 @@
 
 void usage(char *progname)
 {
-	printf("usage:  %s old-policy new-users new-policy\n", progname);
+	printf("usage:  %s inpolicy outpolicy users1 [users2 ...]\n", progname);
 	exit(1);
 }
 
@@ -111,10 +111,10 @@
 	struct policy_file pf;
 	struct stat sb;
 	FILE *outfp;
-	int fd, rc;
+	int fd, rc, i;
 	void *map;
 
-	if (argc != 4) 
+	if (argc < 4) 
 		usage(argv[0]);
 
 	fd = open(argv[1], O_RDONLY);
@@ -148,12 +148,6 @@
 	   for the new policy. */
 	sepol_set_policyvers(policydb.policyvers);
 
-	yyin = fopen(argv[2], "r");
-	if (!yyin) {
-		fprintf(stderr, "%s:  unable to open %s\n", argv[0], 
-			argv[2]);
-		exit(1);
-	}
 	id_queue = queue_create();
 	if (!id_queue) {
 		fprintf(stderr, "%s:  out of memory\n", argv[0]);
@@ -161,21 +155,28 @@
 	}
 	policydbp = &policydb;
 	policydb_errors = 0;
-	if (yyparse() || policydb_errors) {
-		fprintf(stderr, "%s:  error(s) encountered while parsing configuration\n", argv[0]);
-		exit(1);
+
+	for (i = 3; i < argc; i++) {
+		yyin = fopen(argv[i], "r");
+		if (!yyin) {
+			fprintf(stderr, "%s:  unable to open %s\n", argv[0], 
+				argv[i]);
+			exit(1);
+		}
+
+		if (yyparse() || policydb_errors) {
+			fprintf(stderr, "%s:  error(s) encountered while parsing configuration %s\n", argv[0], argv[i]);
+			exit(1);
+		}
 	}
 	queue_destroy(id_queue);
 
-	if (policydb_errors) 
-		exit(1);
-
 	hashtab_map_remove_on_error(policydb.p_users.table, select_user, kill_user, &policydb);
 	hashtab_map(policydb.p_users.table, remap_users, &policydb);
 
-	outfp = fopen(argv[3], "w");
+	outfp = fopen(argv[2], "w");
 	if (!outfp) {
-		perror(argv[3]);
+		perror(argv[2]);
 		exit(1);
 	}
 	pf.type = PF_USE_STDIO;
@@ -183,7 +184,7 @@
 	rc = policydb_write(&policydb, &pf);
 	if (rc) {
 		fprintf(stderr, "%s:  error writing %s\n",
-			argv[0], argv[3]);
+			argv[0], argv[2]);
 		exit(1);
 	}
 	fclose(outfp);

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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: Single home directory type for all roles.

[Russell Coker]

On Thu, 2004-12-09 at 12:20 -0500, Stephen Smalley wrote:
> On Thu, 2004-12-09 at 11:50, Daniel J Walsh wrote:
> > One problem I still have with RBAC though is the labeling of files based 
> > on the role of the user.  IE (staff_home_t versus
> > user_home_t).  I believe this causes many problems, without much benefit.
> 
> The benefit is providing separation among the roles.  If user_t can
> write to staff_home_t, then the only thing preventing a user_t process
> from injecting arbitrary commands into a staff user's .bashrc file or
> otherwise corrupting a staff user's data or reading arbitrary files
> created by the staff user is DAC.    

Yes.  This is how two SE Linux "play machines" have been demonstrated to
be inadequately secured.  One of the two machines was demonstrated to be
insecure by stealth and is believed to be the machine that caused
spender to think that my machine had been cracked (can't be sure as
spender doesn't answer questions).

> > 1.  Causes problems with sharing files between users,   IE a staff user 
> > coping a file to tmp and then the user
> > can't read it, because it has the wrong type. 
> 
> If you want to share files, you just need to define a file type that is
> accessible to both domains and label the shared directory with it.  Then

Or just have them in the same role.

> users from both roles can create and modify content under that shared
> directory without losing protection on their own data.  Note that
> unifying the home directory type doesn't solve #1 for you, because cp
> /home/user/foo /tmp/foo will create /tmp/foo in the default type, e.g.
> staff_tmp_t; cp only preserves contexts when explicitly told to do so. 
> And unifying the temporary types would again open a vulnerability
> between the roles, classical insecure tmp file issues.

However there still are issues because sysadm_t can read symlinks of
type user_tmp_t, so a user can attempt a symlink race condition attack
on the administrator.

Having a tunable to allow user roles to read each other's temporary
files would be much better than any other "solution" to this problem.

> > 2.  Requirement that selinux-policy-strict-sources be installed and a 
> > rebuild of policy in order to change the roles of a user.
> 
> You mean to update the file_contexts?  One could certainly build a tool
> to apply selective modifications to an existing file_contexts
> configuration without requiring the full sources.

I think he's referring to the users file which is compiled into the
policy.  But you've addressed that later in your message.


I think that the real issue here is making a SE Linux system work for
someone who doesn't want SE Linux.  We can make the targeted policy work
for such people, but trying to make the strict policy work for them is
not going to do any good, all it will result in is a less effective
strict policy and such people still won't use it anyway!

Last I heard Lindows had everything running as root.  Some people like
having the minimum amount of security in return for a small amount of
usability.  There's nothing that we can do in strict policy to make such
people happy.

--
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: Single home directory type for all roles.

[Stephen Smalley]

On Thu, 2004-12-09 at 12:47, Russell Coker wrote:
> However there still are issues because sysadm_t can read symlinks of
> type user_tmp_t, so a user can attempt a symlink race condition attack
> on the administrator.

Yes, that should be removed IMHO.  Currently only occurs due to allow
rule on sysadmfile:lnk_file.   

> Having a tunable to allow user roles to read each other's temporary
> files would be much better than any other "solution" to this problem.

No, having an explicit type for the purpose of sharing is preferable, so
that the user has to explicitly indicate what he wants to share, either
by relabeling or by copying into a shared directory that has that type.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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: Single home directory type for all roles.

[Russell Coker]

On Thu, 2004-12-09 at 12:53 -0500, Stephen Smalley wrote:
> On Thu, 2004-12-09 at 12:47, Russell Coker wrote:
> > However there still are issues because sysadm_t can read symlinks of
> > type user_tmp_t, so a user can attempt a symlink race condition attack
> > on the administrator.
> 
> Yes, that should be removed IMHO.  Currently only occurs due to allow
> rule on sysadmfile:lnk_file.   

The problem with such a change is that it interferes with the operation
of "ls -l /tmp" (which is IMHO a fairly important operation for a system
administrator).  I can imagine a situation where one user is trying a
race condition against another user but the administrator doesn't notice
because "ls -l /tmp" doesn't display full information.

Last time I mentioned this I was informed that it is impractically
difficult for the kernel code to differentiate between an application
such as ls calling readlink(2) and the kernel code calling it as part of
a file open operation.

The solution then would be to have a separate domain for the
administrator to run ls which can read all sym-links while other
programs the administrator may run (rm, cp, mv, etc) will be denied
access to read many types of sym-link.  Is this a good idea?

> > Having a tunable to allow user roles to read each other's temporary
> > files would be much better than any other "solution" to this problem.
> 
> No, having an explicit type for the purpose of sharing is preferable, so
> that the user has to explicitly indicate what he wants to share, either
> by relabeling or by copying into a shared directory that has that type.

Relabeling probably isn't an option for the scenario under discussion.
A shared directory will work.

I have been considering such issues for a while and come to the
conclusion that having ALL files that a user creates under /home/$USER
is a limitation on what we can do in this regard.  If we
had /home/share/$USER for sharing files then we could deny
relabelto/from user_share_t and of course deny all users the ability to
write to /home/share so the users would then be unable to mess this up.
If we have shared files in /home/$USER/Public as Colin suggests then
users will do "mv Public Public.old ; mkdir Public" and then whinge when
things stop working (this is the big problem with all labeling under the
home directory but it becomes worse when sharing files with other
users).

Can we break the tradition of having only /home/$USER in this regard?
There are several other categories of files that are relevant to
security that could benefit from similar treatment if we go down that
path.

--
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: Single home directory type for all roles.

[Stephen Smalley]

On Thu, 2004-12-09 at 13:12, Russell Coker wrote:
> Last time I mentioned this I was informed that it is impractically
> difficult for the kernel code to differentiate between an application
> such as ls calling readlink(2) and the kernel code calling it as part of
> a file open operation.

Not sure who said that, but there are two separate LSM hooks on those
code paths, security_inode_readlink() vs. security_inode_follow_link(). 
They just happen to perform the same check in SELinux presently. 
Whether or not it is legitimate to separate them in the access control
model is another question; if you don't want the admin following the
link, why do you want an application he runs to rely on the information
returned by readlink?
In any event, we could apply different permission checks - it just
requires defining a new permission in the lnk_file class and modifying
the selinux_inode_follow_link() hook function to use it.  Trivial patch,
anyone could do it (but then you would need to identify all the places
in the policy where you would need to add it).

> The solution then would be to have a separate domain for the
> administrator to run ls which can read all sym-links while other
> programs the administrator may run (rm, cp, mv, etc) will be denied
> access to read many types of sym-link.  Is this a good idea?

Seems painful.

> Can we break the tradition of having only /home/$USER in this regard?
> There are several other categories of files that are relevant to
> security that could benefit from similar treatment if we go down that
> path.

For MLS, we'll need multiple home directories per user anyway, although
they could all be rooted under /home/$USER and polyinstantiated
directories could be used to transparently redirect to the right member
subdirectory.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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: Single home directory type for all roles.

[Stephen Smalley]

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

On Thu, 2004-12-09 at 13:18, Stephen Smalley wrote:
> Not sure who said that, but there are two separate LSM hooks on those
> code paths, security_inode_readlink() vs. security_inode_follow_link(). 
> They just happen to perform the same check in SELinux presently. 
> Whether or not it is legitimate to separate them in the access control
> model is another question; if you don't want the admin following the
> link, why do you want an application he runs to rely on the information
> returned by readlink?
> In any event, we could apply different permission checks - it just
> requires defining a new permission in the lnk_file class and modifying
> the selinux_inode_follow_link() hook function to use it.  Trivial patch,
> anyone could do it (but then you would need to identify all the places
> in the policy where you would need to add it).

(un-tested) Patches below should do it as far as defining the new
permission for the policy and updating the kernel.  But you would have
to audit the policy to determine when to give this permission.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency

[-- Attachment #2: sel-follow.patch --]
[-- Type: text/x-patch, Size: 2407 bytes --]

Index: linux-2.6/security/selinux/hooks.c
===================================================================
RCS file: /nfshome/pal/CVS/linux-2.6/security/selinux/hooks.c,v
retrieving revision 1.141
diff -u -p -r1.141 hooks.c
--- linux-2.6/security/selinux/hooks.c	6 Dec 2004 19:57:39 -0000	1.141
+++ linux-2.6/security/selinux/hooks.c	9 Dec 2004 18:45:29 -0000
@@ -2149,7 +2149,7 @@ static int selinux_inode_follow_link(str
 	rc = secondary_ops->inode_follow_link(dentry,nameidata);
 	if (rc)
 		return rc;
-	return dentry_has_perm(current, NULL, dentry, FILE__READ);
+	return dentry_has_perm(current, NULL, dentry, LNK_FILE__FOLLOW);
 }
 
 static int selinux_inode_permission(struct inode *inode, int mask,
Index: linux-2.6/security/selinux/include/av_perm_to_string.h
===================================================================
RCS file: /nfshome/pal/CVS/linux-2.6/security/selinux/include/av_perm_to_string.h,v
retrieving revision 1.19
diff -u -p -r1.19 av_perm_to_string.h
--- linux-2.6/security/selinux/include/av_perm_to_string.h	1 Dec 2004 16:47:00 -0000	1.19
+++ linux-2.6/security/selinux/include/av_perm_to_string.h	9 Dec 2004 18:44:41 -0000
@@ -17,6 +17,7 @@
    S_(SECCLASS_FILE, FILE__EXECUTE_NO_TRANS, "execute_no_trans")
    S_(SECCLASS_FILE, FILE__ENTRYPOINT, "entrypoint")
    S_(SECCLASS_FILE, FILE__EXECMOD, "execmod")
+   S_(SECCLASS_LNK_FILE, LNK_FILE__FOLLOW, "follow")
    S_(SECCLASS_FD, FD__USE, "use")
    S_(SECCLASS_TCP_SOCKET, TCP_SOCKET__CONNECTTO, "connectto")
    S_(SECCLASS_TCP_SOCKET, TCP_SOCKET__NEWCONN, "newconn")
Index: linux-2.6/security/selinux/include/av_permissions.h
===================================================================
RCS file: /nfshome/pal/CVS/linux-2.6/security/selinux/include/av_permissions.h,v
retrieving revision 1.18
diff -u -p -r1.18 av_permissions.h
--- linux-2.6/security/selinux/include/av_permissions.h	1 Dec 2004 16:47:00 -0000	1.18
+++ linux-2.6/security/selinux/include/av_permissions.h	9 Dec 2004 18:44:41 -0000
@@ -125,6 +125,8 @@
 #define LNK_FILE__QUOTAON                         0x00008000UL
 #define LNK_FILE__MOUNTON                         0x00010000UL
 
+#define LNK_FILE__FOLLOW                          0x00020000UL
+
 #define CHR_FILE__IOCTL                           0x00000001UL
 #define CHR_FILE__READ                            0x00000002UL
 #define CHR_FILE__WRITE                           0x00000004UL

[-- Attachment #3: policy-follow.patch --]
[-- Type: text/x-patch, Size: 449 bytes --]

Index: policy/flask/access_vectors
===================================================================
RCS file: /nfshome/pal/CVS/selinux-usr/policy/flask/access_vectors,v
retrieving revision 1.17
diff -u -r1.17 access_vectors
--- policy/flask/access_vectors	1 Dec 2004 16:45:37 -0000	1.17
+++ policy/flask/access_vectors	9 Dec 2004 18:44:17 -0000
@@ -123,6 +123,9 @@
 
 class lnk_file
 inherits file
+{
+	follow
+}
 
 class chr_file
 inherits file

Re: Single home directory type for all roles.

[Russell Coker]

On Thu, 2004-12-09 at 13:18 -0500, Stephen Smalley wrote:
> On Thu, 2004-12-09 at 13:12, Russell Coker wrote:
> > Last time I mentioned this I was informed that it is impractically
> > difficult for the kernel code to differentiate between an application
> > such as ls calling readlink(2) and the kernel code calling it as part of
> > a file open operation.
> 
> Not sure who said that, but there are two separate LSM hooks on those
> code paths, security_inode_readlink() vs. security_inode_follow_link(). 
> They just happen to perform the same check in SELinux presently. 
> Whether or not it is legitimate to separate them in the access control
> model is another question; if you don't want the admin following the
> link, why do you want an application he runs to rely on the information
> returned by readlink?

You are correct that there are cases of applications calling readlink(2)
for the purpose of canonicalising a path which would be vulnerable to
race conditions after such a change.  However writing an application
that does such things in a manner such that it is not vulnerable to any
race conditions is really difficult and it seems likely that most such
applications can be attacked in other ways (which will be more difficult
to implement).

But it would catch the majority of attacks and make it more difficult
for an attack to leave a file system.  Some of the attacks might work if
the attacker found a symlink in a directory that they could rename - but
the attacker would need to discover the contents of the sym-link which
should be impossible.

> In any event, we could apply different permission checks - it just
> requires defining a new permission in the lnk_file class and modifying
> the selinux_inode_follow_link() hook function to use it.  Trivial patch,
> anyone could do it (but then you would need to identify all the places
> in the policy where you would need to add it).

Fixing the policy should be easy enough.

> > The solution then would be to have a separate domain for the
> > administrator to run ls which can read all sym-links while other
> > programs the administrator may run (rm, cp, mv, etc) will be denied
> > access to read many types of sym-link.  Is this a good idea?
> 
> Seems painful.

Yes.  But it would give a practical use for ls_exec_t.  ;)

> > Can we break the tradition of having only /home/$USER in this regard?
> > There are several other categories of files that are relevant to
> > security that could benefit from similar treatment if we go down that
> > path.
> 
> For MLS, we'll need multiple home directories per user anyway, although
> they could all be rooted under /home/$USER and polyinstantiated
> directories could be used to transparently redirect to the right member
> subdirectory.

That's an entirely different issue.

If we have both strict policy in it's current form and MLS then we would
have two ways of categorising the files (role and level).  I think that
probably the best thing to do for MLS is to polyinstantiate /home per
MLS level.  Anything else seems to get too confusing too fast.

I hope that we don't plan on supporting polyinstantiation for MLS over
NFS.

--
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: Single home directory type for all roles.

[Casey Schaufler]

--- Russell Coker <rcoker@redhat.com> wrote:

> The problem with such a change is that it interferes
> with the operation
> of "ls -l /tmp" (which is IMHO a fairly important
> operation for a system
> administrator).  I can imagine a situation where one
> user is trying a
> race condition against another user but the
> administrator doesn't notice
> because "ls -l /tmp" doesn't display full
> information.

I apologize in advance for missing any discussions
regrading /tmp over the past year or so. ...

In the U2X world the issue of /tmp was solved
using a variety of implementations of "moldy"
directories. An attribute (in some cases a seperate
file type) was used that identified certain
directories, /tmp in particular, as moldy. The lookup
processing was modified such that when a moldy
directory is encountered an additional path component
based on the process's label is inserted, as:

    /tmp becomes /tmp/<labelname>

and then resolution continues. A process with a
"moldy" attribute of it's own is does not have the
additional component added, addressing the admin
issue. Some systems created the subdirectories on
reference, others required it be done
administratively. There are similar tricks that
can be played with variable symlinks.


=====
Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - 250MB free storage. Do more. Manage less. 
http://info.mail.yahoo.com/mail_250

--
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: Single home directory type for all roles.

[Russell Coker]

On Thu, 2004-12-09 at 12:03 -0800, Casey Schaufler wrote:
> In the U2X world the issue of /tmp was solved

What is U2X?

>     /tmp becomes /tmp/<labelname>

There is talk of adding poly-instantiated directories to SE Linux which
will give similar facilities.  I'm not aware of any code release yet
though.

> and then resolution continues. A process with a
> "moldy" attribute of it's own is does not have the
> additional component added, addressing the admin
> issue. Some systems created the subdirectories on
> reference, others required it be done
> administratively. There are similar tricks that
> can be played with variable symlinks.

Yes, that solves many of the issues related to users attacking other
users via sym-links.  But it doesn't entirely solve the issues related
to attacking the administrator processes.  It's a fairly standard
practice for the administrator to inspect the files of a user and modify
them on occasion.  This means that the admin has to work inside the
mouldy directory.

--
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: Single home directory type for all roles.

[Valdis.Kletnieks]

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

On Fri, 10 Dec 2004 23:20:26 +1100, Russell Coker said:
> On Thu, 2004-12-09 at 12:03 -0800, Casey Schaufler wrote:
> > In the U2X world the issue of /tmp was solved
> 
> What is U2X?

For a moment, I thought it was an i18n-style contraction of unix, except
that the /tmp issue isn't by any means solved in "the unix world".  Or if
it *is* solved there, it's not actually made it into AIX, Irix, Tru64, or Solaris.
So I have no idea what Casey's talking about.  There might be some hooks in
some Unixoids to help assist, but I don't know of anyplace where it's a fully
integrated solution...

I'll note that IBM played with "hidden directories" in the TCF component
of their AIX/370 product - and it didn't make the jump into AIX 3 and later.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Single home directory type for all roles.

[Casey Schaufler]

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


--- Valdis.Kletnieks@vt.edu wrote:

> On Fri, 10 Dec 2004 23:20:26 +1100, Russell Coker
> said:
> > On Thu, 2004-12-09 at 12:03 -0800, Casey Schaufler
> wrote:
> > > In the U2X world the issue of /tmp was solved
> > 
> > What is U2X?
> 
> For a moment, I thought it was an i18n-style
> contraction of unix,

Yes, that is what it is. Some of us remember a time
when AT&T was very protective of the trademark and
changed how they wanted it used with alarming
frequency. Mostly it's joke.

> except
> that the /tmp issue isn't by any means solved in
> "the unix world".

Every major unix vendor offers or has offered a
B1/CMW/LSPP system. Every one of these has a moldy
directory solution of some form or another.
The big problem is not lack of solution, it's that
the problem is solved differently by each vendor.

> Or if
> it *is* solved there, it's not actually made it into
> AIX, Irix, Tru64, or Solaris.

You have to go to the costs-extra multilevel secure
versions.

> So I have no idea what Casey's talking about.  There
> might be some hooks in
> some Unixoids to help assist, but I don't know of
> anyplace where it's a fully
> integrated solution...

Trusted Solaris, Trusted Irix, SystemV/MLS, UNICOS
all include it.

But, enough of that. You probably want something
other than claims about how we did it back in our
day. Fair enough. A while back SGI put a bunch of
the Trusted Irix code out for general use under
the OB1 project. I've attached the moldy directory
processing code for your general amusement.


=====
Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com 

[-- Attachment #2: mac.c --]
[-- Type: text/plain, Size: 14697 bytes --]

/*
 * 
 * Copyright 1990 Silicon Graphics, Inc. 
 * All rights reserved.
 *     
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 *
 */
#ident	"$SGIRevision: 1.47 $"

#include "sys/types.h"
#include "sys/systm.h"
#include "sys/debug.h"
#include "sys/cmn_err.h"
#include "ksys/cred.h"
#include "sys/kabi.h"
#include "sys/proc.h"
#include "sys/vfs.h"
#include "sys/param.h"
#include "sys/errno.h"
#include "sys/vfs.h"
#include "sys/vnode.h"
#include "sys/fstyp.h"
#include "ksys/vfile.h"
#include "ksys/fdt.h"
#include "sys/uio.h"
#include "sys/pathname.h"
#include "sys/mac_label.h"
#include "sys/eag.h"
#include "sys/capability.h"
#include "sys/sat.h"
#include "sys/attributes.h"
#include "os/proc/pproc_private.h"	/* XXX bogus */
#include "ksys/fdt.h"

extern mac_label *mac_high_low_lp;
extern mac_label *mac_low_high_lp;

/*
 * Copy in a mac label.
 */
int
mac_copyin_label(mac_label *src, mac_label **result)
{
	mac_label ml;

	if (copyin((void *) src, (void *) &ml, sizeof(ml))) {
		*result = NULL;
		return(EFAULT);
	}

	*result = mac_add_label(&ml);
	return (*result == NULL ? EINVAL : 0);
}

/*
 * Copy the cred structure for the write. Set the label.
 */
static void
mac_setumac(mac_label *lp)
{
	proc_t *p = curprocp;
	struct cred *cr;

	(void) pcred_lock(p);
	cr = crcopy(p);
	cr->cr_mac = lp;
	pcred_push(p);
}

/* 
 * get and set the process label.
 */
int
mac_getplabel(mac_label *lp)
{
	cred_t *cr = get_current_cred();

	if (lp == NULL)
		return (EFAULT);

	if (copyout((caddr_t)cr->cr_mac, (caddr_t)lp, mac_size(cr->cr_mac)))
		return (EFAULT);

	return (0);
}

int
mac_setplabel(mac_label *lp, int userspace)
{
	int i;
	cred_t *cr = get_current_cred();

	if (userspace) {
		mac_label *nlp;

		if (i = mac_copyin_label(lp, &nlp))
			return (i);
		lp = nlp;
	}
	else {
		if ((lp = mac_add_label(lp)) == NULL)
			return EINVAL;
	}
	/*
	 * Audit the old label
	 */
	_SAT_SAVE_ATTR(SAT_MAC_LABEL_TOKEN, curuthread);

	/*
	 * If changing the label to the same value it's a noop.
	 */
	if (lp == cr->cr_mac) {
		_SAT_SETPLABEL(lp, 0);
		return (0);
	}
	/*
	 * Processes are never allowed to set "equal" sensitivity.
	 */
	if (lp->ml_msen_type == MSEN_EQUAL_LABEL) {
		_SAT_SETPLABEL(lp, EINVAL);
		return (EINVAL);
	}
	/*
	 * Changing the moldy state of the process requires CAP_MAC_MLD
	 * if capabilities are installed.
	 * NOTICE! CAP_MAC_RELABEL_SUBJ is NOT sufficient to change the
	 * moldyness of a process.
	 */
	if (mac_is_moldy(lp) != mac_is_moldy(cr->cr_mac) &&
	    !_CAP_CRABLE(cr, CAP_MAC_MLD)) {
		_SAT_SETPLABEL(lp, EPERM);
		return (EPERM);
	}
	
	/*
	 * Any other change requires CAP_MAC_RELABEL_SUBJ.
	 * Check for "equal" integrity.
	 */
	if (lp->ml_mint_type == MINT_EQUAL_LABEL || !mac_equ(lp, cr->cr_mac)) {
		if (!_CAP_CRABLE(cr, CAP_MAC_RELABEL_SUBJ)) {
			_SAT_SETPLABEL(lp, EPERM);
			return (EPERM);
		}
	}

	/*
	 * Transformation is acceptable.
	 */
	mac_setumac(lp);
	_SAT_SETPLABEL(lp, 0);
	return (0);
}

int
mac_vsetlabel(vnode_t *vp, mac_label *mlp)
{
	int error;

	VOP_ATTR_SET(vp, SGI_MAC_FILE, (char *)mlp, mac_size(mlp),
		     ATTR_ROOT, sys_cred, error);
	
	return error;
}

mac_label *
mac_vtolp(vnode_t *vp)
{
	int error;
	mac_label ml, *mlp;
	int mls = sizeof(ml);

	ASSERT(vp);

	VOP_ATTR_GET(vp, SGI_MAC_FILE, (char *)&ml, &mls, ATTR_ROOT,
		     sys_cred, error);

	if (error) {
#ifdef DEBUG
		cmn_err(CE_NOTE, "mac_vtolp: %s(%d) error=%d v_type=%d",
			__FILE__, __LINE__, error, vp ? vp->v_type : -1);
#endif
		return mac_high_low_lp;
	}

	if ((mlp = mac_add_label(&ml)) == NULL) {
#ifdef DEBUG
		cmn_err(CE_WARN, "mac_vtolp: %s(%d) mac_invalid(%x)",
			__FILE__, __LINE__, &ml);
#endif
		return mac_high_low_lp;
	}

	return mlp;
}

/* 
 * get and set the file label.
 */
int
mac_get(char *fname, int fdes, mac_label *lp)
{
	vnode_t *vp;
	int error = 0;
	mac_label *mlp;
	vfile_t *fp;

	_SAT_PN_BOOK(SAT_FILE_ATTR_READ, curuthread);

	if (fdes != -1 && fname != NULL)
		return (EINVAL);
	if (fdes == -1 && fname == NULL)
		return (EINVAL);

	if (fname) {
		if (error = lookupname(fname, UIO_USERSPACE, NO_FOLLOW,
				       NULLVPP, &vp, NULL))
			return (error);
	}
	else {
		if (error = getf(fdes, &fp))
			return (error);
		if (!VF_IS_VNODE(fp))
			return (EINVAL);
		vp = VF_TO_VNODE(fp);
		VN_HOLD(vp);
	}

	if ((mlp = mac_vtolp(vp)) == NULL) {
		/*
		 * XXX:casey
		 * This should never happen - the underlying file system
		 * dependent code should provide something.
		 */
		VN_RELE(vp);
		_SAT_ACCESS(SAT_FILE_ATTR_READ, error);
		return (EACCES);
	}
	if (mac_access(mlp, get_current_cred(), VREAD)) {
		VN_RELE(vp);
		_SAT_ACCESS(SAT_FILE_ATTR_READ, error);
		return (EACCES);
	}

	if (copyout((caddr_t)mlp, (caddr_t)lp, mac_size(mlp)))
		error = EFAULT;

	VN_RELE(vp);

	_SAT_ACCESS(SAT_FILE_ATTR_READ, error);
	return (error);
}

int
mac_set(char *fname, int fdes, mac_label *lp)
{
	vnode_t *vp;
	int error;
	mac_label *new_label;
	vfile_t *fp;
	cred_t *cr = get_current_cred();

	if (error = mac_copyin_label(lp, &new_label))
		return (error);

	if (new_label->ml_msen_type == MSEN_EQUAL_LABEL ||
	    new_label->ml_mint_type == MINT_EQUAL_LABEL) {
		if (!_CAP_ABLE(CAP_MAC_RELABEL_OPEN))
			return (EPERM);
	}

	if (!mac_equ(new_label, cr->cr_mac)) {
		if (mac_dom(new_label, cr->cr_mac)) {
			if (!_CAP_ABLE(CAP_MAC_UPGRADE))
				return (EPERM);
		}
		else if (!_CAP_ABLE(CAP_MAC_DOWNGRADE))
			return (EPERM);
	}

	if (fdes != -1 && fname != NULL)
		return (EINVAL);
	if (fdes == -1 && fname == NULL)
		return (EINVAL);

	_SAT_PN_BOOK(SAT_FILE_ATTR_WRITE, curuthread);

	if (fname) {
		if (error = lookupname(fname, UIO_USERSPACE, NO_FOLLOW,
				       NULLVPP, &vp, NULL))
			return (error);
	}
	else {
		if (error = getf(fdes, &fp))
			return (error);
		if (!VF_IS_VNODE(fp))
			return (EINVAL);
		vp = VF_TO_VNODE(fp);
		VN_HOLD(vp);
	}

	/*
	 * Verify that the caller has CAP_MAC_RELABEL_OPEN if required.
	 * Do a vanilla MAC write access check if that passes.
	 */
	if (vp->v_count > 1 && !_CAP_ABLE(CAP_MAC_RELABEL_OPEN))
		error = EBUSY;
	else
		error = mac_vaccess(vp, cr, VWRITE);

	/*
	 * Verify ownership
	 */
	if (!error) {
		vattr_t va;

		va.va_mask = AT_UID;
		VOP_GETATTR(vp, &va, 0, sys_cred, error);
		if (!error && va.va_uid != cr->cr_uid &&
		    !_CAP_CRABLE(cr, CAP_FOWNER))
			error = EACCES;
	}

	if (!error) {
		/*
		 * Only directories may be made MOLDY.
		 */
		if (mac_is_moldy(new_label) && vp->v_type != VDIR)
			error = ENOTDIR;
		/*
		 * Better not try to update a read-only file system.
		 */
		else if (vp->v_vfsp->vfs_flag & VFS_RDONLY)
			error = EROFS;
		/*
		 * Apply the change.
		 */
		else 
			error = mac_vsetlabel(vp, new_label);
	}


	VN_RELE(vp);
	_SAT_SETLABEL(new_label, error);
	return (error);
}

/*
 * Simply print a message to the effect that MAC is enabled.
 */
void
mac_confignote(void)
{
	cmn_err(CE_CONT, "Mandatory Access Control Enabled.\n");
}

/*
 * Derive the appropriate moldy subdirectory name for a label
 * on a file system.
 */
static void
mac_moldy_pathname(mac_label *lp, pathname_t *moldname)
{
	int i;
	int name_size = 3;		/* msen type, '-', and mint type */
	char *name = moldname->pn_path;
	char *letters = "bcdfhklmnrstvwxz"; /* All non-descending consonants */
	unsigned short *ep;

	*name++ = lp->ml_msen_type;
	if (lp->ml_level != 0) {
		*name++ = letters[(lp->ml_level >> 4) & 0x0f];
		*name++ = letters[lp->ml_level & 0x0f];
		name_size += 2;
	}
	*name++ = '-';
	*name++ = lp->ml_mint_type;
	if (lp->ml_grade != 0) {
		*name++ = letters[(lp->ml_grade >> 4) & 0x0f];
		*name++ = letters[lp->ml_grade & 0x0f];
		name_size += 2;
	}

	for (i = 0, ep = &lp->ml_list[0]; i < lp->ml_catcount; i++, ep++) {
		*name++ = '+';
		*name++ = letters[(*ep >> 4) & 0x0f];
		*name++ = letters[*ep & 0x0f];
		name_size += 3;
	}
	for (i = 0; i < lp->ml_divcount; i++, ep++) {
		*name++ = '-';
		*name++ = letters[(*ep >> 4) & 0x0f];
		*name++ = letters[*ep & 0x0f];
		name_size += 3;
	}

	*name = '\0';
	moldname->pn_pathlen = name_size;
	return;
}

/*
 * Moldy directory processing.
 * If passed in a moldy directory's vnode and the process isn't moldy
 * attempt to create a subdirectory at the user's label.
 * If it fails with anything other than EEXISTS, drop out.
 * Prepend the subdirectory's name to the caller's path and
 * return back to lookuppn.
 *
 * Sure, it sounds easy, but watch the error handling and credential
 * flipping.
 */
int
mac_moldy_path(vnode_t *vp, char *ct, pathname_t *pnp, cred_t *cred)
{
	mac_label *mlp;
	pathname_t moldname;
	vnode_t *nvp;
	vattr_t va;
	int error;

	/*
	 * Don't redirect on anything other than directories.
	 */
	if (vp->v_type != VDIR)
		return 0;
	/*
	 * Don't redirect moldy processes.
	 * This should probably be done before the v_type check, but
	 * that's a cheaper operation and I'd like to see the messages
	 * for debug purposes.
	 */
	if (mac_is_moldy(cred->cr_mac))
		return 0;

	/*
	 * Don't redirect on non-moldy directories
	 */
	if ((mlp = mac_vtolp(vp)) == NULL) {
#ifdef DEBUG
		cmn_err(CE_WARN, "mac_moldy_path: %s(%d)\n", __FILE__,__LINE__);
#endif
		return 0;
	}

	if (!mac_is_moldy(mlp))
		return 0;
	/*
	 * Get the attributes of the directory.
	 * Get them all in case we have to create a
	 * sub-directory with the same attributes.
	 * Use sys_cred to get an msenhigh/mintequal label and a
	 * superuser uid.
	 */
	va.va_mask = AT_ALL;
	VOP_GETATTR(vp, &va, 0, sys_cred, error);
	if (error) {
#ifdef	DEBUG
		cmn_err(CE_WARN, "mac_moldy_path: failed to get attrs\n");
#endif	/* DEBUG */
		return error;
	}

	pn_alloc(&moldname);
	/*
	 * If we got to a moldy directory via ".." keep going backwords.
	 */
	if (ct[0] == '.' && ct[1] == '.' && ct[2] == '\0') {
		moldname.pn_path[0] = '.';
		moldname.pn_path[1] = '.';
		moldname.pn_path[2] = '\0';
		moldname.pn_pathlen = 2;
	}
	/*
	 * Otherwise all conditions are meet.
	 * This is a moldy directory and redirection should be done.
	 * Get the name to redirect to.
	 */
	else {
		mac_moldy_pathname(cred->cr_mac, &moldname);
		/*
		 * Create the sub-directory with the same attributes.
		 * Use sys_cred to get an msenhigh/mintequal label and a
		 * superuser uid.
		 *
		 * Don't let a failure put you off. It usually means that the
		 * sub-directory already exists or you're on a read only
		 * file system, or something else which is OKay.
		 */
		VOP_MKDIR(vp, moldname.pn_path, &va, &nvp, sys_cred, error);
		/*
		 * If the sub-directory isn't new don't set its label!
		 */
		if (error == 0) {
			/*
			 * Set attributes of the newly created sub-directory.
			 */
			va.va_mask = AT_MODE | AT_UID | AT_GID;
			VOP_SETATTR(nvp, &va, 0, sys_cred, error);
			if (error) {
#ifdef	DEBUG
				cmn_err(CE_WARN,
				    "failed to set owner moldy subdir (%d)\n",
				    error);
#endif	/* DEBUG */
			}
			if (error = mac_vsetlabel(nvp, cred->cr_mac)) {
#ifdef	DEBUG
				cmn_err(CE_WARN,
				    "failed to relabel moldy subdir (%d)\n",
				    error);
#endif	/* DEBUG */
			}
			VN_RELE(nvp);
		}
	}

	/*
	 * Prepend the moldy sub-directory name to the look-up path.
	 * NOTE: ignore an error return from VOP_MKDIR or VOP_SETATTR.
	 */
	error = pn_insert(pnp, &moldname);
	ASSERT(error == 0);

	pn_free(&moldname);
	/*
	 * Return an indication that the path was inserted.
	 */
	return error ? error : -1;
}

/*
 *  Set the mac_enabled flag which is used to turn on MAC
 *  functionality through out the kernel.  Also, overide the
 *  the super user policy set in cap_init().  This policy flag
 *  should really be a tunable parameter, but until that is
 *  implemented, this is a convenient place to ensure that the
 *  policy is changed when Trix is installed.  Note:  mac_init()
 *  is called after cap_init() in main().
 */

void
mac_init()
{
	mac_enabled = 1;
	cap_enabled = CAP_SYS_NO_SUPERUSER;

}

int
mac_revoke(char *fname)
{
	vnode_t *vp;
	int error;

	if (!_CAP_ABLE(CAP_DEVICE_MGT))
		return (EPERM);

	if (error = lookupname(fname, UIO_USERSPACE, NO_FOLLOW, NULLVPP, &vp,
			       NULL))
		return (error);

	if (!(vp->v_flag & VSHARE)) {
		VN_RELE(vp);
#ifdef DEBUG
		cmn_err(CE_WARN,"mac_revoke: %s on non-VSHARE",
			get_current_name());
#endif
		return (EINVAL);
	}
	if (vp->v_type != VCHR) {
		VN_RELE(vp);
#ifdef DEBUG
		cmn_err(CE_WARN,"mac_revoke: %s on non-VCHR",
			get_current_name());
#endif
		return (EINVAL);
	}
	if (vp->v_count < 1) {
		VN_RELE(vp);
#ifdef DEBUG
		cmn_err(CE_WARN,"mac_revoke: %s on <1 count",
			get_current_name());
#endif
		return (EINVAL);
	}

	/*
	 * Do a vanilla MAC write access check.
	 */
	if (!(error = mac_vaccess(vp, get_current_cred(), VWRITE)))
		vn_kill(vp);

	VN_RELE(vp);

	return (error);
}

int
mac_vaccess(struct vnode *vp, struct cred *cr, mode_t mode)
{
	mac_label *mlp = mac_vtolp(vp);

	if (mlp)
		return mac_access(mlp, cr, mode);

#ifdef DEBUG
	cmn_err(CE_WARN,"mac_vaccess: %s(%d)", __FILE__, __LINE__);
#endif
	return 0;
}

void
mac_mountroot(struct vfs *vfsp)
{
	vfsp->vfs_mac = kern_malloc(sizeof(mac_vfs_t));
	vfsp->vfs_mac->mv_ipmac = mac_low_high_lp;
	vfsp->vfs_mac->mv_default = mac_low_high_lp;
}

void
mac_mount(struct vfs *vfsp, char *attrs)
{
	mac_label ml;

	if (!attrs)
		return;

	if (vfsp->vfs_mac == NULL) {
		vfsp->vfs_mac = kern_malloc(sizeof(mac_vfs_t));
		ASSERT(vfsp->vfs_mac);
		vfsp->vfs_mac->mv_default = NULL;
		vfsp->vfs_mac->mv_ipmac = NULL;
	}

	if (eag_parseattr(MAC_MOUNT_DEFAULT, attrs, &ml))
		vfsp->vfs_mac->mv_default = mac_add_label(&ml);

	if (eag_parseattr(MAC_MOUNT_IP, attrs, &ml))
		vfsp->vfs_mac->mv_ipmac = mac_add_label(&ml);
}

/*
 * Set the initial MAC value. Used after the creation of a symlink
 * because VOP_SYMLINK doesn't have the decency to return a vnode.
 */
int
mac_initial_path(char *fname)
{
	cred_t *cr = get_current_cred();
	mac_label *mlp;
	mac_label *lp = cr->cr_mac;
	vnode_t *vp;
	int error;

	if (error = lookupname(fname, UIO_USERSPACE, NO_FOLLOW, NULLVPP, &vp,
			       NULL))
		return (error);

	if (mac_is_moldy(lp)) {
		lp = mac_add_label(mlp = mac_demld(lp));
		kern_free(mlp);
	}

	error = mac_vsetlabel(vp, lp);

	VN_RELE(vp);
	return (error);
}

Re: Single home directory type for all roles.

[Valdis.Kletnieks]

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

On Fri, 10 Dec 2004 08:19:39 PST, Casey Schaufler said:

> > Or if
> > it *is* solved there, it's not actually made it into
> > AIX, Irix, Tru64, or Solaris.
> 
> You have to go to the costs-extra multilevel secure
> versions.

Right.  And that was my point - that although every vendor has managed to hack
something up, it hasn't ever escaped and gotten any significant mindshare. You
may as well say that somebody's already solved this for Linux, because there
exists some out-of-tree patch that handles it.  Because that's what all those
basically were - out-of-mainline-tree add-ons. It hasn't been solved for "the
Unix world", it's been solved for some tiny subset that were forced to install
"an MLS component" for whatever reason, and had to deal with all the borkedness
of the bolt-on because there wasn't enough market share to make it Really Work
Right (go ahead - admit it.  Trusted Irix almost certainly had plenty of warts
on it that never got fixed because Trusted Irix had only a miniscule market share,
when similar-sized warts in the regular Irix would get fixed...)

And "in the base level" is an important thing - I've seen *plenty* of sites
that don't want to have to install (or pay for) a full MLS implementation when
all they want is some variant of "We need to redirect each user's view of /tmp
to $USER/tmp just so they quit stepping on each other's toes accidentally".
Everybody who's ever worked the help desk at a uni and had to answer "How come
I can't save test1.c?" with "because some other user already saved test1.c in
/tmp" knows exactly what I mean...

(Admittedly, it was even worse in the days before 'chmod +t /tmp', when one
user doing a 'rm *' could totally adger the work of everybody on the system..)

> > So I have no idea what Casey's talking about.  There
> > might be some hooks in
> > some Unixoids to help assist, but I don't know of
> > anyplace where it's a fully
> > integrated solution...
> 
> Trusted Solaris, Trusted Irix, SystemV/MLS, UNICOS
> all include it.

After-the-fact bolt-ons, all of them. ;)

For better or worse, at least the AIX/370 "hidden directories" stuff was mostly
integrated into the base level code, and documented, and integrated into the
sysadmin and user userspace tools - /bin/sh had code to set the search path for
them, and so on.  And even there, IBM had basically grafted Locus's "Transparent
Computing Facility" code onto an otherwise mostly-stock SYSV kernel, and there
were quite a few rough edges to deal with (all the *little* stuff, like getting
the software installer tool to Do The Right Thing - it had all the same sort of
corner-case issues that Fedora is now fighting with 'rpm' to make sure that
files end up labelled correctly).

Why am I making a point about this?  Because we're presumably working on
something that will be in the *mainline* kernel, and have support in the
default .ISO images shipped by vendors - and I don't know of any Unix vendor
who's shipped this stuff in their *mainline* product.

And *that* is uncharted territory indeed.  VMS is probably the closest thing to
Unix/Linux that actually used stuff like SYS$WHATEVER inside a filename to get
a similar effect to moldy directories *and* carry it through all the way for
the base system...


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Single home directory type for all roles.

[Stephen Smalley]

On Fri, 2004-12-10 at 12:00, Valdis.Kletnieks@vt.edu wrote:
> Why am I making a point about this?  Because we're presumably working on
> something that will be in the *mainline* kernel, and have support in the
> default .ISO images shipped by vendors - and I don't know of any Unix vendor
> who's shipped this stuff in their *mainline* product.
> 
> And *that* is uncharted territory indeed.  VMS is probably the closest thing to
> Unix/Linux that actually used stuff like SYS$WHATEVER inside a filename to get
> a similar effect to moldy directories *and* carry it through all the way for
> the base system...

My view on this is that we need to build a mechanism that leverages the
existing per-process namespace and bind mount support in Linux.  If
implementing it in userspace using only those existing kernel
mechanisms, the basic idea would be something like:

1) login-style programs would consult a configuration file that
specifies the list of candidate directories for polyinstantiation (e.g.
/tmp, $HOME),
2) The programs would then invoke security_compute_member() (the SELinux
interface for selecting a member of a polyinstantiated object) between
the user context and the top-level directory context for each of these
directories,
3) If security_compute_member() returns a different context than the
context on the top-level directory, then this indicates that
polyinstantiation of that directory is specified by the policy.  In that
case, the program would lookup or create the member subdirectory with
the returned member context, using a function of the member context as
the name of the member subdirectory (e.g. a hash of it).
4) If any polyinstantiation was indicated, then the program would clone
a child with a separate namespace rather than just using fork for
creating the child.
5) For each directory for which polyinstantiation was indicated the
child would bind mount the original directory under a different name to
allow referencing by security-aware applications that need to access
multiple members (if allowed by policy), then bind mount the member
subdirectory over the original directory location.
6) The child process can then exec the user shell, which will operate in
the new namespace.

Some thought would have to be given into how to handle programs like
su/newrole/newlevel, where you then need to re-bind to a different
member.  Since the original directory will be accessible under a
different name (e.g. /tmp -> /.tmp) if allowed by policy, it should be
possible to have them perform such re-binding.

This will also have implication for other software that presently
assumes a global namespace, e.g. autofs/automount won't work properly in
an environment where most user sessions have their own namespace.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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: Single home directory type for all roles.

[Casey Schaufler]

--- Valdis.Kletnieks@vt.edu wrote:

> On Fri, 10 Dec 2004 08:19:39 PST, Casey Schaufler
> said:
> 
> > > Or if
> > > it *is* solved there, it's not actually made it
> into
> > > AIX, Irix, Tru64, or Solaris.
> > 
> > You have to go to the costs-extra multilevel
> secure
> > versions.
> 
> Right.  And that was my point - that although every
> vendor has managed to hack
> something up, it hasn't ever escaped and gotten any
> significant mindshare. You
> may as well say that somebody's already solved this
> for Linux, because there
> exists some out-of-tree patch that handles it. 
> Because that's what all those
> basically were - out-of-mainline-tree add-ons.

Although I expect you may invoke the "splitting
hairs" counter, the Trusted versions of Irix,
Solaris, and UNICOS build from the same source
tree (the mainline) as thier regular counterparts
do (or did in the UNICOS case). The vendors charge
extra for the modules, but they are built along
with everything else.

> It
> hasn't been solved for "the
> Unix world", it's been solved for some tiny subset
> that were forced to install
> "an MLS component" for whatever reason, and had to
> deal with all the borkedness
> of the bolt-on because there wasn't enough market
> share to make it Really Work

The integration of MLS systems with their SLU
breathern is much tighter than you seem to believe.

> Right (go ahead - admit it.  Trusted Irix almost
> certainly had plenty of warts
> on it that never got fixed because Trusted Irix had
> only a miniscule market share,
> when similar-sized warts in the regular Irix would
> get fixed...)

Sure. On the other hand, Trix had major influence
on CXFS because so many Big HPC sites wanted both.

> And "in the base level" is an important thing - I've
> seen *plenty* of sites
> that don't want to have to install (or pay for) a
> full MLS implementation when
> all they want is some variant of "We need to
> redirect each user's view of /tmp
> to $USER/tmp just so they quit stepping on each
> other's toes accidentally".

Err, not to hold up a mirror or anything, but
SELinux faces all of those issues.

> Everybody who's ever worked the help desk at a uni
> and had to answer "How come
> I can't save test1.c?" with "because some other user
> already saved test1.c in
> /tmp" knows exactly what I mean...
> 
> (Admittedly, it was even worse in the days before
> 'chmod +t /tmp', when one
> user doing a 'rm *' could totally adger the work of
> everybody on the system..)
> 

> > Trusted Solaris, Trusted Irix, SystemV/MLS, UNICOS
> > all include it.
> 
> After-the-fact bolt-ons, all of them. ;)

All of which have over a decade of deployment,
predate over half the current kernel code in their
respective systems, and all of which are in the
base source trees.

It's fun to discuss this, but hey. Enjoy the code
if you like, ignore it otherwise.


=====
Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Do you Yahoo!? 
Take Yahoo! Mail with you! Get it on your mobile phone. 
http://mobile.yahoo.com/maildemo 

--
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: Single home directory type for all roles.

[Valdis.Kletnieks]

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

On Fri, 10 Dec 2004 05:12:31 +1100, Russell Coker said:

> The solution then would be to have a separate domain for the
> administrator to run ls which can read all sym-links while other
> programs the administrator may run (rm, cp, mv, etc) will be denied
> access to read many types of sym-link.  Is this a good idea?

Probably not - then you get into a situation where you try to mv/rm/cp
something, it fails, and when you run ls, it looks like it should work....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Single home directory type for all roles.

[Russell Coker]

On Thu, 2004-12-09 at 15:40 -0500, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 10 Dec 2004 05:12:31 +1100, Russell Coker said:
> 
> > The solution then would be to have a separate domain for the
> > administrator to run ls which can read all sym-links while other
> > programs the administrator may run (rm, cp, mv, etc) will be denied
> > access to read many types of sym-link.  Is this a good idea?
> 
> Probably not - then you get into a situation where you try to mv/rm/cp
> something, it fails, and when you run ls, it looks like it should work....

That would only happen when you do "ls -l /tmp/foo/bar" and
"cp /tmp/foo/bar /whatever" and /tmp/foo is a sym-link.  It's not the
most common use, but you are correct it would bite people occasionally.

Creating a new permission for sym-links as in Steve's test patch is the
best solution.

--
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: Single home directory type for all roles.

[Daniel J Walsh]

Ok I succumb.    I will not fight the battle any longer, but I believe 
that average people will not user roles because it
is too difficult.  I will not build tools that will automatically 
relabel the file system since these will be prone
to errors.  People will run users in the default role of the system, 
whether we default it to user_r  with user_canbe_sysadm,
or default to staff. 

I believe that the only people who will use roles as they are currently 
constituted are security people. 

Dan

--
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: Single home directory type for all roles.

[Stephen Smalley]

On Fri, 2004-12-10 at 09:09, Daniel J Walsh wrote:
> People will run users in the default role of the system, 
> whether we default it to user_r  with user_canbe_sysadm,
> or default to staff. 
> 
> I believe that the only people who will use roles as they are currently 
> constituted are security people. 

That will be true for most users until we have integrated user
management.  I've given you the basic building block for doing that
without requiring full policy sources (genpolusers), why can't you at
least integrate with system-config-users?  I know that won't help with
NIS/LDAP/..., but it is a starting point.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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: Single home directory type for all roles.

[Colin Walters]

On Fri, 2004-12-10 at 09:09 -0500, Daniel J Walsh wrote:
> Ok I succumb.    I will not fight the battle any longer, but I believe 
> that average people will not user roles because it
> is too difficult. 

Couldn't we just have the role as an additional option on user creation,
but is readonly thereafter?  That would be useful to me at least.



--
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: Single home directory type for all roles.

[Casey Schaufler]

--- Daniel J Walsh <dwalsh@redhat.com> wrote:

> Ok I succumb.    I will not fight the battle any
> longer, but I believe 
> that average people will not user roles because it
> is too difficult.

Roles are *hard*. The best scheme we ever came up
with in the B1/CMW era was to devote a role to each
MAC label that the system used. Thus, system
information that was not sensitive (e.g. /etc/passwd)
was associated with one role, system information
that was sensitive (e.g. /etc/shadow) got another,
and audit trail file got a third. We ended up
trashing the whole role model because it made
working with name services too difficult. Oh, and
the first question out of every customer's mouth was
"How do I get real root"?



=====
Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.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: Single home directory type for all roles.

[Russell Coker]

On Fri, 2004-12-10 at 09:09 -0500, Daniel J Walsh wrote:
> Ok I succumb.    I will not fight the battle any longer, but I believe 
> that average people will not user roles because it
> is too difficult.  I will not build tools that will automatically 
> relabel the file system since these will be prone
> to errors.  People will run users in the default role of the system, 
> whether we default it to user_r  with user_canbe_sysadm,
> or default to staff. 

I think that the way to go is to have staff_t be the default login
domain, have two roles for it staff_r and staff_restricted_r where the
latter can't change to sysadm_r and has other limitations.  I'll write
the policy for staff_restricted_r.

> I believe that the only people who will use roles as they are currently 
> constituted are security people. 

Currently the only people who use strict policy are "security people".

--
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: Single home directory type for all roles.

[Daniel J Walsh]

Russell Coker wrote:

>On Fri, 2004-12-10 at 09:09 -0500, Daniel J Walsh wrote:
>  
>
>>Ok I succumb.    I will not fight the battle any longer, but I believe 
>>that average people will not user roles because it
>>is too difficult.  I will not build tools that will automatically 
>>relabel the file system since these will be prone
>>to errors.  People will run users in the default role of the system, 
>>whether we default it to user_r  with user_canbe_sysadm,
>>or default to staff. 
>>    
>>
>
>I think that the way to go is to have staff_t be the default login
>domain, have two roles for it staff_r and staff_restricted_r where the
>latter can't change to sysadm_r and has other limitations.  I'll write
>the policy for staff_restricted_r.
>
>  
>
>>I believe that the only people who will use roles as they are currently 
>>constituted are security people. 
>>    
>>
>
>Currently the only people who use strict policy are "security people".
>  
>
By security people, I meant people who understand how to write policy.  
My opinion, is the
end goal of strict policy should be used by security admins who don't 
need to know how to write
policy. selinux-policy-strict-sources should end up being like 
kernel-sources.  Only to be used by
developers and people interested in how the system works. 

--
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: Single home directory type for all roles.

[Russell Coker]

On Mon, 2004-12-13 at 08:56 -0500, Daniel J Walsh wrote:
> >>I believe that the only people who will use roles as they are currently 
> >>constituted are security people. 
> >>
> >
> >Currently the only people who use strict policy are "security people".
> >  
> >
> By security people, I meant people who understand how to write policy.  

Same here.

> My opinion, is the
> end goal of strict policy should be used by security admins who don't 
> need to know how to write
> policy. selinux-policy-strict-sources should end up being like 
> kernel-sources.  Only to be used by
> developers and people interested in how the system works. 

I mostly agree with that.  However at the moment we are far from it in
so many ways that the issue of roles is minor.

--
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: Single home directory type for all roles.

[Thomas Bleher]

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

* Stephen Smalley <sds@epoch.ncsc.mil> [2004-12-09 19:50]:
> On Thu, 2004-12-09 at 12:47, Russell Coker wrote:
> > However there still are issues because sysadm_t can read symlinks of
> > type user_tmp_t, so a user can attempt a symlink race condition attack
> > on the administrator.
> 
> Yes, that should be removed IMHO.  Currently only occurs due to allow
> rule on sysadmfile:lnk_file.   

A while ago we had this discussion on the lsm-list. Colin suggested
using the following patch to prevent symlinks attacks:

--- orig/constraints
+++ mod/constraints
@@ -67,3 +67,7 @@
 constrain socket_class_set { create relabelto relabelfrom } 
 	( u1 == u2 or t1 == privowner );
 
+# read symlinks under /tmp only if owners match
+constrain lnk_file read
+	( t2 != tmpfile or u1 == u2 );
+ 

I have used this patch for a few weeks on our systems (university, ~150
computers, ~4000 users, all with separate SELinux identity), no
complaints or problems so far (except the tetex_data_t change I posted
today) So I'd like this patch included in cvs policy.
Of course, this is only really useful if you have separate user
identities for your users.

Thomas

-- 
http://www.cip.ifi.lmu.de/~bleher/selinux/ - my SELinux pages
GPG-Fingerprint: BC4F BB16 30D6 F253 E3EA  D09E C562 2BAE B2F4 ABE7

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Single home directory type for all roles.

[Russell Coker]

On Thu, 2004-12-09 at 20:07 +0100, Thomas Bleher wrote:
> A while ago we had this discussion on the lsm-list. Colin suggested
> using the following patch to prevent symlinks attacks:
> 
> --- orig/constraints
> +++ mod/constraints
> @@ -67,3 +67,7 @@
>  constrain socket_class_set { create relabelto relabelfrom } 
>  	( u1 == u2 or t1 == privowner );
>  
> +# read symlinks under /tmp only if owners match
> +constrain lnk_file read
> +	( t2 != tmpfile or u1 == u2 );
> + 

That will be fine AFTER we have a follow operation as in the sample
patch Steve just posted.

For some particular environments with clueful administrators it might
not be a big deal to deny the administrator the ability to run
"ls -l /tmp" and see everything that they would see without SE Linux.
In most cases I believe that they will demand that they can have a fully
functional ls.  Also even for skilled administrators, it's just really
handy to be able to see what the users are doing.  Being forced to login
as a user (or su to the user in Fedora) just to see what sym-links they
have in /tmp is unweildy.

Also the constraints entry would have to apply to home_type for correct
operation on systems where /tmp and /home are on the same file system
which is the result of "autopartitioning" in Fedora Core and a common
practice by many (most?) administrators of small systems.

constrain lnk_file read
	( (t2 != tmpfile and t2 != home_type) or u1 == u2 );

--
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: Single home directory type for all roles.

[Colin Walters]

On Thu, 2004-12-09 at 11:50 -0500, Daniel J Walsh wrote:

> 1.  Causes problems with sharing files between users,   IE a staff user 
> coping a file to tmp and then the user
> can't read it, because it has the wrong type. 

I feel that what we really need is an explicit file sharing area; for
example the gnome-user-share program uses /home/$USER/Public.  Having a
special label for public files like this will also allow us to write
policy for the gnome-user-share Apache daemon.  It does seem wrong to me
for any user_t to have access to my staff_t temporary files, and also
the other way around (remember that user_t/staff_t prevents /tmp race
conditions).  I run a strict server on which I have several users who I
don't *entirely* trust.  The extra assurance the user_t/staff_t
distinction brings is nice.

> 2.  Requirement that selinux-policy-strict-sources be installed and a 
> rebuild of policy in order to change the roles of a user.

I'm not sure I see what's so bad about this.  I would assume that most
people running strict will have to customize policy anyways.

> 3.  But the number one problem I have is with relabeling files.  If I 
> were to implement roles management in
> system-config-securitylevel/adduser, I would need to trigger a relabel 
> any time a role of a user was changed.  This
> relabel would have to be inteligent enough to figure out not only the 
> home directories, but also the files in /tmp and potentially
> files in html files scattered over the system.  I find this an 
> unworkable situation.

Hmm.  But the fact that in the default strict policy user_r and staff_r
are nearly equivalent in terms of functionality is really a special
case, no?  I imagine most people really using RBAC will be defining
specialized roles such as webmaster_r, nurse_r, developer_r, etc.  In
this situation it seems to me that it would be unusual for a person to
switch roles entirely; much more likely they would gain a role.  And if
they *did* switch roles, it seems likely that they would not have access
to their old files at all.  

> So yesterday I went though the policy and created a new tunable 
> single_user_file_type, that causes the policy to share a common
> filetypes between staff and users.  (Haven't completed this for http yet). 

I'm not saying it's not useful to have an option, but before
recommending this, I'd like to think a bit more about any other possible
solutions.  I don't have any good ideas about how to handle user_r ->
staff_r in general right now though.

> With SELinux Policy Modules, can I build an system-config-user/adduser 
> that would modify a file under /etc/selinux/strict/roles/
> (the users file) and then reload just that policy?

I haven't looked in detail at binary policy modules, but my guess is
that they can't *delete* a role, type, or permission.  So it seems
difficult to use a binary policy module to change a user's role, e.g.
from user_r to staff_r as you suggest.



--
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: Single home directory type for all roles.

[Russell Coker]

On Thu, 2004-12-09 at 12:28 -0500, Colin Walters wrote:
> policy for the gnome-user-share Apache daemon.  It does seem wrong to me
> for any user_t to have access to my staff_t temporary files, and also
> the other way around (remember that user_t/staff_t prevents /tmp race
> conditions).  I run a strict server on which I have several users who I
> don't *entirely* trust.  The extra assurance the user_t/staff_t
> distinction brings is nice.

Currently the default policy has /root labeled as staff_home_dir_t.
This significantly weakens the boundaries between staff_r and sysadm_r.
If we were to make changes which then weaken the boundaries between
user_r and staff_r then we might as well just have no user_r and staff_r
and use sysadm_r for all user logins - IE have the targeted policy.

> > 2.  Requirement that selinux-policy-strict-sources be installed and a 
> > rebuild of policy in order to change the roles of a user.
> 
> I'm not sure I see what's so bad about this.  I would assume that most
> people running strict will have to customize policy anyways.

I agree.

> Hmm.  But the fact that in the default strict policy user_r and staff_r
> are nearly equivalent in terms of functionality is really a special
> case, no?

A bug IMHO.  If we have two roles that become almost equivalent then the
sensible thing to do is remove one.  If we decide that for Fedora strict
policy we don't want to have any regular users be denied the ability
perform administrative tasks then the correct thing to do is to make
staff_r the default user role.

It's easy enough for anyone to add a new role if they need more roles
than the default policy provides.

>   I imagine most people really using RBAC will be defining
> specialized roles such as webmaster_r, nurse_r, developer_r, etc.  In
> this situation it seems to me that it would be unusual for a person to
> switch roles entirely; much more likely they would gain a role.  And if
> they *did* switch roles, it seems likely that they would not have access
> to their old files at all.  

Gaining a role (IE one user having multiple roles) is another issue
entirely.  But I think that apart from the special case of staff_r and
sysadm_r there is little need to have multiple roles.

You might have a situation where developers and webmasters have write
access to the web content.  Web masters have access to web logs, and
developers have access to source.  Writing appropriate TE rules for this
such that developers can do everything they need as developer_t and web
masters can do everything they need as webmaster_t is easy enough.

> > With SELinux Policy Modules, can I build an system-config-user/adduser 
> > that would modify a file under /etc/selinux/strict/roles/
> > (the users file) and then reload just that policy?
> 
> I haven't looked in detail at binary policy modules, but my guess is
> that they can't *delete* a role, type, or permission.  So it seems
> difficult to use a binary policy module to change a user's role, e.g.
> from user_r to staff_r as you suggest.

If you use binary policy modules to add roles and the users in question
are not in the base policy then this might work.

--
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: Single home directory type for all roles.

[Daniel J Walsh]

Russell Coker wrote:

>On Thu, 2004-12-09 at 12:28 -0500, Colin Walters wrote:
>  
>
>>policy for the gnome-user-share Apache daemon.  It does seem wrong to me
>>for any user_t to have access to my staff_t temporary files, and also
>>the other way around (remember that user_t/staff_t prevents /tmp race
>>conditions).  I run a strict server on which I have several users who I
>>don't *entirely* trust.  The extra assurance the user_t/staff_t
>>distinction brings is nice.
>>    
>>
>
>Currently the default policy has /root labeled as staff_home_dir_t.
>This significantly weakens the boundaries between staff_r and sysadm_r.
>If we were to make changes which then weaken the boundaries between
>user_r and staff_r then we might as well just have no user_r and staff_r
>and use sysadm_r for all user logins - IE have the targeted policy.
>  
>
With this change, I would go back to /root labeled as sysadm_home_t, 
which should probably happen
anyways as we move to stricter policy.

I am trying to strengthen the difference between them without having to 
relabel files if I change the role of the user.
Current policy on Fedora Strict policy basically shows no difference 
between staff and user so adding this allows us
to remove some privs from user_r without causing the user to do a 
massive relabel.

>  
>
>>>2.  Requirement that selinux-policy-strict-sources be installed and a 
>>>rebuild of policy in order to change the roles of a user.
>>>      
>>>
>>I'm not sure I see what's so bad about this.  I would assume that most
>>people running strict will have to customize policy anyways.
>>    
>>
>
>I agree.
>
>  
>
Yes up to now they have had too, but we are trying to expand the number 
of users of strict policy. 
I believe if you have to massively relabel in the course of 
administrating the machine, we have a bug.

>>Hmm.  But the fact that in the default strict policy user_r and staff_r
>>are nearly equivalent in terms of functionality is really a special
>>case, no?
>>    
>>
>
>A bug IMHO.  If we have two roles that become almost equivalent then the
>sensible thing to do is remove one.  If we decide that for Fedora strict
>policy we don't want to have any regular users be denied the ability
>perform administrative tasks then the correct thing to do is to make
>staff_r the default user role.
>
>  
>
I want to go back to the separation between user and staff without the 
differences in file system.

>It's easy enough for anyone to add a new role if they need more roles
>than the default policy provides.
>
>  
>
Not without relabing the file system.  Currently if I want to add a new 
role, say student that has less privs
then user,  I need to massively rewrite the policy.  If we came up with 
a policy that shared homedir and tmpdir
file contexts between all types of users, I could begin to create 
additional default roles for people.

>>  I imagine most people really using RBAC will be defining
>>specialized roles such as webmaster_r, nurse_r, developer_r, etc.  In
>>this situation it seems to me that it would be unusual for a person to
>>switch roles entirely; much more likely they would gain a role.  And if
>>they *did* switch roles, it seems likely that they would not have access
>>to their old files at all.  
>>    
>>
>
>Gaining a role (IE one user having multiple roles) is another issue
>entirely.  But I think that apart from the special case of staff_r and
>sysadm_r there is little need to have multiple roles.
>
>You might have a situation where developers and webmasters have write
>access to the web content.  Web masters have access to web logs, and
>developers have access to source.  Writing appropriate TE rules for this
>such that developers can do everything they need as developer_t and web
>masters can do everything they need as webmaster_t is easy enough.
>
>  
>
>>>With SELinux Policy Modules, can I build an system-config-user/adduser 
>>>that would modify a file under /etc/selinux/strict/roles/
>>>(the users file) and then reload just that policy?
>>>      
>>>
>>I haven't looked in detail at binary policy modules, but my guess is
>>that they can't *delete* a role, type, or permission.  So it seems
>>difficult to use a binary policy module to change a user's role, e.g.
>>from user_r to staff_r as you suggest.
>>    
>>
>
>If you use binary policy modules to add roles and the users in question
>are not in the base policy then this might work.
>  
>


--
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: Single home directory type for all roles.

[Stephen Smalley]

On Thu, 2004-12-09 at 14:45, Daniel J Walsh wrote:
> Yes up to now they have had too, but we are trying to expand the number 
> of users of strict policy. 
> I believe if you have to massively relabel in the course of 
> administrating the machine, we have a bug.

Massively relabeling would indeed be wrong.  At most, we're talking
about a user's own files, and even there, I don't think we want to
automatically relabel anyway.  It requires knowledge of:
- the relationship between the old role and new role,
- the data in question.

The admin may just choose to move aside the old home directory and start
a new one for the user, e.g. with "clean" dotfiles to avoid tainting.

> I want to go back to the separation between user and staff without the 
> differences in file system.

If there is no difference in the filesystem, then what real separation
have you achieved?  At that point, you are relying entirely on DAC to
protect staff_r's files from user_r (except for relying on SELinux to
prevent DAC overrides by user_r).

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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: Single home directory type for all roles.

[Russell Coker]

On Thu, 2004-12-09 at 14:45 -0500, Daniel J Walsh wrote:
> >A bug IMHO.  If we have two roles that become almost equivalent then the
> >sensible thing to do is remove one.  If we decide that for Fedora strict
> >policy we don't want to have any regular users be denied the ability
> >perform administrative tasks then the correct thing to do is to make
> >staff_r the default user role.
> >
> I want to go back to the separation between user and staff without the 
> differences in file system.

That's impossible.  If you can write to someone's .bashrc file or
similar then you can get their privs.

> >It's easy enough for anyone to add a new role if they need more roles
> >than the default policy provides.
> >
> Not without relabing the file system.

The expected practice should be to create the role before creating the
user who will have it.  This means that there should not be a need to
relabel.  There is only a need to relabel if you change the roles that
are permitted after the machine has been running.  But that also means
you may have to have the user logout first to prevent processes becoming
unlabeled.

>   Currently if I want to add a new 
> role, say student that has less privs
> then user,  I need to massively rewrite the policy.  If we came up with 
> a policy that shared homedir and tmpdir
> file contexts between all types of users, I could begin to create 
> additional default roles for people.

For what benefit?  If they share file types and they share X access
(with xdm logins) then what benefits can we gain from multiple roles?

Multiple roles will still increase administrative overhead even without
multiple file types.  So multiple roles with the same types gives you
some of the overhead with almost none of the benefit.


--
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: Single home directory type for all roles.

[Daniel J Walsh]

Russell Coker wrote:

>On Thu, 2004-12-09 at 14:45 -0500, Daniel J Walsh wrote:
>  
>
>>>A bug IMHO.  If we have two roles that become almost equivalent then the
>>>sensible thing to do is remove one.  If we decide that for Fedora strict
>>>policy we don't want to have any regular users be denied the ability
>>>perform administrative tasks then the correct thing to do is to make
>>>staff_r the default user role.
>>>
>>>      
>>>
>>I want to go back to the separation between user and staff without the 
>>differences in file system.
>>    
>>
>
>That's impossible.  If you can write to someone's .bashrc file or
>similar then you can get their privs.
>  
>
So we either go to full MAC which few people will use, or we have to 
rely partially on DAC for protection.
I am looking for a way to raise the bar on policy without making a multi 
use machine unmanageable. 


BTW I like the idea of defaulting to staff_r.  I think we should do that 
and turn off user_canbe_sysadm.

>  
>
>>>It's easy enough for anyone to add a new role if they need more roles
>>>than the default policy provides.
>>>
>>>      
>>>
>>Not without relabing the file system.
>>    
>>
>
>The expected practice should be to create the role before creating the
>user who will have it.  This means that there should not be a need to
>relabel.  There is only a need to relabel if you change the roles that
>are permitted after the machine has been running.  But that also means
>you may have to have the user logout first to prevent processes becoming
>unlabeled.
>
>  
>
Yes that is all well in good, but it does not work that way in the real 
world.  Admins
are going to want to be able to change peoples roles.

>>  Currently if I want to add a new 
>>role, say student that has less privs
>>then user,  I need to massively rewrite the policy.  If we came up with 
>>a policy that shared homedir and tmpdir
>>file contexts between all types of users, I could begin to create 
>>additional default roles for people.
>>    
>>
>
>For what benefit?  If they share file types and they share X access
>(with xdm logins) then what benefits can we gain from multiple roles?
>
>Multiple roles will still increase administrative overhead even without
>multiple file types.  So multiple roles with the same types gives you
>some of the overhead with almost none of the benefit.
>
>  
>
Roles can be used to govern which applications can be run.  So I could 
have a student role where only
student applications could be run. 

--
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: Single home directory type for all roles.

[Russell Coker]

On Thu, 2004-12-09 at 15:22 -0500, Daniel J Walsh wrote:
> Roles can be used to govern which applications can be run.  So I could 
> have a student role where only
> student applications could be run. 

That doesn't require multiple default domains.  You could have two roles
user_r and user_student_r that only differ in whether
user_student_exec_t can be executed to enter domain user_student_t.

I think that the real solution to the issues you raise are in using
roles more and different login domains less.

--
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: Single home directory type for all roles.

[Thomas Bleher]

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

* Daniel J Walsh <dwalsh@redhat.com> [2004-12-09 22:21]:
> Russell Coker wrote:
> >On Thu, 2004-12-09 at 14:45 -0500, Daniel J Walsh wrote:
> >The expected practice should be to create the role before creating the
> >user who will have it.  This means that there should not be a need to
> >relabel.  There is only a need to relabel if you change the roles that
> >are permitted after the machine has been running.  But that also means
> >you may have to have the user logout first to prevent processes becoming
> >unlabeled.
> >
> Yes that is all well in good, but it does not work that way in the real 
> world.  Admins
> are going to want to be able to change peoples roles.

Then they'll have to relabel the users home dir, delete /tmp and logout
the user. That's life.
I think it's a price worth paying for the added security benefit.
And it's not like an admin has to add a new role every day.

> Roles can be used to govern which applications can be run.  So I could 
> have a student role where only
> student applications could be run. 

That's right, but unless you lock down the account _very_ much, you
can't prevent them from running arbitrary code. That's something to keep
in mind.

Thomas

-- 
http://www.cip.ifi.lmu.de/~bleher/selinux/ - my SELinux pages
GPG-Fingerprint: BC4F BB16 30D6 F253 E3EA  D09E C562 2BAE B2F4 ABE7

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Single home directory type for all roles.

[Russell Coker]

On Thu, 2004-12-09 at 22:38 +0100, Thomas Bleher wrote:
> > Roles can be used to govern which applications can be run.  So I could 
> > have a student role where only
> > student applications could be run. 
> 
> That's right, but unless you lock down the account _very_ much, you
> can't prevent them from running arbitrary code. That's something to keep
> in mind.

Also we have to look into the can_exec_any() situation.  An increasing
number of domains use this macro to execute most binaries on the system.
I am not convinced that it is suitable for any domain, not even user_t.

--
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: Single home directory type for all roles.

[Colin Walters]

On Thu, 2004-12-09 at 15:22 -0500, Daniel J Walsh wrote:

> BTW I like the idea of defaulting to staff_r.  I think we should do that 
> and turn off user_canbe_sysadm.

Fully agreed on this btw.



--
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: Single home directory type for all roles.

[Stephen Smalley]

On Thu, 2004-12-09 at 17:29, Colin Walters wrote:
> On Thu, 2004-12-09 at 15:22 -0500, Daniel J Walsh wrote:
> 
> > BTW I like the idea of defaulting to staff_r.  I think we should do that 
> > and turn off user_canbe_sysadm.
> 
> Fully agreed on this btw.

I'm not sure about this proposal.  Remember that I reworked user.te so
that user_canbe_sysadm does not convey all of the permissions of staff_t
to user_t (i.e. the full priv_user macro); it only conveys the
reach_sysadm permissions for using su/sudo/userhelper to reach sysadm. 
Also, if you have everyone default to staff_r, including user_u, then if
you ever want to enable the user/staff separation, you have to relabel
all of the home directories for people you want to put back into user_r,
which is likely a larger set than the ones you want to put into
staff_r.  Or am I missing something?

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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: Single home directory type for all roles.

[Colin Walters]

On Fri, 2004-12-10 at 08:11 -0500, Stephen Smalley wrote:
> On Thu, 2004-12-09 at 17:29, Colin Walters wrote:
> > On Thu, 2004-12-09 at 15:22 -0500, Daniel J Walsh wrote:
> > 
> > > BTW I like the idea of defaulting to staff_r.  I think we should do that 
> > > and turn off user_canbe_sysadm.
> > 
> > Fully agreed on this btw.
> 
> I'm not sure about this proposal.  Remember that I reworked user.te so
> that user_canbe_sysadm does not convey all of the permissions of staff_t
> to user_t (i.e. the full priv_user macro); it only conveys the
> reach_sysadm permissions for using su/sudo/userhelper to reach sysadm. 

Ok, that makes sense.

> Also, if you have everyone default to staff_r, including user_u, then if
> you ever want to enable the user/staff separation, you have to relabel
> all of the home directories for people you want to put back into user_r,
> which is likely a larger set than the ones you want to put into
> staff_r. 

Well, I think we want to avoid switching user roles as much as possible;
if we have integrated roles into useradd, then the system administrator
can add any additional users they want into user_r or staff_r as
desired.



--
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: Single home directory type for all roles.

[Thomas Bleher]

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

* Daniel J Walsh <dwalsh@redhat.com> [2004-12-09 21:49]:
> Russell Coker wrote:
> >On Thu, 2004-12-09 at 12:28 -0500, Colin Walters wrote:
> >>policy for the gnome-user-share Apache daemon.  It does seem wrong to me
> >>for any user_t to have access to my staff_t temporary files, and also
> >>the other way around (remember that user_t/staff_t prevents /tmp race
> >>conditions).  I run a strict server on which I have several users who I
> >>don't *entirely* trust.  The extra assurance the user_t/staff_t
> >>distinction brings is nice.
> >>   
> >>
> >
> >Currently the default policy has /root labeled as staff_home_dir_t.
> >This significantly weakens the boundaries between staff_r and sysadm_r.
> >If we were to make changes which then weaken the boundaries between
> >user_r and staff_r then we might as well just have no user_r and staff_r
> >and use sysadm_r for all user logins - IE have the targeted policy.
> > 
> >
> With this change, I would go back to /root labeled as sysadm_home_t, 
> which should probably happen
> anyways as we move to stricter policy.

Agreed.

> I am trying to strengthen the difference between them without having to 
> relabel files if I change the role of the user.
> Current policy on Fedora Strict policy basically shows no difference 
> between staff and user so adding this allows us
> to remove some privs from user_r without causing the user to do a 
> massive relabel.
> >
> >>>2.  Requirement that selinux-policy-strict-sources be installed and a 
> >>>rebuild of policy in order to change the roles of a user.
> >>>     
> >>>
> >>I'm not sure I see what's so bad about this.  I would assume that most
> >>people running strict will have to customize policy anyways.
> >
> >I agree.
> >
> Yes up to now they have had too, but we are trying to expand the number 
> of users of strict policy. 
> I believe if you have to massively relabel in the course of 
> administrating the machine, we have a bug.
> 
> >>Hmm.  But the fact that in the default strict policy user_r and staff_r
> >>are nearly equivalent in terms of functionality is really a special
> >>case, no?
> >
> >A bug IMHO.  If we have two roles that become almost equivalent then the
> >sensible thing to do is remove one.  If we decide that for Fedora strict
> >policy we don't want to have any regular users be denied the ability
> >perform administrative tasks then the correct thing to do is to make
> >staff_r the default user role.
> >
> I want to go back to the separation between user and staff without the 
> differences in file system.
> 
> >It's easy enough for anyone to add a new role if they need more roles
> >than the default policy provides.
> >
> Not without relabing the file system.  Currently if I want to add a new 
> role, say student that has less privs
> then user,  I need to massively rewrite the policy.  If we came up with 
> a policy that shared homedir and tmpdir
> file contexts between all types of users, I could begin to create 
> additional default roles for people.

But then you lose almost all the benefit of having separate roles in the
first place. Because then the separation between roles depends entirely
on DAC permissions. I don't think that's the right way to go.

If someone needs separate roles for security why would he compromise
on this?

And you still have to know policy to add a new role and understand which
permissions it needs. If you know all this, relabeling is no problem for
you.

Maybe we need to build some higher order macros, to make creating new
roles easier, so a full user role looks something like this:

# type for home dir, access to tty
base_permissions(student)
can_mount(student)
# can see all processes
dnl can_ps(student, domain)
can_network_server(student)

# professor can read temporary files of students
read_tmp_files(professor, student)

Thomas

-- 
http://www.cip.ifi.lmu.de/~bleher/selinux/ - my SELinux pages
GPG-Fingerprint: BC4F BB16 30D6 F253 E3EA  D09E C562 2BAE B2F4 ABE7

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Single home directory type for all roles.

[Russell Coker]

On Thu, 2004-12-09 at 22:16 +0100, Thomas Bleher wrote:
> Maybe we need to build some higher order macros, to make creating new
> roles easier, so a full user role looks something like this:
> 
> # type for home dir, access to tty
> base_permissions(student)
> can_mount(student)
> # can see all processes
> dnl can_ps(student, domain)
> can_network_server(student)
> 
> # professor can read temporary files of students
> read_tmp_files(professor, student)

This is the general direction that things are going in.  It's just that
progress on changes to user role definitions has been slow.

--
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: Single home directory type for all roles.

[Colin Walters]

On Fri, 2004-12-10 at 05:02 +1100, Russell Coker wrote:

> Currently the default policy has /root labeled as staff_home_dir_t.
> This significantly weakens the boundaries between staff_r and sysadm_r.

I don't see there as being an interesting boundary between staff_r and
sysadm_r.  The reason I see staff_r as separated is because it has no
interaction with user_r, which closes a lot of possible attacks.

> If we were to make changes which then weaken the boundaries between
> user_r and staff_r then we might as well just have no user_r and staff_r
> and use sysadm_r for all user logins - IE have the targeted policy.

Yes, allowing interaction between user_r and staff_r would be bad.

> A bug IMHO.  If we have two roles that become almost equivalent then the
> sensible thing to do is remove one.  If we decide that for Fedora strict
> policy we don't want to have any regular users be denied the ability
> perform administrative tasks then the correct thing to do is to make
> staff_r the default user role.

Agreed.



--
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: Single home directory type for all roles.

[Russell Coker]

On Thu, 2004-12-09 at 17:43 -0500, Colin Walters wrote:
> On Fri, 2004-12-10 at 05:02 +1100, Russell Coker wrote:
> > Currently the default policy has /root labeled as staff_home_dir_t.
> > This significantly weakens the boundaries between staff_r and sysadm_r.
> 
> I don't see there as being an interesting boundary between staff_r and
> sysadm_r.  The reason I see staff_r as separated is because it has no
> interaction with user_r, which closes a lot of possible attacks.

Among other things a default configuration allows sshd to permit logins
as staff_r but not sysadm_r.  If a sshd was suspected to be compromised
then you could login at the console as sysadm_r to fix things IFF /root
was not writable to staff_r domains.  If a session launched by sshd can
directly modify files under /root then if you suspected a sshd
compromise then the only option would be to boot from recovery media.

Also note that many daemons look for configuration or data files
under /root, this is due to bugs in daemons but many of them are not
expected to be fixed for quite a while.  Until/unless we get the daemons
in question fixed staff_t can be used to modify the behavior of daemons
with the current labeling of /root (NB in most cases the daemon will
operate without permission to read files under the /root directory, but
even the existence of files can change the behavior).


--
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: Single home directory type for all roles.

[Colin Walters]

On Fri, 2004-12-10 at 13:23 +1100, Russell Coker wrote:
> On Thu, 2004-12-09 at 17:43 -0500, Colin Walters wrote:
> > On Fri, 2004-12-10 at 05:02 +1100, Russell Coker wrote:
> > > Currently the default policy has /root labeled as staff_home_dir_t.
> > > This significantly weakens the boundaries between staff_r and sysadm_r.
> > 
> > I don't see there as being an interesting boundary between staff_r and
> > sysadm_r.  The reason I see staff_r as separated is because it has no
> > interaction with user_r, which closes a lot of possible attacks.
> 
> Among other things a default configuration allows sshd to permit logins
> as staff_r but not sysadm_r.  If a sshd was suspected to be compromised
> then you could login at the console as sysadm_r to fix things IFF /root
> was not writable to staff_r domains.  If a session launched by sshd can
> directly modify files under /root then if you suspected a sshd
> compromise then the only option would be to boot from recovery media.

If you want this, then why not just make your normal account user_r, and
log in as root on the console?

> Also note that many daemons look for configuration or data files
> under /root, this is due to bugs in daemons but many of them are not
> expected to be fixed for quite a while.  

Point, but we should fix those bugs.



--
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: Single home directory type for all roles.

[Luke Kenneth Casson Leighton]

On Fri, Dec 10, 2004 at 10:48:02AM -0500, Colin Walters wrote:

> If you want this, then why not just make your normal account user_r, and
> log in as root on the console?
> 
> > Also note that many daemons look for configuration or data files
> > under /root, this is due to bugs in daemons but many of them are not
> > expected to be fixed for quite a while.  
> 
> Point, but we should fix those bugs.
 
 e.g. if anyone's interested (and using it) - spamassassin, which
 attempts to dump log files (as root) pretty much evvveeerryyywhere.


--
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: Single home directory type for all roles.

[Daniel J Walsh]

Colin Walters wrote:

>On Thu, 2004-12-09 at 11:50 -0500, Daniel J Walsh wrote:
>
>  
>
>>1.  Causes problems with sharing files between users,   IE a staff user 
>>coping a file to tmp and then the user
>>can't read it, because it has the wrong type. 
>>    
>>
>
>I feel that what we really need is an explicit file sharing area; for
>example the gnome-user-share program uses /home/$USER/Public.  Having a
>special label for public files like this will also allow us to write
>policy for the gnome-user-share Apache daemon.  It does seem wrong to me
>for any user_t to have access to my staff_t temporary files, and also
>the other way around (remember that user_t/staff_t prevents /tmp race
>conditions).  I run a strict server on which I have several users who I
>don't *entirely* trust.  The extra assurance the user_t/staff_t
>distinction brings is nice.
>
>  
>
Currently few people use staff, because user can do everything staff can 
do so you are not protected by this protection.
You also do not protect yourself from staff users attacking other staff 
users.

>>2.  Requirement that selinux-policy-strict-sources be installed and a 
>>rebuild of policy in order to change the roles of a user.
>>    
>>
>
>I'm not sure I see what's so bad about this.  I would assume that most
>people running strict will have to customize policy anyways.
>  
>
My goal is to get more people using strict, not just the ones capable of 
writing policy.

>  
>
>>3.  But the number one problem I have is with relabeling files.  If I 
>>were to implement roles management in
>>system-config-securitylevel/adduser, I would need to trigger a relabel 
>>any time a role of a user was changed.  This
>>relabel would have to be inteligent enough to figure out not only the 
>>home directories, but also the files in /tmp and potentially
>>files in html files scattered over the system.  I find this an 
>>unworkable situation.
>>    
>>
>
>Hmm.  But the fact that in the default strict policy user_r and staff_r
>are nearly equivalent in terms of functionality is really a special
>case, no?  I imagine most people really using RBAC will be defining
>specialized roles such as webmaster_r, nurse_r, developer_r, etc.  In
>this situation it seems to me that it would be unusual for a person to
>switch roles entirely; much more likely they would gain a role.  And if
>they *did* switch roles, it seems likely that they would not have access
>to their old files at all.  
>
>  
>
If we move to this plan, we would turn off the compatability between 
user and staff.
So only staff users could su, usermod, newrole.  The reason they are the 
same now is because
of the labeling problem, and the inability to easily change from a user 
to a staff role.  Why would
you not have access to your old files, if you switch roles.  I agree 
this might be good in some cases
but can't we develop a less stringent rule that does not require relabeling.

>>So yesterday I went though the policy and created a new tunable 
>>single_user_file_type, that causes the policy to share a common
>>filetypes between staff and users.  (Haven't completed this for http yet). 
>>    
>>
>
>I'm not saying it's not useful to have an option, but before
>recommending this, I'd like to think a bit more about any other possible
>solutions.  I don't have any good ideas about how to handle user_r ->
>staff_r in general right now though.
>
>  
>
>>With SELinux Policy Modules, can I build an system-config-user/adduser 
>>that would modify a file under /etc/selinux/strict/roles/
>>(the users file) and then reload just that policy?
>>    
>>
>
>I haven't looked in detail at binary policy modules, but my guess is
>that they can't *delete* a role, type, or permission.  So it seems
>difficult to use a binary policy module to change a user's role, e.g.
>from user_r to staff_r as you suggest.
>
>
>  
>


--
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: Single home directory type for all roles.

[Stephen Smalley]

On Thu, 2004-12-09 at 14:38, Daniel J Walsh wrote:
> Currently few people use staff, because user can do everything staff can 
> do so you are not protected by this protection.
> You also do not protect yourself from staff users attacking other staff 
> users.

Few Fedora SELinux users use staff_r because user_canbe_sysadm is
enabled by default in the Fedora policy.  Disable it, and they'll start
using staff_r, because they will have to do so.  Colin has separation
between staff_r and user_r if he has disabled that tunable, which I
expect he has.  As for staff vs. staff, SELinux can only separate
different security contexts; otherwise, you are relying on DAC (of
course, SELinux does control the Linux capabilities, so your ability to
override DAC controls can be limited by SELinux).

If you disabled user_canbe_sysadm, and provided integrated user
management so that people could update their policy users configuration
(whether via policy sources or using genpolusers) easily when they
update their regular users databases, then you'd see greater use of
staff_r.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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: Single home directory type for all roles.

[Daniel J Walsh]

Stephen Smalley wrote:

>On Thu, 2004-12-09 at 14:38, Daniel J Walsh wrote:
>  
>
>>Currently few people use staff, because user can do everything staff can 
>>do so you are not protected by this protection.
>>You also do not protect yourself from staff users attacking other staff 
>>users.
>>    
>>
>
>Few Fedora SELinux users use staff_r because user_canbe_sysadm is
>enabled by default in the Fedora policy.  Disable it, and they'll start
>using staff_r, because they will have to do so.  Colin has separation
>between staff_r and user_r if he has disabled that tunable, which I
>expect he has.  As for staff vs. staff, SELinux can only separate
>different security contexts; otherwise, you are relying on DAC (of
>course, SELinux does control the Linux capabilities, so your ability to
>override DAC controls can be limited by SELinux).
>
>If you disabled user_canbe_sysadm, and provided integrated user
>management so that people could update their policy users configuration
>(whether via policy sources or using genpolusers) easily when they
>update their regular users databases, then you'd see greater use of
>staff_r.
>
>  
>
Agreed, but I still have the relabeling problem.  My goal is to move 
towards the separation of user and staff though
a default disabling of user_canbe_sysadm, without having find and 
relabel all files the user might have created.



--
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: Single home directory type for all roles.

[Russell Coker]

On Thu, 2004-12-09 at 14:38 -0500, Daniel J Walsh wrote:
> If we move to this plan, we would turn off the compatability between 
> user and staff.
> So only staff users could su, usermod, newrole.  The reason they are the 
> same now is because
> of the labeling problem, and the inability to easily change from a user 
> to a staff role.  Why would
> you not have access to your old files, if you switch roles.  I agree 
> this might be good in some cases
> but can't we develop a less stringent rule that does not require relabeling.

If the aim is to have two roles with the same file access but different
access to su etc then it would be better achieved by having two roles
with the same default domain.

So you could have user:staff_user_r:staff_t and user:staff_r:staff_t and
only allow staff_su_t to be in role staff_r.


--
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: Single home directory type for all roles.

[Daniel J Walsh]

Russell Coker wrote:

>On Thu, 2004-12-09 at 14:38 -0500, Daniel J Walsh wrote:
>  
>
>>If we move to this plan, we would turn off the compatability between 
>>user and staff.
>>So only staff users could su, usermod, newrole.  The reason they are the 
>>same now is because
>>of the labeling problem, and the inability to easily change from a user 
>>to a staff role.  Why would
>>you not have access to your old files, if you switch roles.  I agree 
>>this might be good in some cases
>>but can't we develop a less stringent rule that does not require relabeling.
>>    
>>
>
>If the aim is to have two roles with the same file access but different
>access to su etc then it would be better achieved by having two roles
>with the same default domain.
>
>So you could have user:staff_user_r:staff_t and user:staff_r:staff_t and
>only allow staff_su_t to be in role staff_r.
>
>  
>
Yes that might work, and that is really my goal.  I want to prevent 
"normal users" from
running certain tools based on their role.  Basically sudo, su, 
consolehelper ...



 

--
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: Single home directory type for all roles.

[Alex Ackerman]

> On Thur, December 09, 2004 1:02 PM, Russell Coker wrote:
> > Hmm.  But the fact that in the default strict policy user_r and
staff_r
> > are nearly equivalent in terms of functionality is really a special
> > case, no?
> 
> A bug IMHO.  If we have two roles that become almost equivalent then
the
> sensible thing to do is remove one.  If we decide that for Fedora
strict
> policy we don't want to have any regular users be denied the ability
> perform administrative tasks then the correct thing to do is to make
> staff_r the default user role.
> 
> It's easy enough for anyone to add a new role if they need more roles
> than the default policy provides.

As a novice Fedora SELinux user, this sounds like a bad idea (even if it
was only hypothetical). There is currently a boolean in the strict
policy which disables the ability for normal user_r users from
transitioning to the sysadm_r, thus requiring only those users who may
have need of sysadm_r functions to be a member of staff_r. Any default
changes to this (by eliminating one role or the other) would require
users, like myself, who are not overly comfortable with developing new
user roles to regenerate a restricted user_r-type role for non-trusted
users.

As basic feedback, please do not go this route for the strict policy,
which is a nice secure default for workstation-level systems.

My $0.02,
Alex Ackerman

http://www.darkhonor.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: Single home directory type for all roles.

[Russell Coker]

On Thu, 2004-12-09 at 13:50 -0500, Alex Ackerman wrote:
> > On Thur, December 09, 2004 1:02 PM, Russell Coker wrote:
> > A bug IMHO.  If we have two roles that become almost equivalent then
> > the sensible thing to do is remove one.  If we decide that for Fedora
> > strict policy we don't want to have any regular users be denied the ability
> > perform administrative tasks then the correct thing to do is to make
> > staff_r the default user role.
> > 
> > It's easy enough for anyone to add a new role if they need more roles
> > than the default policy provides.
> 
> As a novice Fedora SELinux user, this sounds like a bad idea (even if it
> was only hypothetical). There is currently a boolean in the strict
> policy which disables the ability for normal user_r users from
> transitioning to the sysadm_r, thus requiring only those users who may
> have need of sysadm_r functions to be a member of staff_r. Any default
> changes to this (by eliminating one role or the other) would require
> users, like myself, who are not overly comfortable with developing new
> user roles to regenerate a restricted user_r-type role for non-trusted
> users.

I agree that it's not desirable to remove a role for an untrusted user
from the default install.  However that is the way things are going with
recent policy changes.  I think it's better to remove the user_r role
entirely than to make it almost the same as staff_r and give people who
are novices at reading policy the wrong idea.

Currently if you want a really restricted user_r role then you need to
change tunables.tun and comment out the definition of user_canbe_sysadm
(this requires having the policy source installed and that you are
capable of editing and compiling policy).  I believe that a better
option would be to have staff_r be the default role for all users in the
default policy and then let someone who wants to create accounts for
untrusted users assign them to user_r.  As part of that they can assign
user_u to user_r (user_u would have to default to staff_r too).

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