|
|
Subscribe / Log in / New account

Fedora 12 lets unprivileged users install packages

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 0:53 UTC (Thu) by elanthis (guest, #6227)
Parent article: Fedora 12 lets unprivileged users install packages

Wheel group. The end. No need to invent more crap
or fancy mechanics to deal with basic security we had solved years ago.


to post comments

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 1:03 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (6 responses)

Wheel group doesn't give you the level of fine grained access PolicyKit does. PolicyKit lets me set a local policy that says I want users in the active session to be able to update the system without a password, install packages with a password and deny package removals by default and deny everything in the remote session.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 2:24 UTC (Thu) by djcapelis (guest, #53964) [Link] (5 responses)

Packagekit should be using PAM to do this. You know, the framework that already does all of those things that you mentioned but the -kit folks didn't bother to reuse it and just expose their policy as a set of PAM service providers?

The OP is right to be angry that he can't use pam_wheel.so to set policy with packagekit in a unified pam.d directory like he can with *every* other tool on his system.

The *-kit projects are often problematic exactly because of this type of destructive need to solve problems by inventing their own (usually inferior) frameworks. All of the policy needs could have been expressed with PAM modules and then we would have had a wonderful unified way to express these types of policies across all kinds of administrative tasks. (PAM is already quite good at these needs.)

But no, we have pklalockdown and /var/lib/polkit-1/localauthority/20-org.d instead.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 2:39 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (4 responses)

PAM is again different from PolicyKit. Start reading from

http://hal.freedesktop.org/docs/PolicyKit/intro-define-pr...

PolicyKit is not a replacement for PAM, Sudo, wheel users or other methods of elevating privileges. Btw, pklalockdown is not in any released version of PolicyKit and is apparently being dropped soon. So pkla files are the recommended way forward as explained in the blog post. The location /var doesn't seem to be a good match and that is being discussed in the development list.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 13:27 UTC (Thu) by fuhchee (guest, #40059) [Link] (3 responses)

"PolicyKit is not a replacement for PAM, Sudo, wheel users or other methods of elevating privileges."

Right, it's just an *additional* way of elevating privileges.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 18:11 UTC (Thu) by drag (guest, #31333) [Link] (2 responses)

It is a attempt to effectly eliminate the need for sudo/su for normal activities as well as provide a way to sanely configure this sort of thing for a administrator.

For example:

Prior to Policykit/DeviceKit type stuff the only way users could mount removable media was to use 'sudo mount' or some similar mechanism. Now you can configure a user's desktop to allow the user account to mount removable volumes.

So lets say your running a corporate network of Linux desktop users and there is a certain class of users that require the ability to mount USB drives for their jobs, for whatever reason.

Using the old way you would have to set up a configuration management system to manage your sudoers configuration and then train your users on how to use sudo. (or have gtksudo or something like that launch stuff on their behalf). And by giving them ability to use sudo your giving them the ability to run root-privileged code under their user account. You can lock down sudo, but it's always a issue.

How, for example, are you going to use sudo to prevent them from remounting a drive in a vulnerable way? How are you going to differentiate between local or network drives or anything like that? You can write shell scripts, but it's trivial to inject code into shell scripts. (which is why the kernel ignores setuid root permissions on scripts). Using Policykit this gives you a saner way to configure policies for groups of users. Right now you'll have to still use a configuration management engine to do it, but in the future it'll support using things like LDAP for configurations. Combining that with Devicekit this allows you to give privileged actions to certain users while still avoiding the pitfalls of giving them (hopefully limited) access to root.

Previously you'd have to be very careful and audit the code of every application you create to run as root to carry out the privileged actions of the user's (since it's running as root under a user's control) to auditing the dbus interfaces for those privileged applications. As long as the daemons and policykit's dbus code is properly secure then this should make your systems much more secure then running gtksudo or sudo or whatever else that gives users root account access.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 18:48 UTC (Thu) by foom (subscriber, #14868) [Link] (1 responses)

Perhaps you didn't know about the "user" option in /etc/fstab that allows unprivileged users to
mount certain devices? That certainly isn't perfect in today's world of dynamically allocated device
names, but it worked quite well before that.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 19:38 UTC (Thu) by drag (guest, #31333) [Link]

Yes if you know what device is going to be mounted prior to mounting it then
you can configure the system ahead of time.

And you are right that it's a poor match with what we have to deal with
today.

That and it's just one of dozens of examples.

Fedora 12 lets unprivileged users install packages

Posted Nov 19, 2009 1:06 UTC (Thu) by ofeeley (guest, #36105) [Link]

Except that that basic security doesn't allow trusted, local desktop users to easily install packages. (Read your children or other relatives as a synonym for trusted, local desktop users).

If there is anything to get excited about it's the lack of clear signaling of this change and the lack of simple ways to revert it.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds