How many dbus privilege elevation daemons are we going to have? [LWN.net]

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

Posted Nov 23, 2009 10:11 UTC (Mon) by buchanmilne (guest, #42315)
In reply to: sudo granularity by drag
Parent article: Fedora 12 to remove unprivileged package installation

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?

(Log in to post comments)