9:08 a.m.
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
1:34 p.m.
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
2:02 p.m.
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).
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
2:31 p.m.
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
3:01 p.m.
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.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
3:10 p.m.
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
3:19 p.m.
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
3:41 p.m.
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.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
5:10 p.m.
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
9:29 a.m.
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
10:36 a.m.
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.
3:02 p.m.
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
3:08 p.m.
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
3:12 p.m.
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.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
1:56 p.m.
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.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
6990
days inactive
7009
days old
desktop@lists.fedoraproject.org
14 comments
6 participants
participants (6)
-
David Zeuthen -
Eric Warnke -
Havoc Pennington -
Kyrre Ness Sjobak -
Matthew Miller -
Mike Hearn