* [refpolicy] [PATCH 2/34]: patch for the usermanage module
@ 2011-02-16 6:00 Guido Trentalancia
2011-02-16 20:43 ` Sven Vermeulen
0 siblings, 1 reply; 5+ messages in thread
From: Guido Trentalancia @ 2011-02-16 6:00 UTC (permalink / raw)
To: refpolicy
This patch adds some needed permissions for passwd_t in
policy/modules/admin/usermanage.te.
--- refpolicy-git-15022011/policy/modules/admin/usermanage.te 2011-01-08 19:07:21.173730458 +0100
+++ refpolicy-git-15022011-new-modified/policy/modules/admin/usermanage.te 2011-02-15 22:46:11.980230160 +0100
@@ -273,6 +273,7 @@ allow passwd_t self:msg { send receive }
allow passwd_t crack_db_t:dir list_dir_perms;
read_files_pattern(passwd_t, crack_db_t, crack_db_t)
+kernel_read_crypto_sysctls(passwd_t)
kernel_read_kernel_sysctls(passwd_t)
# for SSP
@@ -291,8 +292,7 @@ selinux_compute_create_context(passwd_t)
selinux_compute_relabel_context(passwd_t)
selinux_compute_user_contexts(passwd_t)
-term_use_all_ttys(passwd_t)
-term_use_all_ptys(passwd_t)
+term_use_all_terms(passwd_t)
auth_domtrans_chk_passwd(passwd_t)
auth_manage_shadow(passwd_t)
@@ -302,6 +302,7 @@ auth_use_nsswitch(passwd_t)
# allow checking if a shell is executable
corecmd_check_exec_shell(passwd_t)
+corecmd_exec_bin(passwd_t)
domain_use_interactive_fds(passwd_t)
^ permalink raw reply [flat|nested] 5+ messages in thread* [refpolicy] [PATCH 2/34]: patch for the usermanage module 2011-02-16 6:00 [refpolicy] [PATCH 2/34]: patch for the usermanage module Guido Trentalancia @ 2011-02-16 20:43 ` Sven Vermeulen 2011-02-16 20:55 ` Daniel J Walsh 2011-02-16 20:55 ` Dominick Grift 0 siblings, 2 replies; 5+ messages in thread From: Sven Vermeulen @ 2011-02-16 20:43 UTC (permalink / raw) To: refpolicy On Wed, Feb 16, 2011 at 07:00:49AM +0100, Guido Trentalancia wrote: > # allow checking if a shell is executable > corecmd_check_exec_shell(passwd_t) > +corecmd_exec_bin(passwd_t) I'm curious why anything in the passwd_t domain wants to execute a bin_t labelled file? Afaik, the applications labelled with passwd_exec_t (and thus will potentially run in passwd_t) are passwd, vigr, vipw, chage, passwd, grpconv, pwunconv and grpunconv. Which of these is trying to execute a bin_t (and which command exactly)? Wkr, Sven Vermeulen ^ permalink raw reply [flat|nested] 5+ messages in thread
* [refpolicy] [PATCH 2/34]: patch for the usermanage module 2011-02-16 20:43 ` Sven Vermeulen @ 2011-02-16 20:55 ` Daniel J Walsh 2011-02-16 22:20 ` Guido Trentalancia 2011-02-16 20:55 ` Dominick Grift 1 sibling, 1 reply; 5+ messages in thread From: Daniel J Walsh @ 2011-02-16 20:55 UTC (permalink / raw) To: refpolicy -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/16/2011 03:43 PM, Sven Vermeulen wrote: > On Wed, Feb 16, 2011 at 07:00:49AM +0100, Guido Trentalancia wrote: >> # allow checking if a shell is executable >> corecmd_check_exec_shell(passwd_t) >> +corecmd_exec_bin(passwd_t) > > I'm curious why anything in the passwd_t domain wants to execute a bin_t > labelled file? Afaik, the applications labelled with passwd_exec_t (and thus > will potentially run in passwd_t) are passwd, vigr, vipw, chage, passwd, > grpconv, pwunconv and grpunconv. Which of these is trying to execute a > bin_t (and which command exactly)? > > Wkr, > Sven Vermeulen > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy I believe this is caused by a pam plugin that attempts to contact the gnome-keyring-daemon with the new passwd. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1cObsACgkQrlYvE4MpobM8FwCg6Mh2YttKGfYRHbeRvsy88tbX c7IAni8PNqkPxIa4WFnIZqTBpKm3vK7K =PPNf -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 5+ messages in thread
* [refpolicy] [PATCH 2/34]: patch for the usermanage module 2011-02-16 20:55 ` Daniel J Walsh @ 2011-02-16 22:20 ` Guido Trentalancia 0 siblings, 0 replies; 5+ messages in thread From: Guido Trentalancia @ 2011-02-16 22:20 UTC (permalink / raw) To: refpolicy Hello Dan, Sven and Dominick ! Thanks for your comments. On Wed, 16/02/2011 at 15.55 -0500, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 02/16/2011 03:43 PM, Sven Vermeulen wrote: > > On Wed, Feb 16, 2011 at 07:00:49AM +0100, Guido Trentalancia wrote: > >> # allow checking if a shell is executable > >> corecmd_check_exec_shell(passwd_t) > >> +corecmd_exec_bin(passwd_t) > > > > I'm curious why anything in the passwd_t domain wants to execute a bin_t > > labelled file? Afaik, the applications labelled with passwd_exec_t (and thus > > will potentially run in passwd_t) are passwd, vigr, vipw, chage, passwd, > > grpconv, pwunconv and grpunconv. Which of these is trying to execute a > > bin_t (and which command exactly)? > > > > Wkr, > > Sven Vermeulen > > _______________________________________________ > > refpolicy mailing list > > refpolicy at oss.tresys.com > > http://oss.tresys.com/mailman/listinfo/refpolicy > I believe this is caused by a pam plugin that attempts to contact the > gnome-keyring-daemon with the new passwd. No, it has nothing to do with gnome or any other graphical tool. Unfortunately, I am not able to reproduce it again now and I am not able to find the relative logs. There is some relatively small chance that it is just a mistake (related to a temporarily mislabeled unix_chkpwd). However, I think it is more likely just required by some licit use of the user management tools that I can't remember now. corecmd_exec_bin is being used widely in the usermanage module for all other domains, for example, at line 448-449 we have: # Execute /usr/bin/{passwd,chfn,chsh} and /usr/sbin/{useradd,vipw}. corecmd_exec_bin(useradd_t) despite none of the binaries mentioned in the comment are labeled generically bin_t. Regards, Guido ^ permalink raw reply [flat|nested] 5+ messages in thread
* [refpolicy] [PATCH 2/34]: patch for the usermanage module 2011-02-16 20:43 ` Sven Vermeulen 2011-02-16 20:55 ` Daniel J Walsh @ 2011-02-16 20:55 ` Dominick Grift 1 sibling, 0 replies; 5+ messages in thread From: Dominick Grift @ 2011-02-16 20:55 UTC (permalink / raw) To: refpolicy -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/16/2011 09:43 PM, Sven Vermeulen wrote: > On Wed, Feb 16, 2011 at 07:00:49AM +0100, Guido Trentalancia wrote: >> # allow checking if a shell is executable >> corecmd_check_exec_shell(passwd_t) >> +corecmd_exec_bin(passwd_t) > > I'm curious why anything in the passwd_t domain wants to execute a bin_t > labelled file? Afaik, the applications labelled with passwd_exec_t (and thus > will potentially run in passwd_t) are passwd, vigr, vipw, chage, passwd, > grpconv, pwunconv and grpunconv. Which of these is trying to execute a > bin_t (and which command exactly)? I am aware of atleast one bin_t app that password wants to execute in Fedora when you change your password in Gnome account information: gnome-keyring-daemon (allowing it will not make it work anyway). I would like to know as well which bin_t files password is trying to execute. I would more likely not allow this. > Wkr, > Sven Vermeulen > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1cOdoACgkQMlxVo39jgT+u3wCeO2CRH3h+Q6HWdYIcHeKCixEq 59kAn16w/YjddZyHUDcZD9/AYb+h7Dk6 =oJwE -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-02-16 22:20 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-02-16 6:00 [refpolicy] [PATCH 2/34]: patch for the usermanage module Guido Trentalancia 2011-02-16 20:43 ` Sven Vermeulen 2011-02-16 20:55 ` Daniel J Walsh 2011-02-16 22:20 ` Guido Trentalancia 2011-02-16 20:55 ` Dominick Grift
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.