sudo granularity

Posted Nov 20, 2009 14:12 UTC (Fri) by fperrin (subscriber, #61941)
In reply to: sudo granularity by rfunk
Parent article: Fedora 12 to remove unprivileged package installation

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.