How many dbus privilege elevation daemons are we going to have?
Posted Nov 23, 2009 10:11 UTC (Mon) by buchanmilne
In reply to: sudo granularity
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)
rurpmi - restricted urpmi
rurpmi [options] [package_name...]
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
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.
This software is still experimental. While some operations are
forbidden, there is no guarantee it is actually secure.
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?
to post comments)