Currently, applications like redhat-config-users prompt for the root password when executed by a non-root user. It would be very nice if power could be delegated more specifically, so that certain users could run certain administrative commands without knowing the root password. However, it's good to have some level of authentication -- these users should be prompted for their own passwords. (This is similar to the behavior of the sudo command.) I'd suggest that the security/console.apps/whatever files should have a new parameter where one could list groups whose members are allowed to execute the given command in this manner. ("wheel" might be a popular choice, but more specific ones could also exist.) I suppose it's probably also reasonable to allow individual users to be listed in these files, but that seems like it might be a maintenance hassle. Currently, one can manipulate the pam modules to allow members of a group to execute given commands, but there's no (obvious to me, at least) mechanism for prompting for the user's own password. I don't think this would be too hard to add, and it'd be extremely useful.
Created attachment 90653 [details] adds UGROUP to userhelper variables This is a simple attempt to introduce the requested feature. It adds a UGROUP variable to userhelper (for /etc/security/console.apps/foo files). When this is not set, behavior is exactly as before. When it is set, and when USER is unset or <user>, attempt to authenticate as invoking user for members of UGROUP, but require root password for everyone else.
(I realize that there's no way this is going in the upcoming RHL release. But I hope it or something like it will be considered for the next time around.)
Idea for alternate semantics: if UGROUP is set, any member of that group could authenticate as themselves, and people not members of that group would fall back to authenticating as USER. If USER is set to <user>, UGROUP would effectively be redundant. There should also be a <none> special value for USER, which would mean that non-UGROUP members would always just be denied. I think I like that better; I'll work on that for a next patch. It'd also be nice to allow multiple groups, of course.
Created attachment 90654 [details] better implementation of UGROUP Ok, yeah. This version does as explained above: 1) if UGROUP is not set, same behavior as always 2) if UGROUP *is* set, members of that group can authenticate as themselves regardless of USER setting. (Non-members still use USER.) 3) new <none> value for USER denies access; when used in conjunction with UGROUP, only members of the given group can authorize at all and others are given an Insufficient Rights message. Sorry for the quick succession of bugzilla spam. This version should be good for a while. :)
Created attachment 91044 [details] update for 1.67; change UGROUP to UGROUPS This version updates the patch to apply cleanly to 1.67 (minor change) and changes UGROUP to UGROUPS, in anticipation of future work to enable a list of groups. Right now, the changes are extrememly minimal: $ diffstat usermode-1.67-sudoish.patch userhelper-wrap.c | 3 ++- userhelper.c | 26 +++++++++++++++++++++++++- 2 files changed, 27 insertions(+), 2 deletions(-) And 17 of the added lines are to add a simple function to check if a given user is a member of a given group, and two of the others are comments, so it's basically an 8 line change. Changing to allow a list of groups will be be a bit more complicated, but I think useful enough to warrant it. So I'm changing the name to UGROUPS now, because we're updating all of the redhat-config- programs, and I don't want to do that twice. :)
I still think fixing Bug 81255 is a more generic solution which would allow the same result
Chris -- I can't think of a way to make the bug #81255 pam_listfile solution allow authentication-as-self, which is a key feature here. Am I missing something?
Created attachment 91488 [details] "feature complete" version allows multiple UGROUPS Okay, I stopped being a slacker and added the code necessary to allow UGROUPS to be a comma-separated list of groups. (With whitespace trimmed, too.) I'm not really happy with "UGROUPS" as the variable name -- it's not descriptive enough. AUTHASUSERGROUPS seems a bit too long, and AAUGROUPS is just adding vowels to the beginning without really adding extra information. :) Suggestions welcome.
Patch works unchanged on 1.68 from rawhide.
Created attachment 97199 [details] updated for 1.69-3 Updated patch for package in fedora devel tree. Tested and works rebuilt on RHL 9. The patch doesn't touch any of the SELinux stuff; not sure if it needs to or how that would/should interact.
Continuing conversation with myself.... Patch applies cleanly to 1.69-4; haven't tested extensively. I'll do that when Fedora Core 2 is released. Still looking for suggestions for a better term than "UGROUPS".
Created attachment 99080 [details] patch to userhelper man page Adds documentation for UGROUPS and USER=<none> features to the man page for userhelper.
Patch applies cleanly to 1.69-5 as well. I'm still not sure about how all this will integrate with SE Linux -- I posted to the fedora-selinux mailing list, but haven't gotten any feedback yet.
patch applies cleanly to 1.70-2.
Any chance of getting this in before the test3 devel freeze? It's very nice. And it's change with minimal impact if not enabled explicitly (by editing the console.apps files).
Please consider for Fedora Core 3. Thanks.
Looks sensible but doesn't apply to CVS head btw
Created attachment 101780 [details] updated for 1.70-6 Looks like 'ruid_user' changed to 'invoking_user'. This version works with 1.70-6 in rawhide, and I assume CVS.
PS: the changelog for usermode says: * Tue Jul 1 2004 Dan Walsh <dwalsh> 1.70-5 - Fix to use root if user not defined but my patch is touching the part of the code where that selection seems like it would logically be made (so when I read the changes, I thought that might be the conflict) but it is unchanged -- in get_user_for_auth() in userhelper.c: [...] configured_user = svGetValue(s, "USER"); if (configured_user == NULL) { ret = invoking_user; } else [...] so if USER isn't defined, it seems like it would still default to <user>. (And in fact, on testing, it that's what it does.)
Putting on target tracking bug, since I think we should target at least commenting on this patch.
Note -- patch for 1.70-6 applies fine to 1.73-1 in rawhide, but I haven't tested it thouroughly yet.
Hi Mathew, thank you for the patch and for talking for such a long time with yourself here. I like the idea behind the patch that the users needed to authenticate will not be prompted for the root but their own password. In that manner I think that the solution presented here seems better to me that in Bug 81255 presented by Chris. Dan, is there something wrong with the patch from the SELinux point of view?
This looks ok to me. We pulled most of the special USERNAME handling out of userhelper, and only left the transition stuff in it. We had the machine prompting for Username a while back but changed it back for targeted policy reasons. I suspect this is opening potential security holes though. One being that if you are using NISGroups you could be fooled into allowing access with user password, secondly if I only allow say system-config-printer to have this functionality, pam_timestamp will still allow the users to startup other apps for the X Minutes that it is in effect. Dan
Ok after talking to Nalin, he told me that pam_stimestamp will not be a problem since it records if you logged in using your password or roots. The second problem also exists for sudo, so I guess we open no more of a security hole than already exists. Dan
The patches are now applied to usermode upstream CVS. Mathew, thanks for them!
*** Bug 81255 has been marked as a duplicate of this bug. ***
Cool, thanks!
Hello, Re-opening this bug as discussed in: https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01903.html Currently users need to be added to wheel post-install. Can this be done through choice or by default during install as I find this feature very useful. Can it be implemented for Fedora 8?
This bug should be left closed -- it's about getting the infrastructure in place. Implementing a configuration based on a given policy should get its own new bug. Thanks.