HideAdminToolsToUsers

Differences between revisions 1 and 3 (spanning 2 versions)
⇤ ← Revision 1 as of 2005-10-31 22:12:37 →
Size: 4082
Editor: 187_220_103_66-WIFI_HOTSPOTS
Comment: initial spec
← Revision 3 as of 2005-11-09 23:04:55 → ⇥
Size: 3329
Editor: 209
Comment: we need our own patch, adapt spec to actual implementation
Deletions are marked like this. Additions are marked like this.
Line 10: Line 10:
Normal users who are not allowed to execute admin programs should not have the admin tools included in their menus, nor get update-notifier messages in the notification area of the panel.  Normal users who are not allowed to execute admin programs should not have the admin tools included in their menus, nor get update-notifier messages in the notification area of the panel.
Line 30: Line 30:
It happens that the sudo CVS HEAD version enhanced the -l option to accept a command, and deliver in the exit code whether the user is allowed to execute that command. Thus it is not necessary to write any code on our own; the upstream patch just needs to be applied to the Ubuntu package. It happens that the sudo CVS HEAD version enhanced the -l option to accept a command, and deliver in the exit code whether the user is allowed to execute that command. However, CVS head is diverged too much from the current stable line, the patch does not apply at all. Thus we will implement our own small patch.
Line 32: Line 32:
With this patch, `sudo -l` ''command'' will exit with 0 if ''command'' can be executed by the user, and with 1 if not.

In addition we need to change sudo's "Default listpw" option to "false", since by default sudo asks for the user password. This introduces a small information disclosure, but such information can likely be found in other places like bash history, or by just trying.

In order to avoid blocking if the administrator manually enables the "listpw" option, sudo should be called with the '-S' option and with `/dev/null` as stdin.		 We will add a '-t' option to sudo, so that `sudo -t` ''command'' will exit with 0 if ''command'' can be executed by the user, and with 1 if not.
Line 40: Line 36:
Additional fields must be added to the desktop files which define the required privileges for the application:
 * X-Ubuntu-RootRequired = true (false is the default and does not need to be stated)
 * X-Ubuntu-GroupRequired = <group>		 Additional fields can be added to the desktop files of applications which require nonstandard privileges:
Line 44: Line 38:
gnome-system-tools (and other tools requiring root privileges) need to use `X-Ubuntu-RootRequired = true`, gnome-cups-admin uses `X-Ubuntu-GroupRequired = lpadmin`. {{{
X-KDE-SubstituteUID = true
X-KDE-Username = foo
}}}

These fields are already defined for KDE .desktop files, so we should just use them instead of introducing new names. `X-KDE-Username` defaults to `root` and usually does not need to be stated.
Line 48: Line 47:
gnome-menus need to check the additional fields in the desktop file and use `sudo -l` to check `X-Ubuntu-RootRequired`. gnome-panel already has a patch to check for group membership; this can be used to check `X-Ubuntu-GroupRequired`. gnome-menus need to check the additional fields in the desktop file and use `sudo -l` ''command in the .desktop file'' (or `sudo -u` ''X-KDE-Username value'' `...` if given) to decide whether to display a particular .desktop file.
Line 58: Line 57:
 * Apply the [http://www.courtesan.com/pipermail/sudo-cvs/2004-November/000119.html "check for command" patch] to sudo.
 * The sudo `postinst` script needs to add the option `Default listpw=false` option to the default `/etc/sudoers` file.		  * `sudo -t` ''command'' should never ask for the user's password. This is no information leak, since the user can always just try to execute it straight away. [-t option implemented in 1.6.8p9-3ubuntu2]
Line 64: Line 62:
In order to support upgrades from Breezy, the listpw option should be changed in an already existing `/etc/sudoers` file. Since this file is not a conffile, we can change it in the postinst without problems. The option should be placed below the "# Defaults" comment, or after the first comment block if the Defaults comment is not found. No configuration files are changed by this spec.

Summary

Normal users who are not allowed to execute admin programs should not have the admin tools included in their menus, nor get update-notifier messages in the notification area of the panel.

Rationale

It can be confusing if they try to access these functions and then they are not able to do what they believed.

Use cases

  • Martin is the local administrator of his home machine and wants to have easy access to the administrative programs in the Gnome menu.
  • Annett also uses this home machine, but is not allowed to change the system configuration. She does not want to see stuff that is not useful for her.

  • However, Annett is in the lpadmin group, so she does want to see the Printer administration menu entry.

Design

Backend

We need a backend to detect whether the user has the privilege to execute a particular command as a particular user. Currently gnome-menus checks whether the user is in the admin group, but this breaks upgrades from Debian and Warty and does not respect local sudo configuration.

To avoid duplicating code and possibly introducing security holes, sudo itself should be used to answer this question.

It happens that the sudo CVS HEAD version enhanced the -l option to accept a command, and deliver in the exit code whether the user is allowed to execute that command. However, CVS head is diverged too much from the current stable line, the patch does not apply at all. Thus we will implement our own small patch.

We will add a '-t' option to sudo, so that sudo -t command will exit with 0 if command can be executed by the user, and with 1 if not.

Desktop files

Additional fields can be added to the desktop files of applications which require nonstandard privileges: 

X-KDE-SubstituteUID = true
X-KDE-Username = foo

These fields are already defined for KDE .desktop files, so we should just use them instead of introducing new names. X-KDE-Username defaults to root and usually does not need to be stated.

gnome-menus

gnome-menus need to check the additional fields in the desktop file and use sudo -l command in the .desktop file (or sudo -u X-KDE-Username value ... if given) to decide whether to display a particular .desktop file.

update-notifier

update-notifier needs to check whether the user can execute update-manager as root and hide the icon if not.

Implementation

Code

  • sudo -t command should never ask for the user's password. This is no information leak, since the user can always just try to execute it straight away. [-t option implemented in 1.6.8p9-3ubuntu2]

  • The changes to gnome-panel and update-notifier are straightforward and don't need to be spec'ed.

Data preservation and migration

No configuration files are changed by this spec.

Outstanding issues

BoF agenda and discussion

HideAdminToolsToUsers (last edited 2008-08-06 16:17:54 by localhost)