RE: Single home directory type for all roles.

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.

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.

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.

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.