[refpolicy] [PATCH 2/34]: patch for the usermanage module

[guido@trentalancia.com (Guido Trentalancia)]

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