Hello all,
I have unsucessfully been attempting to find out through both documentation, testing, and internet sources if I can get consolehelper to act more like sudo rather than su. Right now my problem is that there is NO WAY to roll this out to more users as a desktop alternative without giving them some power user ability ( printers, date and time, removable storage managment, ... ). Right now in order to give them access to these applications AFAICT I must either give the users the root password ( not gonna happen ) or create a pam.d file so that there is no password prompt ( pam_wheel with trust option ). Neither of these is a truly acceptable option at this point.
Any change should try to keep the system as close to baseline as possible, I would prefer not to rip out the consolehelper system, but I will if I have to. The featureset I want is identical to sudo, but I will make accomidations as long as I can allow users to run a specific command after prompting for the users password.
If anyone can point me in the right direction or just tell me that it's impossible with the current system that would be a great help.
Cheers, Eric Warnke Systems Administer, Research ITS SUNY at Albany
On Wed, 2005-03-02 at 10:08 -0500, Eric Warnke wrote:
Hello all,
I have unsucessfully been attempting to find out through both documentation, testing, and internet sources if I can get consolehelper to act more like sudo rather than su. Right now my problem is that there is NO WAY to roll this out to more users as a desktop alternative without giving them some power user ability ( printers, date and time, removable storage managment, ... ). Right now in order to give them access to these applications AFAICT I must either give the users the root password ( not gonna happen ) or create a pam.d file so that there is no password prompt ( pam_wheel with trust option ). Neither of these is a truly acceptable option at this point.
Any change should try to keep the system as close to baseline as possible, I would prefer not to rip out the consolehelper system, but I will if I have to. The featureset I want is identical to sudo, but I will make accomidations as long as I can allow users to run a specific command after prompting for the users password.
You can probably just set things up with sudo... I'm not sure how involved that is.
I do think consolehelper knows how to require user password instead of root password though. You may have more luck finding help with this on fedora-list or IRC than on this list. I'm not sure of the syntax myself but I'm pretty sure you want to edit the /etc/pam.d files.
All this "end user desktop" stuff that requires root I consider a bug btw, if you want to file a bugzilla for the individual items that would be helpful. If you get NOTABUG/WONTFIX from someone at Red Hat let me know and I'll tell them they are wrong.
Havoc
On Thu, Mar 03, 2005 at 02:34:51PM -0500, Havoc Pennington wrote:
All this "end user desktop" stuff that requires root I consider a bug btw, if you want to file a bugzilla for the individual items that would be helpful. If you get NOTABUG/WONTFIX from someone at Red Hat let me know and I'll tell them they are wrong.
I wouldn't want just anyone to have the ability to run many of the system-config apps just because they're sitting at the console, though. What do you think about making the UGROUPS=wheel thing the default? (Or some other group like "admin"....)
We also patch system-config-users to have an easy checkbox for wheel group membership and to display that in a column on the Users tab (right after Primary Group).
On Thu, 2005-03-03 at 15:02 -0500, Matthew Miller wrote:
On Thu, Mar 03, 2005 at 02:34:51PM -0500, Havoc Pennington wrote:
All this "end user desktop" stuff that requires root I consider a bug btw, if you want to file a bugzilla for the individual items that would be helpful. If you get NOTABUG/WONTFIX from someone at Red Hat let me know and I'll tell them they are wrong.
I wouldn't want just anyone to have the ability to run many of the system-config apps just because they're sitting at the console, though. What do you think about making the UGROUPS=wheel thing the default? (Or some other group like "admin"....)
I don't think many of the system-config apps are "end user desktop" stuff at all. What needs to be fixed [1] though is at least printing, sound, display, software installation, date/time and network. Right now, in the default install, this requires the root password. I think that was the bug Havoc talked about.
David
[1] : here fixed can also mean replaced with something that more, uhm, suitable for desktop use - look at NetworkManager for an example
On Thu, Mar 03, 2005 at 03:31:13PM -0500, David Zeuthen wrote:
I don't think many of the system-config apps are "end user desktop" stuff at all. What needs to be fixed [1] though is at least printing, sound, display, software installation, date/time and network. Right now, in the default install, this requires the root password. I think that was the bug Havoc talked about.
I don't consider date/time to be "end user". That should be managed through ntp, which shouldn't be just tweaked at the whim of whoever sits down at the box. (Setting the *user's* timezone is a different issue.)
Display, sound, and local printing should Just Work, and network where possible. I'll not touch the details of printer configuration right now. :)
Software installation *definitely* needs some sort of authentication and special privilege. Sure, this needs to be made so it's not intimidating, but we also shouldn't shoot ourselves in the head.
On Thu, 2005-03-03 at 16:01 -0500, Matthew Miller wrote:
On Thu, Mar 03, 2005 at 03:31:13PM -0500, David Zeuthen wrote:
I don't think many of the system-config apps are "end user desktop" stuff at all. What needs to be fixed [1] though is at least printing, sound, display, software installation, date/time and network. Right now, in the default install, this requires the root password. I think that was the bug Havoc talked about.
I don't consider date/time to be "end user". That should be managed through ntp, which shouldn't be just tweaked at the whim of whoever sits down at the box. (Setting the *user's* timezone is a different issue.)
Probably depends on the deployment or situation. The additional point about all this "be sure end users can do desktop stuff without root" is that we should have some kind of easy way to enable/disable their ability to do particular things.
Display, sound, and local printing should Just Work, and network where possible. I'll not touch the details of printer configuration right now. :)
Software installation *definitely* needs some sort of authentication and special privilege. Sure, this needs to be made so it's not intimidating, but we also shouldn't shoot ourselves in the head.
For a managed client (with IT staff) then normally the IT dept will own all software installation, but for a home desktop the end user should be able to do it.
The trick is to enable that without allowing an app running as the user to do it, in order to preserve safety vs. viruses etc. There was a thread about this a while back. One approach is that if you aren't root, you can only install signed packages; and you have to be root to add new trusted keys. The "setuid" process would be simple and just check the signature, then invoke the full installer.
I think software installation without root is less important than the other stuff for now, since we have a ton of other problems in a "home nontechnical user" environment anyhow. And software installation by users isn't useful in an organization with IT staff.
Though I guess I *can* imagine a setup where users can install any software that is signed by the particular IT department, that could be useful. Probably not "best practice" but conceivably useful.
Havoc
On Thu, 2005-03-03 at 16:01 -0500, Matthew Miller wrote:
I don't consider date/time to be "end user". That should be managed through ntp, which shouldn't be just tweaked at the whim of whoever sits down at the box. (Setting the *user's* timezone is a different issue.)
You need to be able to change timezone when traveling. User may also not be on a network so you cannot rely on a NTP server.
Display, sound, and local printing should Just Work, and network where possible. I'll not touch the details of printer configuration right now. :)
Heh :-)
Software installation *definitely* needs some sort of authentication and special privilege. Sure, this needs to be made so it's not intimidating, but we also shouldn't shoot ourselves in the head.
I knew this would come up :-)
o Why should installing updates and software that is *signed* by a key that the admin chooses to trust require root?
o IIRC you can already install "software" as a non-privileged user for e.g. Firefox - my point is that there is more to installing software than just RPM
In all cases we of course need to guard against viruses and malware so only certain trusted programs are allowed to do these actions. SELinux and D-BUS can help here, e.g. we might use a SE-Linux label for system-config-packages (and make sure LD_PRELOAD exploits are not possible) that allows interaction with a root process via D-BUS that performs the installation.
David
On Thu, Mar 03, 2005 at 04:19:52PM -0500, David Zeuthen wrote:
I don't consider date/time to be "end user". That should be managed through ntp, which shouldn't be just tweaked at the whim of whoever sits down at the box. (Setting the *user's* timezone is a different issue.)
You need to be able to change timezone when traveling. User may also not be on a network so you cannot rely on a NTP server.
You shouldn't have to change the *system* timezone, though.
$ echo $TZ America/New_York $ date Thu Mar 3 16:34:40 EST 2005 $ export TZ=Japan $ date Fri Mar 4 06:35:17 JST 2005
Personally, I think the system timezone should *always* be GMT, and local time always set per-user. (There could be a system default TZ, of course.) But that's a different discussion. :)
o Why should installing updates and software that is *signed* by a key that the admin chooses to trust require root?
Because it could affect other users in unpredictable ways.
o IIRC you can already install "software" as a non-privileged user for e.g. Firefox - my point is that there is more to installing software than just RPM
Right -- that's okay, because privilege separation reduces the possible impact on others.
On Thu, 2005-03-03 at 16:41 -0500, Matthew Miller wrote:
o Why should installing updates and software that is *signed* by a key that the admin chooses to trust require root?
Because it could affect other users in unpredictable ways.
Not on a single-user laptop. There has to be local site policy at some point to get things right.
Havoc
On Thu, 03 Mar 2005 16:01:17 -0500, Matthew Miller wrote:
Software installation *definitely* needs some sort of authentication and special privilege. Sure, this needs to be made so it's not intimidating, but we also shouldn't shoot ourselves in the head.
You're thinking like an admin - yes for managed networks users probably should not be able to install whatever they like but bear in mind anybody can stick software in $HOME if they really want to, even if it's mounted no-exec. So I think what you really want to avoid is unpredictable system reconfiguration/change rather than software installation per-se.
And yes for home/personal systems clearly any root/sudo prompts at all are silly, the user should never be prompted for a password once they have logged in - not even for software installation.
thanks -mike
man, 21.03.2005 kl. 16.29 skrev Mike Hearn:
On Thu, 03 Mar 2005 16:01:17 -0500, Matthew Miller wrote:
Software installation *definitely* needs some sort of authentication and special privilege. Sure, this needs to be made so it's not intimidating, but we also shouldn't shoot ourselves in the head.
You're thinking like an admin - yes for managed networks users probably should not be able to install whatever they like but bear in mind anybody can stick software in $HOME if they really want to, even if it's mounted no-exec. So I think what you really want to avoid is unpredictable system reconfiguration/change rather than software installation per-se.
And yes for home/personal systems clearly any root/sudo prompts at all are silly, the user should never be prompted for a password once they have logged in - not even for software installation.
I disagree - the pasword promt is a good indication of "you are now doing something that will (permanently) change your system configuration". And the gtk pasword dialog (gtksu?) also tells which program asked for root acess.
On Thu, 2005-03-03 at 15:02 -0500, Matthew Miller wrote:
On Thu, Mar 03, 2005 at 02:34:51PM -0500, Havoc Pennington wrote:
All this "end user desktop" stuff that requires root I consider a bug btw, if you want to file a bugzilla for the individual items that would be helpful. If you get NOTABUG/WONTFIX from someone at Red Hat let me know and I'll tell them they are wrong.
I wouldn't want just anyone to have the ability to run many of the system-config apps just because they're sitting at the console, though. What do you think about making the UGROUPS=wheel thing the default? (Or some other group like "admin"....)
We also patch system-config-users to have an easy checkbox for wheel group membership and to display that in a column on the Users tab (right after Primary Group).
As David says, sometimes this is sort of complicated. e.g. for NetworkManager we changed the architecture to be asking for certain things from the user session, vs. writing out an arbitrary config file.
He's also right that some of the system-config-* aren't desktop oriented at all (or they at least include a bunch of non-desktop stuff in addition)
So the fix may not be as simple as changing the pam setup, but it's still broken right now.
One problem is that if you can run a GTK app as root (anything equivalent to setgid) then you can probably hack that app and do bad stuff, http://gtk.org/setuid.html
So it's probably a requirement in all cases that we split out a backend that runs as root and have the UI separate.
Havoc
Thanks everyone, the UGROUPS worked, not the way I would like, but it worked. Is there any more documentation for these config files?
I would suggest that the lack of ANY decent installed documentation ( man pages /usr/share/doc/ ) on either consolehelper or usermode be consitered a bug.
Cheers, Eric
Havoc Pennington wrote:
As David says, sometimes this is sort of complicated. e.g. for NetworkManager we changed the architecture to be asking for certain things from the user session, vs. writing out an arbitrary config file.
He's also right that some of the system-config-* aren't desktop oriented at all (or they at least include a bunch of non-desktop stuff in addition)
So the fix may not be as simple as changing the pam setup, but it's still broken right now.
One problem is that if you can run a GTK app as root (anything equivalent to setgid) then you can probably hack that app and do bad stuff, http://gtk.org/setuid.html
So it's probably a requirement in all cases that we split out a backend that runs as root and have the UI separate.
Havoc
On Thu, Mar 03, 2005 at 04:02:57PM -0500, Havoc Pennington wrote:
One problem is that if you can run a GTK app as root (anything equivalent to setgid) then you can probably hack that app and do bad stuff, http://gtk.org/setuid.html So it's probably a requirement in all cases that we split out a backend that runs as root and have the UI separate.
Yes, sounds very sane.
Plus, as long as we're using SELinux, that could definitely help here.
On Wed, Mar 02, 2005 at 10:08:07AM -0500, Eric Warnke wrote:
I have unsucessfully been attempting to find out through both documentation, testing, and internet sources if I can get consolehelper to act more like sudo rather than su. Right now my problem is that there is NO WAY to roll this out to more users as a desktop alternative without giving them some power user ability ( printers, date and time,
This may help. As of Fedora Core 3, the "UGROUPS" patch is in usermode. From the userhelper man page:
UGROUPS A comma-separated list of groups whose members will be authen- ticated as if USER were set to the special value <user>. If the invoking user is not a member of one of these groups, the name defined in USER will be used as normal. For example, setting UGROUPS to wheel and USER to root allows members of wheel (tra- ditionally used for administrative privileges) to authenticate with their own credentials and requires other users to provide the root password.
So, for example, if /etc/security/console.apps/system-config-users looks like this:
USER=root PROGRAM=/usr/share/system-config-users/system-config-users SESSION=true UGROUPS=wheel
members of the wheel group will be able to authenticate with their own passwords, and others will need the root password.
We've made this the default for all of the system-config-* apps here at BU for several years with good results; it might be nice to also make it the default in future versions of Fedora. (Although this is a pretty big default security policy change, it *is* basically the traditional meaning of the "wheel" group.)
Caveat: I just noticed that the little "keys" gnome-panel icon doesn't work with this, and I'm trying to figure out what should be done about that.
desktop@lists.fedoraproject.org
-
David Zeuthen -
Eric Warnke -
Havoc Pennington -
Kyrre Ness Sjobak -
Matthew Miller -
Mike Hearn