Fedora 12 to remove unprivileged package installation [LWN.net]

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 4:11 UTC (Fri) by mmcgrath (guest, #44906) [Link] (9 responses)

A couple of things about this in case this article turns into another thread of doom.

1) Fedora has no policy at present regarding what actions a user should be able to take without root access and I suspect most if not all other distributions don't have a written policy either. Though one may be in the works for us.

2) The package maintainers introduced this early on in the F12 lifecycle. That no one caught it and complained is a fault of the lifecycle, not the maintainers.

3) Fedora 12 was released on Tuesday, it's now Thursday and problem has been taken care of and all of us (not just in Fedora) will be giving second thoughts to things like this in the future. Kudos for the quick response, I'd like to think we're all better for it.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 4:16 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (3 responses)

On 2), noone caught this before because Rawhide packages are unsigned making PackageKit prompt for password and also because those of who choose to retain the authorization while entering the password for the first time wouldn't notice the difference after an upgrade. So it's not the fault of the lifecycle. Maintainers are certainly responsible for announcing and documenting the changes properly.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 6:41 UTC (Fri) by pabs (subscriber, #43278) [Link] (2 responses)

Uhh, unsigned packages doesn't sound good.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 6:56 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

Just to be clear, Rawhide is the development branch of Fedora.

Fedora 12 to remove unprivileged package installation

Posted Nov 22, 2009 11:40 UTC (Sun) by pabs (subscriber, #43278) [Link]

I knew that before my post :)

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 6:55 UTC (Fri) by bojan (subscriber, #14302) [Link] (4 responses)

> 2) The package maintainers introduced this early on in the F12 lifecycle. That no one caught it and complained is a fault of the lifecycle, not the maintainers.

Question: did official release notes of Fedora 12 (i.e. on the day it came out) have information about this or not?

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 6:58 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (3 responses)

No. If you read Owen Taylor's mail, that has been made explicit. A release note update pushed as soon as soon as we were aware of the changes needed to revert it.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 7:05 UTC (Fri) by bojan (subscriber, #14302) [Link] (2 responses)

> No.

Right. I think that may be half the problem here. If it was in release notes, more people would pick it up before the release.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 7:09 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

Yes, which is my point if you read

http://lwn.net/Articles/362998/

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 7:26 UTC (Fri) by bojan (subscriber, #14302) [Link]

Yeah, that's the thing I wasn't sure of, whether there actually was something in the notes or not, because the documents are on the web and they are subject to change. I don't remember seeing anything, but I didn't read every single line (I upgraded a few days before the official release).

Thanks for the confirmation.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 4:34 UTC (Fri) by tkil (guest, #1787) [Link] (36 responses)

Has there been any discussion on switching to a "sudo" model? That way, trusted users could
simply supply their own password and the root password can stay with just root. (Granted, that's
not as much of a big deal anymore as more and more installs are single-user, but...)

FWIW, OSX uses this model (as does Vista, to a slightly lesser extent).

Maybe that's the fancy roles-based stuff that they didn't get around to finishing, as discussed in
the main article...

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 4:38 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (25 responses)

Sudo, atleast as configured in Mac OS X and Ubuntu provides much broader access than the role based policies planned. The desktop team interest in Fedora seems be not go the sudo way but instead rely on PolicyKit.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 5:47 UTC (Fri) by tkil (guest, #1787) [Link] (24 responses)

Agreed that 'sudo' is much more powerful than just installing packages. But what I was trying to get at was less "fancy roles" and more "when the system wants root authority to do something, I'd like to be able to use my own password if I'm in the 'sudoers' file appropriately".

That's all.

As it is, I tend to manage packages on my Fedora 11 system through the terminal, and do "sudo yum ..."

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 13:00 UTC (Fri) by stickster (guest, #40146) [Link] (23 responses)

I think "more powerful" may not be the best characterization of sudo in this case. The point of using PolicyKit is that sudo is generally less granular, and more difficult to manage from a deployment perspective outside of the simplest cases. It's certainly a very useful tool and I'm sure that many people on single-user systems put a manual entry in /etc/sudoers to grant themselves or the wheel group access. It works reasonably well for the single-owner laptop, but it's actually not powerful enough from the standpoint of flexibility and granularity, or supporting a toolset around it for systems management policies or some of the other things planned for PolicyKit like role-based management.

sudo granularity

Posted Nov 20, 2009 13:21 UTC (Fri) by rfunk (subscriber, #4054) [Link] (22 responses)

Sudo allows you to specify permission not only by-user and by-group (and the
less-used by-machine), but also specify *by-executable* what they can do.
It's possible that that side of it is actually too granular, rather than not
granular enough.

sudo granularity

Posted Nov 20, 2009 13:24 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (21 responses)

Here is one example of where sudo is not fine grained enough: I want user foo to be able to update his system via PackageKit without any password and user bar to be able to just install packages but with his own password and I want other users to enter the admin password before doing any of these tasks.

sudo granularity

Posted Nov 20, 2009 13:31 UTC (Fri) by rfunk (subscriber, #4054) [Link] (20 responses)

sudo can absolutely do that, as long as you have different executables for
"updating" and for "just installing" (wrappers are often helpful). I'm not
familiar with PackageKit, but I could certainly do it with apt-get or
aptitude.

sudo granularity

Posted Nov 20, 2009 13:38 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (3 responses)

Precisely, sudo can only do it when they are different executables. Not granular enough. Btw, I am talking about doing it in the graphical interface. Not command line.

sudo granularity

Posted Nov 20, 2009 14:15 UTC (Fri) by hppnq (guest, #14462) [Link]

Precisely, sudo can only do it when they are different executables.

Not at all, sudo supports program arguments and options.

Btw, I am talking about doing it in the graphical interface. Not command line.

What's the difference?

sudo granularity

Posted Nov 20, 2009 14:28 UTC (Fri) by rfunk (subscriber, #4054) [Link] (1 responses)

Any program that would allow the restrictions you're talking about has to be
designed for it. How hard is it to design it to take different command-line
arguments for the different cases, rather than using some new API?

Sigh. Once again, those who don't understand Unix are doomed to re-invent
it, poorly.

sudo granularity

Posted Nov 20, 2009 16:31 UTC (Fri) by stickster (guest, #40146) [Link]

Thankfully I'm not involved in the design or implementation of PolicyKit, so any lack of clue I have won't be a factor. :-) Are you interested in reviewing the documentation for PolicyKit and bringing your insight to the development list upstream?

sudo granularity

Posted Nov 20, 2009 14:12 UTC (Fri) by fperrin (subscriber, #61941) [Link] (15 responses)

You can also say that user foo can run "aptitude update" and "aptitude upgrade" without password, and bar can run "yum install whatever" with a password with something like:

foo ALL=NOPASSWD: aptitude update, aptitude upgrade
bar ALL = aptitude
# or maybe: bar ALL = aptitude install *

http://www.gratisoft.us/sudo/sample.sudoers contains plenty of other examples. Saying that sudo isn't granular enough is wrong :)

sudo granularity

Posted Nov 20, 2009 16:04 UTC (Fri) by drag (guest, #31333) [Link] (14 responses)

If you use Packagekit and Policykit you can configure it to do pretty much the entire thing without allowing the user any access to the root account.

This is the biggest advantage over sudo. Sudo gives access to the root account and that is a bad thing. Yes it can be configured to do a per binary or even restrict people somewhat on the types of commands they can execute, but the problem you run into is that if there is any vulnerability in any part of that program your handing over or if it's possible to mishandle it in any way then that is a easy way to get root access to your machine.

With *kit/policykit all you have to worry about in terms of vulnerable code is the dbus interface for the privileged daemon. As long as that is good then you know your safe. Of course you'll never be able to get rid of sudo, it's a very valueable administrative tool, but if you can cover common desktop cases in a more secure manner then that's a big win.

sudo granularity

Posted Nov 20, 2009 21:31 UTC (Fri) by mjthayer (guest, #39183) [Link] (13 responses)

So in other words, the difference being that the P*Kits do not give you access to stdin and stdout of the the privileged helper?

sudo granularity

Posted Nov 21, 2009 2:36 UTC (Sat) by drag (guest, #31333) [Link] (12 responses)

Isn't that enough?!

Look at the above example given:

foo ALL=NOPASSWD: aptitude update, aptitude upgrade

When you invoke 'aptitude upgrade' aptitude will sometimes run into dependency resolution issues. When that happens you can go into 'resolution mode' that gives you full access to the aptitude gui and there you can perform any of the functions supported by aptitude, which is a huge amount. That is almost certainly not the intended purpose of that sudoers line! How hard would you suppose it would be to get a shell out of something like that?

Is aptitude even intended to be secure against tempering? Did the author ever intend or expect it to need to be tamper proof? I really doubt it.

You guys are going on like sudo is easy to get right that it's easy to write administrative scripts and that it's configuration system is so much more simpler and easier to deal with.. and it's not. It's a very difficult thing to get right with a very obscure configuration system and is full of numerous pitfalls and holes. The major benefit of sudo right now is that it's going through so many years of providing so many security holes in so many systems that people have most of the obvious stuff that can go wrong with the sudo command itself fairly locked down.

Another example is what happens when you perform a upgrade and Debian introduces a configuration change to one of the maintainer scripts? I know you can view the differences between the files... does it use 'less' for this? (I don't know off the top of my head) If it does then you can do a ! and shell out of that and then get full root access.

In that example it's obvious that the person was trying to take something that was never intended and never designed to provide any sort of security at all.. aptitude was designed for the sole purpose of being used by a root account with no access controls expected at all and then your trying to to use sudo to turn into something that it's not designed to do. I am not trying to pick on it and I expect a person can come up with better examples with more thought, so any apologies if I offended; I am not trying to be insulting or anything here.

But, at least with packagekit and policykit I never have to worry about any of that affecting the security of my desktops if I configure it to allow certain users to perform upgrades and nothing else. It's not really that difficult to 'get' and work with it to provide that sort of common functionality. not hard to do at all.

sudo granularity

Posted Nov 21, 2009 13:09 UTC (Sat) by cortana (subscriber, #24596) [Link]

> How hard would you suppose it would be to get a shell out of something
> like that?

Trivial, FYI. Modify a config file of the one of the packages you are upgrading, and dpkg will ask you whether you want to see a diff, edit the file, or drop to a shell. :)

sudo granularity

Posted Nov 21, 2009 14:52 UTC (Sat) by fperrin (subscriber, #61941) [Link] (1 responses)

When you invoke 'aptitude upgrade' aptitude will sometimes run into dependency resolution issues. When that happens you can go into 'resolution mode' that gives you full access to the aptitude gui and there you can perform any of the functions supported by aptitude, which is a huge amount.

What happens if the user wants to install a package that conflicts with something that is already installed on the system? Will PackageKit decides to overwrite what is already installed, or will it fail to install the package? The first is a no-no, the second is, well, a failure. Or maybe it will ask the user how to resolve the dependencies, in which case we are back to the same situation as with aptitde in "resolution mode".

sudo granularity

Posted Nov 21, 2009 16:00 UTC (Sat) by sbishop (guest, #33061) [Link]

I'd go with "fail to install the package". At that point, root needs to get
involved, which seems reasonable to me.

sudo granularity

Posted Nov 22, 2009 0:08 UTC (Sun) by hppnq (guest, #14462) [Link]

The problems with sudo and dpkg (and friends) you describe have been known for a while. Search for bug 318736: updating the system should not be done by untrusted users, was the verdict of the dpkg maintainer. There are no default configurations that I know that are at odds with this -- except of course the one we are discussing here.

(There is cosmic justice: if you have searched for bug 318736, you may have noticed one Debian sudo related bug (well, apt-listchanges run with escalated privileges) and one Ubuntu dbus related one.)

How many dbus privilege elevation daemons are we going to have?

Posted Nov 23, 2009 10:11 UTC (Mon) by buchanmilne (guest, #42315) [Link]

Isn't that enough?! Look at the above example given: foo ALL=NOPASSWD: aptitude update, aptitude upgrade

I would have thought Debian would have had at least some mitigation for this. Mandriva has had rurpmi for years:

RURPMI.8(1)          User Contributed Perl Documentation         RURPMI.8(1)



NAME
       rurpmi - restricted urpmi

SYNOPSIS
           rurpmi [options] [package_name...]

DESCRIPTION
       rurpmi is similar to urpmi, but has a stripped-down set of features.
       It's intended to be used by users without root privileges but with
       sudo rights on it, preventing any abuse of this tool to compromise
       the system.

       With rurpmi, you can't install arbitrary rpm files; moreoever the
       --keep and --verify-rpm options are forced, and several dangerous
       options are forbidden (--root, --use-distrib, --env, --allow-nodeps,
       --allow-force, --force, --noscripts, --auto-update). Also, you won't
       be able to install rpms with bad signatures.

CAVEAT
       This software is still experimental. While some operations are
       forbidden, there is no guarantee it is actually secure.

OPTIONS
       The options are the same than urpmi ones.

Note that, being RPM-based, there are no package-installation interactive features in urpmi (diff viewing or editing, prompts for configuring packages after install etc.), although config file diff viewing is available in rpmdrake.

While I guess there are potential security risks that haven't been audited, I have been using it via sudo for years (and been providing it to other users, e.g. via sudo rules in LDAP):

Now, it won't (in fact, doesn't, as nothing provides access to rurpmi by default) help the GUI case. While rpmdrake run as non-root can browse packages, the default GUI method to install packages ends up running rpmdrake (and thus perl-GTK and GTK etc.) as root. However, packagekit is also available, and will hopefully become the default in future.

Ultimately I guess something like *Kit is the solution to manage elevated access, but how many daemons running as root solely to provide privileged access are we going to end up with? So far we have one for packages, one for network interfaces, one for hardware, and one for device permissions. How many more will there be?

sudo granularity

Posted Nov 23, 2009 10:17 UTC (Mon) by mjthayer (guest, #39183) [Link]

>> So in other words, the difference being that the P*Kits do not give you access to stdin and stdout of the the privileged helper?
> You guys are going on like sudo is easy to get right that it's easy to write administrative scripts and that it's configuration system is so much more simpler and easier to deal with.. and it's not.
Actually I was just wanting to be sure that I had understood your previous posting :) In fact, I really like the idea of PolicyKit, as in properly implementing granular least-privilege administration, and it seams to me as though it could be a more understandable way of doing many things done by SELinux today. My main problem with it is that its dependency on DBus means that it is mainly limited to desktop environments. Nothing against DBus - I think it is a neat IPC system - but it has only really caught on on the desktop, and I'm not really sure why an IPC bus is needed here anyway rather than a privileged helper on the lines of (but not necessarily the same as) sudo. Not to mention that if DBus stops or crashes for any reason - not inconceivable - PolicyKit is also out of action.

sudo granularity

Posted Nov 23, 2009 10:33 UTC (Mon) by mjthayer (guest, #39183) [Link] (5 responses)

> Another example is what happens when you perform a upgrade and Debian introduces a configuration change to one of the maintainer scripts?
Totally off-topic, but that is my least-favourite aspect of the Debian packaging system. The way that configuration files are installed by default, and that if the user then configures the package in any way (including using a script or a GUI tool) they have to manually resolve the differences in the configuration file during upgrade is notably lacking in elegance. I suppose it is hard to avoid in some cases, but I'm sure it could be in most.

sudo granularity

Posted Nov 23, 2009 22:04 UTC (Mon) by nix (subscriber, #2304) [Link] (4 responses)

It seems to me that, if it were taught about enough configuration file
formats, augeas could fix this (at least for the fairly common case of
configuration files that aren't actually programs in a Turing-complete
language: nothing will save you from manual resolution if you modify a
shell script).

sudo granularity

Posted Nov 24, 2009 10:20 UTC (Tue) by mjthayer (guest, #39183) [Link] (3 responses)

Augeas looks nice, but a relatively mechanism-free way of doing this for .debs (the mechanism used could still be Augeas) would be to add support for configuration file updater scripts. Such a script could process a configuration file automatically and return success if it were able to complete the job without making any "unsafe" changes, and failure with an explanatory message otherwise. All messages from a dpkg configuration run could be displayed at the end of that run to avoid interrupting running updates. And packages like upstart, for which other packages are likely to provide configuration files, could export an updater script for use by those packages.

Of course, knowing the Debian packaging system there is probably already a way to do this now.

sudo granularity

Posted Nov 24, 2009 10:48 UTC (Tue) by mjthayer (guest, #39183) [Link] (2 responses)

> Of course, knowing the Debian packaging system there is probably already a way to do this now.
Update: of course there is.
http://www.debian.org/doc/debian-policy/ap-pkg-conffiles....

sudo granularity

Posted Nov 24, 2009 12:59 UTC (Tue) by mjthayer (guest, #39183) [Link] (1 responses)

Actually after (re-)reading the page linked to above, I wonder whether a good solution would be to write scripts to do this for individual packages using Augeas and try to get them included upstream. The Debian packagers would be likely to use them, but others might well do so as well, and they would get much wider review. And starting with a few high-profile packages might make the idea catch on :)

Thanks for pointing out Augeas anyway.

sudo granularity

Posted Nov 24, 2009 20:45 UTC (Tue) by nix (subscriber, #2304) [Link]

I only discovered it yesterday while exploring libvirt's dependencies
(hey, I was bored). It's the first use of even a subset of ML in anger
that I've ever seen.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 4:40 UTC (Fri) by drag (guest, #31333) [Link] (7 responses)

Yes. The role-based thing was not finished. That is why they defaulted to
"all local users".
<br><br>
This version of package kit is not configurable on a per-user basis and that
is the core of the problem.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 4:43 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

Actually, it *is* configurable using PolicyKit on a per user basis. Just doesn't have a GUI to do it in this release.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 4:46 UTC (Fri) by drag (guest, #31333) [Link] (1 responses)

Just going off of what was said in the email:

"""
The idea was that the change in PolicyKit would be accompanied by a
default set of roles, and a nice user interface for assigning users to
roles. Unfortunately, with the constraints of time, it became clear that
this all (and especially the GUI) wasn't going to be there for Fedora
12. So, PackageKit needed a fixed policy for all users. For each action
(install signed packages, install unsigned packages, remove packages,
etc.), it needed to allow, deny, or ask for the root password.
"""

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 5:16 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

Perhaps you misunderstood something but you can write policies yourself. Read man pklocalauthority for examples. It doesn't have a GUI.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 5:51 UTC (Fri) by tkil (guest, #1787) [Link] (3 responses)

The thing is, it looks like the knobs that are getting exposed (regardless of whether or not there's a GUI) are the ones I want. I'm actually very fine with the old-school "you have to have root authority to do X" rules; what I want is to be able to use a sudo-like capability to show root authority using my own password, and not have to use root's.

*shrug* Not really that big of a deal, but it's something that I really like in OSX, and would like to have in Fedora. I'll look more closely at some of the options available now, to see if this capability is there and just turned off.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 5:56 UTC (Fri) by tkil (guest, #1787) [Link]

Grr... stupid thinkos

The thing is, it looks like the knobs that are getting exposed (regardless of whether or not there's a GUI) are not the ones I want.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 6:25 UTC (Fri) by AdamW (subscriber, #48457) [Link] (1 responses)

policykit is far more fine-grained both in terms of authentication methods and actions than _any_ previous system, including su and sudo.

with policykit you can require all sorts of types of authentication for any defined pk action, and actions are far more fine-grained (su and sudo can only make _entire processes_ run with changed privileges). authentication can be with root password, with user password, or with all sorts of other mechanisms. it's extremely powerful. so, yes, policykit would definitely allow you to do what you want if you configure it appropriately (allow any particular action with authentication via the user password).

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 6:40 UTC (Fri) by tkil (guest, #1787) [Link]

so, yes, policykit would definitely allow you to do what you want if you configure it appropriately (allow any particular action with authentication via the user password).

Spiffy! I'll definitely have to look into PK in a bit more depth than I have. Thanks for the info!

PolicyKit _can_ do this

Posted Nov 20, 2009 18:08 UTC (Fri) by mattdm (subscriber, #18) [Link] (1 responses)

I think your question isn't really about sudo per se, but about auth-as-self instead of auth-as-root. This is often a better choice than no-auth-at-all, particularly for desktop machines -- I want to be able to let my friend browse in Firefox at my computer and be assured that he won't (accidentally or otherwise) install packages, set the system time, etc.

And the answer is: yes, PolicyKit can do this. You set ResultAny in the policy config file to "auth_self" instead of "auth_admin" -- or to "auth_self_keep", to provide temporary caching of authorization (like the sudo typical config).

consolekit, the tool used in Red Hat derived distributions for root access for GUI (and a few command line) utils before PolicyKit, can also do this.

PolicyKit _can_ do this

Posted Nov 20, 2009 20:57 UTC (Fri) by tkil (guest, #1787) [Link]

I think your question isn't really about sudo per se, but about auth-as-self instead of auth-as-root.

Yes, exactly! Thank you for the excellent terminology.

And the answer is: yes, PolicyKit can do this. You set ResultAny in the policy config file to "auth_self" instead of "auth_admin" -- or to "auth_self_keep", to provide temporary caching of authorization (like the sudo typical config).

That's excellent, and I'll keep it in mind. (I'm currently in the "single user workstation" mode, so having to enter root's password isn't that big of a deal to me, honestly.)

If I had more energy, I'd try to follow the conversation on the mailing lists, but I should have taken my cue from the first comment here. :) I do think that the OSX and Vista models of "admin users vs. regular users" is a decent start (and actually echoes historical usage of the "wheel" group); further, I find it preferable to having to enter the root password (the default on Fedora for a while now).

(I also realize that there are at least two issues with Linux systems that OSX and Vista don't see nearly as often: (1) the person sitting at the console, regular user or admin, does need extra privs to do some entirely reasonable actions; and (2) Linux systems are far more likely to have remote users than either OSX or Vista systems.)

Also also wik, subscriber #18? Yowza. :)

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 8:04 UTC (Fri) by elanthis (guest, #6227) [Link] (14 responses)

::rolleyes:: wheel group. That's what it is for. Users with wheel can get all the nice admin-
only features. Let the user GUI have a nice easy "administrator" flag forsetting it for novice
sysadmins. Have it set on the initial user account created by anaconda. Stop reinventing
the wheel (hehe) and creating new weird text file configuration that nobody knows about and
does nothing actually needed that warrants the extra complexity.

Simplicity == godliness.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 8:20 UTC (Fri) by drag (guest, #31333) [Link] (12 responses)

I don't think that the whole world of group/user/system/application/local/remote policies for a user is allowed or not allowed to do in corporations, home desktops, military, government.. Any and all environments, organizations, and use cases for everything can be managed accurately and effortlessly with that single 'on/off' switch that is 'wheel membership'.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 8:34 UTC (Fri) by SiB (subscriber, #4048) [Link] (11 responses)

Maybe, a simple on/off switch (wheel group) is much safer in most cases than another bloated mechanism that is difficult to get right and to configure correctly and securely.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 8:41 UTC (Fri) by jengelh (guest, #33263) [Link]

Indeed. Name SELinux.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 11:09 UTC (Fri) by drag (guest, #31333) [Link] (9 responses)

Wheel alone is only able to meet 2 use cases. Having a central mechanism like Packagekit means that a user/admin is able to configure their system in a sane manner for a much wider set of requirements.

Hell on my Debian box I have my main user belong to no less then 14 different groups, each of which give different privileges to different aspects of the system. A couple I had to create myself in order to avoid using 'sudo' all the time. (and I can tell you right now that requiring the user to run root code under their account won't fly in the majority of organizations) I can tell you that having a central way to manage user permissions like packagekit is vastly simpler and easier to get right then having to create my own groups, touch a half a dozen different configuration files all over my system and setting up special file system configurations for usbfs and directories in /var in order to avoid using 'sudo'. Half of it was educated guess work.. playing around with different settings until I got things to work properly. I tried to get it right, but I really have no way to properly test it.

Now imagine having to manage a mess of desktops. Dozens or Hundreds or even thousands of desktops. And you have to take into account a many different types of users from different departments with different policies and different requirements. The ability to set 'group policy' is a killer feature for managed desktops. It's to the point now were it's a hard requirement.. unless your OS is able to provide that sort of mechanisms it simply won't be considered.

Even simple single-computer use cases like setting up a guest account or koisk in order to put the system into a secure-enough mode to allow children or untrusted people to use the desktop can be surprisingly difficult to get right, unless your distro has already gone through a lot of effort to pre- configure it for you.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 11:51 UTC (Fri) by hppnq (guest, #14462) [Link] (8 responses)

Half of it was educated guess work.. playing around with different settings until I got things to work properly. I tried to get it right, but I really have no way to properly test it.

And you seriously prefer that over sudo or configuring it properly? Am I missing something?

The ability to set 'group policy' is a killer feature for managed desktops

In the corporate environments where I work security and functionality are not at all tied to the desktop, which is just a simple display and keyboard so you can login to the applications. On the servers, sudo is hooked up with LDAP to provide specific (groups of) users with specific ways to gain some specific extra privileges and administrators with a way to audit everything.

Simple and effective, because it's standard. Not 100% secure and user friendly, but if something goes wrong (and we can predict this confidently and accurately), we know what went wrong and we can fix it within the SLA.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 15:14 UTC (Fri) by drag (guest, #31333) [Link] (7 responses)

> And you seriously prefer that over sudo or configuring it properly? Am I missing something?

I usually prefer to at least try to make something better rather then just shrugging and keeping it insecure because it's easier that way.

> In the corporate environments where I work security and functionality are not at all tied to the desktop,

In most places security on desktops is rather important because that is were people get most of their work done and they use desktops to access everything else on the network. This is because they use things like passwords and kerberos tickets as access controls.. if the desktops the people are using is insecure then so is their access to everything else on the network.

They'll use single sign on and things of that nature because the #1 (by a huge margin) threat to security is weak passwords and requiring users to remember multiple passwords and type in passwords all the time is entirely counter productive. It's absolutely critical that they make it as easy and convenient as possible to use secure passwords. So the place the 'ticket' is cache'd in very important as is the places people type their passwords and access other services from; which of course is the desktop.

If all the desktop is nothing more then a overgrown a terminal then that's easy... just deny everything to everybody. But that's not the reality of many places.

None of this is really rocket science and policykit is not the huge bloated monster that people are trying to pretend that it is. Server environments are much simpler and much easier to manage, which is one of the reasons Linux is popular on the servers, but is unpopular on the desktop. "Group Policy" is, indeed, one of the killer features when it comes to something like Active Directory. Policykit can provide one aspect of what people consider 'group policy' and things like Sabayon provide the other half.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 16:08 UTC (Fri) by clugstj (subscriber, #4020) [Link] (6 responses)

Wow, still trying to justify bad decisions. I haven't seen any use case that couldn't have been much more easily and transparently handled by "sudo". Putting this change in without even having it show up in the release notes deserves all the flaming that has been done - even if it had been a good idea.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 16:24 UTC (Fri) by drag (guest, #31333) [Link] (5 responses)

Well if your talking about granting passwordless ability to install packages to all local users then Fedora
screwed up on two accounts:

1. Did not put it in the release announcements.

2. Made it default for all local users. It should of only been the default for the initial user.

That was the big mistakes.

The passwordless stuff is actually a good feature though. Asking for the user's password is just
security theater because they have already proven their identity through passwords by being able to
log in before. In addition to that prompting users for their user password offers almost no protection
against attacker dwelling in their user account.

This is a huge misconception that prompting the user for their password multiple times is useful
security. It actually is more likely to make things worse since it encourages bad password policy and
numbs the user against real security concerns. Prompting them for the root password is counter
productive since the whole goal is to eliminate access to root in addition to promoting the same bad
password behaviors and encouraging the user to ignore real security concerns.

The number #1 threat to Linux desktop security is weak passwords. Requiring the user to use the
same passwords multiple times or requiring them to use passwords for regular events is making the
problem worse. Regularly popping up warning dialogs is very bad also. Either they have the rights to
perform the action or they don't.. bugging them over and over again when they have rights to the
action is very 'windows-like' in it's bad behavior.

If you still desire a password for regular desktop events then it should probably be a third 'admin'
password that is not root and is not the user's password. Even though that is still mostly theater it's
probably a good compormize.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 16:33 UTC (Fri) by clugstj (subscriber, #4020) [Link] (4 responses)

Still haven't seen a use case that would have been difficult/impossible to implement with "sudo". Why the wheel reinvention?

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 16:47 UTC (Fri) by drag (guest, #31333) [Link] (3 responses)

> Still haven't seen a use case that would have been difficult/impossible to implement with "sudo". Why the wheel reinvention?

The use case is "Being able to perform daily desktop activities without granting access to the root account". That's all. Like I said people are trying to make this too complicated or something. I don't know.

The one use case that most people are probably using now and don't give a shit about is the ability to hotplug cameras and USB devices on their desktops. I haven't heard anybody screaming about this for a long time.. not since it was initially introduced and they mistakenly setup the policy for Gnome users to automount any volume and not just removable media.

That's traditionally root-only action that eliminated a big reason for using sudo on the desktop and increased the usability of the Linux desktop in a huge way. No root password prompt and no user password prompt. This goes for cdroms, usb keys, cameras, and other things. Would it make sense to deny the users this feature if they are not members of wheel and go back to requiring them to use sudo if they were members?

The ability to perform that action is configurable through policykit and users can decide the automount policy through configuring apps residing entirely in their user account. Administrators can configure all of this through the policykit/sabayon type stuff combined with other *kit things.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 19:45 UTC (Fri) by dskoll (subscriber, #1630) [Link] (2 responses)

The use case is "Being able to perform daily desktop activities without granting access to the root account". That's all.

sudo grants restricted access to the root account. So does Policy Kit. The technical details differ (sudo does it in-process with a SUID binary; Policy Kit does it via IPC to a daemon running as root), but you're just quibbling over semantics by claiming that Policy Kit does not grant "access to the root account."

Note that I have no strong preferences for sudo over Policy Kit except for the general observation that very granular and tweakable security facilities are often harder to get right than less granular ones. However, as long as distros do a good job of providing sensible Policy Kit defaults, then Policy Kit is fine. The big issue was that F12's (now reverted) policy was not very sensible.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 21:18 UTC (Fri) by drag (guest, #31333) [Link] (1 responses)

Yeah. The defaults were not that sensible. Only one user should be administrator and it should of been apparent in the release documentation.

However the Dbus IPC is sockets-based. Nothing exotic like a shared memory scheme or anything like that. It gives users root access via those privileged daemons in the a similar manner that having httpd running as root gives remote users root access over port 80.

So ya any security issues in dbus itself or the dbus libraries that applications use would quite easily lead to a compromise and that is something that distros and developers are going to have to be very careful about. As long as that is audited and user supplied input over dbus is carefully managed then it should reduce the attack vector for attackers seeking local root exploits by quite a bit for typical desktop users (vs traditional linux desktop were open sudo and su access are regularly used features)

Policy Kit vs sudo

Posted Nov 20, 2009 22:07 UTC (Fri) by dskoll (subscriber, #1630) [Link]

However the Dbus IPC is sockets-based. Nothing exotic like a shared memory scheme or anything like that. It gives users root access via those privileged daemons in the a similar manner that having httpd running as root gives remote users root access over port 80.

Except there are two huge differences:

No-one runs httpd as root. It drops privileges immediately after creating the listening socket.
The Policy Kit daemon is explicitly designed to run as root and do root-privileged things. That's its whole purpose, after all!

So it's not the case that all the security lies in dbus. The security lies in dbus and the policy kit daemon and in making sure your policies are correctly implemented. It's the last two (especially the last one) that will cause trouble.

I'm not convinced that a root-privileged daemon that sanitizes its input is any more or less secure than a SUID binary that sanitizes its environment, etc. It seems to me neither approach is inherently more or less secure.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 8:34 UTC (Fri) by drag (guest, #31333) [Link]

Sorry, that last post came out all retarded and stupid.

What I mean to say is that it is often very necessary to provide a mechanism to have finer grained control over what a user is allowed to do and not allowed to do on a operating system. Depending on the context, depending on specific use cases, environments, and job requirements it is necessary to lock down or open up a system in different ways. Policykit allows administrators and users to implement 'group policies' for the Linux desktop. By providing a centralized and manageable central interface for this sort of thing it allows for much easier management and avoids much of the pitfalls you run into with unmanaged (or unmanageable) desktops.

This sort of thing can be overkill for typical desktop setups, were something like handing over the ability to run arbitrary executions as root willy-nilly (like Ubuntu) is a normal state of affairs, but it would be very nice to eliminate the need for running root for typical, everyday, and/or mundane desktop activities.

So while it may be handy to use 'wheel' to decide what accounts are 'admins' and what are not (thus avoiding making typical users deal with complex policy choices unless they have to). By itself it does not provide the needed controls or mechanisms.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 15:46 UTC (Fri) by Tara_Li (guest, #26706) [Link]

See, silly me, when I saw this feature originally announced, I thought *YAY* - they are now allowing users to install packages into their own home directories! How foolish, though - nobody would care about *THAT* capability.

Fedora 12 to remove unprivileged package installation

Posted Nov 20, 2009 16:18 UTC (Fri) by k8to (guest, #15413) [Link] (6 responses)

Complexity is the enemy of security.

Complexity eats kittens alive!!!

Posted Nov 21, 2009 22:27 UTC (Sat) by man_ls (guest, #15091) [Link] (5 responses)

Complexity is also the enemy of sanity, maintainability and many other things. In general it is the bane of information systems. And here we have some people trying to replace a good old simple well-understood scheme with a complex system having lots of knobs and configuration files. I am not saying that nothing new should ever be tried, but if it is more complex than the original solution then the benefits should be clear and understandable. Otherwise the new scheme almost certainly requires more thought.

It seems that most LWN readers don't get the supposed advantages of PolicyKit either. No doubt it is much better than sudo and wheel, but perhaps the real use case (maybe a group of RH clients requesting it) needs a better explanation.

Complexity eats kittens alive!!!

Posted Nov 24, 2009 2:18 UTC (Tue) by AdamW (subscriber, #48457) [Link] (4 responses)

it's pretty simple, really.

su/sudo: your disk management tool runs as root, or as user. ain't choice great?

policykit: administrator can define fine-grained policies for all the following actions:

Mount a device
Mount a system-internal device
Check file system on a device
Check file system of a system-internal device
Unmount a device mounted by another user
List open files
List open files on a system-internal device
Eject media from a device
Detach a drive
Modify a device
Modify a system-internal device
Refresh ATA SMART data
Run ATA SMART Self Tests
Retrieve historical ATA SMART data
Unlock an encrypted device
Lock an encrypted device unlocked by another user
Configure Linux Software RAID
Cancel a job initiated by another user
Inhibit media detection
Set drive spindown timeout

don't you see how that level of granularity might be just a _tad_ welcome to your average admin? Bear in mind that it's relatively simple to set up policies based on several levels of user roles, each level having a particular set of permissions, so you can set up a bunch of tailored profiles for your particular installation, and easily slot new users into the appropriate role for them...

Complexity eats kittens alive!!!

Posted Nov 24, 2009 7:08 UTC (Tue) by man_ls (guest, #15091) [Link]

Sure, it looks very useful and a real advance over classic Unix permissions. It should be easy to sell to companies. But it is also more complex than classic Unix permissions, so the simpler it is to manage the better.

Complexity eats kittens alive!!!

Posted Nov 24, 2009 15:53 UTC (Tue) by dskoll (subscriber, #1630) [Link] (2 responses)

don't you see how that level of granularity might be just a _tad_ welcome to your average admin?

No, not really. Explain what the difference between "a device" and "a system-internal device" is. What, exactly, are you allowed to do if you are allowed to "Modify a device"? What does "Cancel a job initiated by another user" mean? Kill someone's process? Stop an "at" or "cron" job?

We see here creeping Microsoftisms. Vaguely-defined actions (described in dumbed-down, imprecise language) that are supposedly security-critical, so the average admin is completely confused as to what he or she should allow. This is a real step backwards.

Complexity eats kittens alive!!!

Posted Nov 24, 2009 20:48 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

The distinction between 'device' and 'system-internal device' is clear
enough: the latter should really be 'external device'. Basically the
latter is internal disks and the former is USB stuff and things like that.

What a 'job' is, I have no idea. I agree, there should be a
maximally-precise version of the descriptions.

Complexity eats kittens alive!!!

Posted Nov 24, 2009 21:10 UTC (Tue) by dskoll (subscriber, #1630) [Link]

The distinction between 'device' and 'system-internal device' is clear enough: the latter should really be 'external device'.

It's not clear to me. What if I have a hot-swappable SCSI disk? Is that internal or external? How about if my root file system is on an external USB device? (Don't laugh... I run my EEEPC that way.)

Some of the categories listed don't look useful to me. In fact, they look dangerous exactly because they are imprecise. If complexity is the enemy of security, then imprecision is the nuclear weapon.

From:		"Paul W. Frields" <stickster-AT-gmail.com>
To:		fedora-announce-list-AT-redhat.com
Subject:		PackageKit change
Date:		Thu, 19 Nov 2009 21:52:38 -0500
Message-ID:		<20091120025238.GJ29686@victoria.internal.frields.org>
Archive‑link:		Article