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