: patch for the usermanage module
PATCH 2/34 : patch for the usermanage module
This patch adds some needed permissions for passwd_t in policy/modules/admin/usermanage.te.
policy/modules/admin/usermanage.te +3 -2
@@ -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)
PATCH 2/34 : patch for the usermanage module
Quoted 3 lines · Guido Trentalancia
# 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
PATCH 2/34 : patch for the usermanage module
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 11 lines · Sven Vermeulen
Quoted 3 lines · Guido Trentalancia
# 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_tdomain wants to execute abin_tlabelled file? Afaik, the applications labelled withpasswd_exec_t(and thus will potentially run inpasswd_t) are passwd, vigr, vipw, chage, passwd, grpconv, pwunconv and grpunconv. Which of these is trying to execute abin_t(and which command exactly)?
Quoted 6 lines
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-----
PATCH 2/34 : patch for the usermanage module
Hello Dan, Sven and Dominick !
Thanks for your comments.
Quoted 15 lines · Daniel J Walsh
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Quoted 11 lines · Sven Vermeulen
Quoted 3 lines · Guido Trentalancia
# 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_tdomain wants to execute abin_tlabelled file? Afaik, the applications labelled withpasswd_exec_t(and thus will potentially run inpasswd_t) are passwd, vigr, vipw, chage, passwd, grpconv, pwunconv and grpunconv. Which of these is trying to execute abin_t(and which command exactly)?
Quoted 8 lines
Quoted 6 lines
Wkr,
Sven Vermeulen
_______________________________________________
refpolicy mailing list
refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicyI 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
PATCH 2/34 : patch for the usermanage module
In reply to Sven Vermeulen-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 10 lines · Sven Vermeulen
Quoted 3 lines · Guido Trentalancia
# 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_tdomain wants to execute abin_tlabelled file? Afaik, the applications labelled withpasswd_exec_t(and thus will potentially run inpasswd_t) are passwd, vigr, vipw, chage, passwd, grpconv, pwunconv and grpunconv. Which of these is trying to execute abin_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.
Quoted 6 lines
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-----