Security Enhanced Linux
What's New
Frequently Asked Questions
Background
Documents
License
Download
Participating
Mail List
Archives
Remaining Work
Contributors
Related Work
Press Releases
Information Assurance Research
NIARL In-house Research Areas
Mathematical Sciences Program
Sabbaticals
Computer & Information Sciences Research
Technology Transfer
Advanced Computing
Advanced Mathematics
Communications & Networking
Information Processing
Microelectronics
Other Technologies
Technology Fact Sheets
Publications
Related Links
|
SELinux Mailing List
subject: patch: add can_create() macro, allow file_type_auto_trans(a,b,c, { file dir }) Date: Tue, 7 Dec 2004 01:08:05 +0100
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 ABE7From: James Carter <jwcart2_at_epoch.ncsc.mil> subject: Re: patch: add can_create() macro, allow file_type_auto_trans(a,b,c, { file dir }) Date: Wed, 08 Dec 2004 14:32:29 -0500
On Mon, 2004-12-06 at 19:08, Thomas Bleher wrote:
-- 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.From: Daniel J Walsh <dwalsh_at_redhat.com> subject: Some more fixes Date: Thu, 09 Dec 2004 11:31:25 -0500
Fixes for ipsec Fixes for ifdefs of targeted policy Added new booleans to replace tunables allow_user_mysql_connect & allow_user_postgresql_connect & pppd_for_user Fixed some can_network_* calls. Added support for winbindd Added a portmap_helper domain for pmap_dump and pmap_set. Not sure if I like this? Looking for comments. Remove user_can_mount tunable
-- 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.From: Thomas Bleher <bleher_at_informatik.uni-muenchen.de> subject: Re: Some more fixes Date: Thu, 9 Dec 2004 19:35:39 +0100
This needs an ifdef(`unconfined.te' around it.
> diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/unused/kudzu.te policy-1.19.12/domains/program/unused/kudzu.te I just sent in a patch to remove this, because on line 54, there's already rw_dir_create_file(kudzu_t, etc_t)
> diff --exclude-from=exclude -N -u -r nsapolicy/macros/user_macros.te policy-1.19.12/macros/user_macros.te I don't think this should be removed. No idea how Fedora handles this but at least on my system I still need it because I neither use udev nor hal. As it's already in a tunable, I think you can just disable this tunable on Fedora.
> Ahh, this was just fixed in a patch from me. Should be left as it is. Thomas -- http://www.cip.ifi.lmu.de/~bleher/selinux/ - my SELinux pages GPG-Fingerprint: BC4F BB16 30D6 F253 E3EA D09E C562 2BAE B2F4 ABE7From: James Carter <jwcart2_at_epoch.ncsc.mil> subject: Re: Some more fixes Date: Fri, 10 Dec 2004 15:14:05 -0500
On Thu, 2004-12-09 at 11:31, Daniel J Walsh wrote:
I put an ifdef(`distro_redhat' around this.
> diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/ldconfig.te policy-1.19.12/domains/program/ldconfig.te As Thomas Bleher mentioned, I put a ifdef(`unconfined.te' around this.
> diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/unused/kudzu.te policy-1.19.12/domains/program/unused/kudzu.te As Thomas Bleher mentioned, this rule is redudant.
> diff --exclude-from=exclude -N -u -r nsapolicy/macros/user_macros.te policy-1.19.12/macros/user_macros.te I didn't remove this, since there still seems to be interest in it. Perhaps it should be moved to a distro_tunable?
> diff --exclude-from=exclude -N -u -r nsapolicy/tunables/tunable.tun policy-1.19.12/tunables/tunable.tun I did not remove the user_can_mount tunable. I did not add the single_user_file_type tunable. -- James Carter <jwcart2@epoch.ncsc.mil> National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Daniel J Walsh <dwalsh_at_redhat.com> subject: Single home directory type for all roles. Date: Thu, 09 Dec 2004 11:50:53 -0500
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.
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
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@@ -573,3 +573,19 @@ ')
')dnl end unconfined_domain
--- policy-1.19.12/macros/program/fingerd_macros.te 2004-12-09 11:01:28.000000000 -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@@ -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@@ -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', `
--- policy-1.19.12/macros/program/mount_macros.te 2004-12-09 11:01:28.000000000 -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@@ -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@@ -80,7 +80,7 @@ dontaudit $1_spamassassin_t { sysctl_t sysctl_kernel_t }:dir search;
# The type of ~/.spamassassin
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@@ -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', `
--- policy-1.19.12/macros/program/tvtime_macros.te 2004-12-09 11:01:28.000000000 -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@@ -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@@ -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;
# The user file type for the VMWare configuration files
-type $1_vmware_conf_t, $1_file_type, file_type, sysadmfile;
# 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@@ -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@@ -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, `
--- policy-1.19.12/macros/user_macros.te 2004-12-09 11:22:43.634730157 -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', `
-- 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.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Single home directory type for all roles. Date: Thu, 09 Dec 2004 12:20:28 -0500
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 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 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 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 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.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Single home directory type for all roles. Date: Thu, 09 Dec 2004 12:40:49 -0500
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.From: Daniel J Walsh <dwalsh_at_redhat.com> subject: Manipulating user roles without policy-sources installed Date: Fri, 10 Dec 2004 11:23:06 -0500
I want to change genpolusers syntax to be genpolusers inpolicy outpolicy userfile1 [userfile2 ... ] So if I add a user to /etc/selinux/strict/users/local.users I execute genpolusers /etc/selinux/strict/policy/policy.18/etc/selinux/strict/users/local.users mv -f /etc/selinux/strict/policy/policy.18.new /etc/selinux/strict/policy/policy.18 load_policy /etc/selinux/strict/policy/policy.18
Tools like useradd and system-config-users can start to manipulate
-- 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.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Manipulating user roles without policy-sources installed Date: Fri, 10 Dec 2004 11:37:15 -0500
Yes, that's easy enough to do, and as no one has used genpolusers to date AFAIK, changing the interface is ok with me. > diff --exclude-from=exclude -N -u -r nsapolicy/local.users policy-1.19.12/local.users > --- nsapolicy/local.users 1969-12-31 19:00:00.000000000 -0500 > +++ policy-1.19.12/local.users 2004-12-10 10:59:20.750916770 -0500 > +# or if you want to be able to directly start daemons > + > +#user jadmin roles { staff_r sysadm_r system_r }; Rather than just have this as a comment in the file, why not use an ifdef in the source file here and apply m4 to it as well so that there is a single line in the installed file that either includes system_r or does not based on what tunables were set when the policy was built? Reduces user confusion, particularly since you are always enabling direct_sysadm_daemon for FC and it is also needed for rpm %post scriptlet processing in a number of cases.
> diff --exclude-from=exclude -N -u -r nsapolicy/Makefile policy-1.19.12/Makefile The comment says "users.custom", but you've named it "local.users". I'm also unclear on the purpose of the grep's - just to make it more readable? If you just want the user statement, you could just grep for lines beginning with user unless you are worried about multi-line user statements in the base policy (which is allowed by checkpolicy, since it uses a semicolon terminator). -- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Daniel J Walsh <dwalsh_at_redhat.com> subject: Re: Manipulating user roles without policy-sources installed Date: Fri, 10 Dec 2004 13:09:24 -0500
>On Fri, 2004-12-10 at 11:23, Daniel J Walsh wrote:
>>diff --exclude-from=exclude -N -u -r nsapolicy/Makefile policy-1.19.12/Makefile
>I'm also unclear on the purpose of the grep's - just to make it more
>If you just want the user statement, you could just grep for 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.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Manipulating user roles without policy-sources installed Date: Fri, 10 Dec 2004 13:38:26 -0500
Patch below should do it. Index: checkpolicy/genpolusers.c RCS file: /nfshome/pal/CVS/selinux-usr/checkpolicy/genpolusers.c,v retrieving revision 1.5 diff -u -r1.5 genpolusers.c --- checkpolicy/genpolusers.c 11 Aug 2004 14:03:19 -0000 1.5 +++ checkpolicy/genpolusers.c 10 Dec 2004 18:31:49 -0000@@ -1,8 +1,8 @@ /* - * genpolusers old-policy new-users new-policy + * genpolusers inpolicy outpolicy users1 [users2 ... ] * - * Given an existing binary policy configuration and a new source users - * configuration (post-processed), generate a new binary policy + * Given an existing binary policy configuration and a set of source users + * configurations (post-processed), generate a new binary policy * configuration that is identical to the old one except that it has * the new user declarations. User declarations from the old binary * policy are replaced if they also exist in the new source users@@ -39,7 +39,7 @@
void usage(char *progname)
- printf("usage: %s old-policy new-users new-policy\n", progname); + printf("usage: %s inpolicy outpolicy users1 [users2 ...]\n", progname); exit(1); } @@ -111,10 +111,10 @@ struct policy_file pf; struct stat sb; FILE *outfp; - int fd, rc; + int fd, rc, i; void *map; - if (argc != 4) + if (argc < 4) usage(argv[0]); fd = open(argv[1], O_RDONLY); @@ -148,12 +148,6 @@ for the new policy. */ sepol_set_policyvers(policydb.policyvers); - yyin = fopen(argv[2], "r"); - if (!yyin) { - fprintf(stderr, "%s: unable to open %s\n", argv[0], - argv[2]); - exit(1); - } id_queue = queue_create(); if (!id_queue) { fprintf(stderr, "%s: out of memory\n", argv[0]); @@ -161,21 +155,28 @@ } policydbp = &policydb; policydb_errors = 0; - if (yyparse() || policydb_errors) { - fprintf(stderr, "%s: error(s) encountered while parsing configuration\n", argv[0]); - exit(1); + + for (i = 3; i < argc; i++) { + yyin = fopen(argv[i], "r"); + if (!yyin) { + fprintf(stderr, "%s: unable to open %s\n", argv[0], + argv[i]); + exit(1); + } + + if (yyparse() || policydb_errors) { + fprintf(stderr, "%s: error(s) encountered while parsing configuration %s\n", argv[0], argv[i]); + exit(1); + } } queue_destroy(id_queue); - if (policydb_errors) - exit(1); - hashtab_map_remove_on_error(policydb.p_users.table, select_user, kill_user, &policydb); hashtab_map(policydb.p_users.table, remap_users, &policydb); - outfp = fopen(argv[3], "w"); + outfp = fopen(argv[2], "w"); if (!outfp) { - perror(argv[3]); + perror(argv[2]); exit(1); } pf.type = PF_USE_STDIO; @@ -183,7 +184,7 @@ rc = policydb_write(&policydb, &pf); if (rc) { fprintf(stderr, "%s: error writing %s\n", - argv[0], argv[3]); + argv[0], argv[2]); exit(1); } fclose(outfp); -- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Russell Coker <rcoker_at_redhat.com> subject: Re: Single home directory type for all roles. Date: Fri, 10 Dec 2004 04:47:24 +1100
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 Or just have them in the same role.
> users from both roles can create and modify content under that shared 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 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.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Single home directory type for all roles. Date: Thu, 09 Dec 2004 12:53:26 -0500
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 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.From: Russell Coker <rcoker_at_redhat.com> subject: Re: Single home directory type for all roles. Date: Fri, 10 Dec 2004 05:12:31 +1100
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 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.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Single home directory type for all roles. Date: Thu, 09 Dec 2004 13:18:39 -0500
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?
> The solution then would be to have a separate domain for the Seems painful.
> Can we break the tradition of having only /home/$USER in this regard? 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.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Single home directory type for all roles. Date: Thu, 09 Dec 2004 13:45:56 -0500
(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 AgencyFrom: Russell Coker <rcoker_at_redhat.com> subject: Re: Single home directory type for all roles. Date: Fri, 10 Dec 2004 06:08:37 +1100
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 Fixing the policy should be easy enough.
> > The solution then would be to have a separate domain for the 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? 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.From: Casey Schaufler <casey_at_schaufler-ca.com> subject: Re: Single home directory type for all roles. Date: Thu, 9 Dec 2004 12:03:00 -0800 (PST)
> The problem with such a change is that it interferes 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
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.From: Russell Coker <rcoker_at_redhat.com> subject: Re: Single home directory type for all roles. Date: Fri, 10 Dec 2004 23:20:26 +1100
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 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.From: Valdis.Kletnieks_at_vt.edu subject: Re: Single home directory type for all roles. Date: Fri, 10 Dec 2004 10:22:33 -0500
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.
-- 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.From: Casey Schaufler <casey_at_schaufler-ca.com> subject: Re: Single home directory type for all roles. Date: Fri, 10 Dec 2004 08:19:39 -0800 (PST)
> On Fri, 10 Dec 2004 23:20:26 +1100, Russell Coker 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 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 You have to go to the costs-extra multilevel secure versions.
> So I have no idea what Casey's talking about. There 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
/* * * 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;
/* * 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
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
int error; VOP_ATTR_SET(vp, SGI_MAC_FILE, (char *)mlp, mac_size(mlp), ATTR_ROOT, sys_cred, error); return error; }
mac_label *
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
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_enabled = 1; cap_enabled = CAP_SYS_NO_SUPERUSER; }
int
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_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
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_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); } -- 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.From: Valdis.Kletnieks_at_vt.edu subject: Re: Single home directory type for all roles. Date: Fri, 10 Dec 2004 12:00:06 -0500
> > Or if 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 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...
-- 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.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Single home directory type for all roles. Date: Fri, 10 Dec 2004 12:06:23 -0500
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:
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.From: Casey Schaufler <casey_at_schaufler-ca.com> subject: Re: Single home directory type for all roles. Date: Fri, 10 Dec 2004 09:29:42 -0800 (PST)
> On Fri, 10 Dec 2004 08:19:39 PST, Casey Schaufler 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 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 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 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
> > Trusted Solaris, Trusted Irix, SystemV/MLS, UNICOS 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.From: Valdis.Kletnieks_at_vt.edu subject: Re: Single home directory type for all roles. Date: Thu, 09 Dec 2004 15:40:47 -0500
> The solution then would be to have a separate domain for the 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....
-- 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.From: Russell Coker <rcoker_at_redhat.com> subject: Re: Single home directory type for all roles. Date: Fri, 10 Dec 2004 14:03:35 +1100
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.From: Daniel J Walsh <dwalsh_at_redhat.com> subject: Re: Single home directory type for all roles. Date: Fri, 10 Dec 2004 09:09:33 -0500
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.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Single home directory type for all roles. Date: Fri, 10 Dec 2004 09:31:22 -0500
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.From: Colin Walters <walters_at_redhat.com> subject: Re: Single home directory type for all roles. Date: Fri, 10 Dec 2004 10:43:57 -0500
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.From: Casey Schaufler <casey_at_schaufler-ca.com> subject: Re: Single home directory type for all roles. Date: Fri, 10 Dec 2004 08:33:57 -0800 (PST)
> Ok I succumb. I will not fight the battle any 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.From: Russell Coker <rcoker_at_redhat.com> subject: Re: Single home directory type for all roles. Date: Tue, 14 Dec 2004 00:25:41 +1100
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 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.From: Daniel J Walsh <dwalsh_at_redhat.com> subject: Re: Single home directory type for all roles. Date: Mon, 13 Dec 2004 08:56:57 -0500
>On Fri, 2004-12-10 at 09:09 -0500, Daniel J Walsh wrote: -- 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.From: Russell Coker <rcoker_at_redhat.com> subject: Re: Single home directory type for all roles. Date: Tue, 14 Dec 2004 01:19:00 +1100
Same here.
> My opinion, is the 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.From: Thomas Bleher <bleher_at_informatik.uni-muenchen.de> subject: Re: Single home directory type for all roles. Date: Thu, 9 Dec 2004 20:07:02 +0100
A while ago we had this discussion on the lsm-list. Colin suggested using the following patch to prevent symlinks attacks:
+# 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 ABE7From: Russell Coker <rcoker_at_redhat.com> subject: Re: Single home directory type for all roles. Date: Fri, 10 Dec 2004 06:19:11 +1100
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.From: Colin Walters <walters_at_redhat.com> subject: Re: Single home directory type for all roles. Date: Thu, 09 Dec 2004 12:28:18 -0500
> 1. Causes problems with sharing files between users, IE a staff user 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 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 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 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 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.From: Russell Coker <rcoker_at_redhat.com> subject: Re: Single home directory type for all roles. Date: Fri, 10 Dec 2004 05:02:24 +1100
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 I agree.
> Hmm. But the fact that in the default strict policy user_r and staff_r 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 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 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.From: Daniel J Walsh <dwalsh_at_redhat.com> subject: Re: Single home directory type for all roles. Date: Thu, 09 Dec 2004 14:45:45 -0500
>On Thu, 2004-12-09 at 12:28 -0500, Colin Walters wrote: 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.
>
>>Hmm. But the fact that in the default strict policy user_r and staff_r
>It's easy enough for anyone to add a new role if they need more roles
>> I imagine most people really using RBAC will be defining -- 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.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Single home directory type for all roles. Date: Thu, 09 Dec 2004 15:07:35 -0500
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 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.From: Russell Coker <rcoker_at_redhat.com> subject: Re: Single home directory type for all roles. Date: Fri, 10 Dec 2004 07:13:15 +1100
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 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 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.From: Daniel J Walsh <dwalsh_at_redhat.com> subject: Re: Single home directory type for all roles. Date: Thu, 09 Dec 2004 15:22:33 -0500
>On Thu, 2004-12-09 at 14:45 -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.
>
>> Currently if I want to add a new -- 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.From: Russell Coker <rcoker_at_redhat.com> subject: Re: Single home directory type for all roles. Date: Fri, 10 Dec 2004 07:30:17 +1100
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.From: Thomas Bleher <bleher_at_informatik.uni-muenchen.de> subject: Re: Single home directory type for all roles. Date: Thu, 9 Dec 2004 22:38:46 +0100
Then they'll have to relabel the users home dir, delete /tmp and logout
the user. That's life.
> Roles can be used to govern which applications can be run. So I could 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 ABE7From: Russell Coker <rcoker_at_redhat.com> subject: Re: Single home directory type for all roles. Date: Fri, 10 Dec 2004 13:56:08 +1100
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.From: Colin Walters <walters_at_redhat.com> subject: Re: Single home directory type for all roles. Date: Thu, 09 Dec 2004 17:29:55 -0500
> BTW I like the idea of defaulting to staff_r. I think we should do that 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.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Single home directory type for all roles. Date: Fri, 10 Dec 2004 08:11:50 -0500
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.From: Colin Walters <walters_at_redhat.com> subject: Re: Single home directory type for all roles. Date: Fri, 10 Dec 2004 11:28:04 -0500
Ok, that makes sense.
> Also, if you have everyone default to staff_r, including user_u, then if 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.From: Thomas Bleher <bleher_at_informatik.uni-muenchen.de> subject: Re: Single home directory type for all roles. Date: Thu, 9 Dec 2004 22:16:19 +0100
Agreed.
> I am trying to strengthen the difference between them without having to 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
# 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 ABE7From: Russell Coker <rcoker_at_redhat.com> subject: Re: Single home directory type for all roles. Date: Fri, 10 Dec 2004 13:58:26 +1100
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.From: Colin Walters <walters_at_redhat.com> subject: Re: Single home directory type for all roles. Date: Thu, 09 Dec 2004 17:43:42 -0500
> Currently the default policy has /root labeled as staff_home_dir_t. 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 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 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.From: Russell Coker <rcoker_at_redhat.com> subject: Re: Single home directory type for all roles. Date: Fri, 10 Dec 2004 13:23:34 +1100
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.From: Colin Walters <walters_at_redhat.com> subject: Re: Single home directory type for all roles. Date: Fri, 10 Dec 2004 10:48:02 -0500
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 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.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: Single home directory type for all roles. Date: Fri, 10 Dec 2004 21:58:35 +0000
> If you want this, then why not just make your normal account user_r, and 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.From: Daniel J Walsh <dwalsh_at_redhat.com> subject: Re: Single home directory type for all roles. Date: Thu, 09 Dec 2004 14:38:39 -0500
>On Thu, 2004-12-09 at 11:50 -0500, Daniel J Walsh wrote:
>>2. Requirement that selinux-policy-strict-sources be installed and a
>
>>So yesterday I went though the policy and created a new tunable -- 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.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Single home directory type for all roles. Date: Thu, 09 Dec 2004 14:58:40 -0500
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.From: Daniel J Walsh <dwalsh_at_redhat.com> subject: Re: Single home directory type for all roles. Date: Thu, 09 Dec 2004 15:09:01 -0500
>On Thu, 2004-12-09 at 14:38, Daniel J Walsh wrote: -- 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.From: Russell Coker <rcoker_at_redhat.com> subject: Re: Single home directory type for all roles. Date: Fri, 10 Dec 2004 07:17:49 +1100
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.From: Daniel J Walsh <dwalsh_at_redhat.com> subject: Re: Single home directory type for all roles. Date: Thu, 09 Dec 2004 15:38:27 -0500
>On Thu, 2004-12-09 at 14:38 -0500, Daniel J Walsh wrote: -- 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.From: Alex Ackerman <alex_at_darkhonor.com> subject: RE: Single home directory type for all roles. Date: Thu, 9 Dec 2004 13:50:16 -0500
> On Thur, December 09, 2004 1:02 PM, Russell Coker wrote: 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,
-- 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.From: Russell Coker <rcoker_at_redhat.com> subject: RE: Single home directory type for all roles. Date: Fri, 10 Dec 2004 06:29:50 +1100
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.
|
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |