HideAdminToolsToUsers

Differences between revisions 4 and 5
⇤ ← Revision 4 as of 2005-11-10 05:03:52 →
Size: 3879
Editor: 159
Comment:
← Revision 5 as of 2005-12-09 15:55:06 → ⇥
Size: 3238
Editor: 195
Comment: adapt spec to reality
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:
 * '''Packages affected''': sudo, gnome-panel, update-notifier, all administrative packages with a desktop file  * '''Packages affected''': gnome-panel, update-notifier, all administrative packages with a desktop file
Line 18: Line 18:
 * 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.		  0. Martin is the local administrator of his home machine and wants to have easy access to the administrative programs in the Gnome menu.
 0. 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.
 0. Mathias is not a full admin, but he was granted sudo access to time-admin, since he needs the company laptop for travelling.
Line 24: Line 24:
=== Backend === We need to detect whether the user has the privilege to execute a particular command as a particular user.
Line 26: Line 26:
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. It was discussed to add an option to sudo itself that tells whether the user can execute a particular command. However, this would either entail information disclosure even on servers (where it matters), or cluttering log files and the administrator's email with failed sudo attempts.
Line 28: Line 28:
To avoid duplicating code and possibly introducing security holes, sudo itself should be used to answer this question. Therefore a compromise was chosen that works for use cases 1 and 2, breaks use case 3, and still behaves sanely for upgrades from Debian and Warty: an administrative menu entry is shown if the user is in the 'admin' group or this group does not exist at all.
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. 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.		 == Implementation ==
Line 47: Line 45:
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. gnome-menus need to check the additional fields in the desktop file. A desktop file is hidden IFF:

 * group `admin` exists
 * the user is not in `admin`
 * `X-KDE-SubstituteUID == true`
Line 51: Line 53:
`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.		 `update-notifier` needs to hide the icon under the same conditions as stated above.
Line 67: Line 62:

== BoF agenda and discussion ==

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

  1. Martin is the local administrator of his home machine and wants to have easy access to the administrative programs in the Gnome menu.
  2. 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.
  3. Mathias is not a full admin, but he was granted sudo access to time-admin, since he needs the company laptop for travelling.

Design

We need to detect whether the user has the privilege to execute a particular command as a particular user.

It was discussed to add an option to sudo itself that tells whether the user can execute a particular command. However, this would either entail information disclosure even on servers (where it matters), or cluttering log files and the administrator's email with failed sudo attempts.

Therefore a compromise was chosen that works for use cases 1 and 2, breaks use case 3, and still behaves sanely for upgrades from Debian and Warty: an administrative menu entry is shown if the user is in the 'admin' group or this group does not exist at all.

Implementation

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. A desktop file is hidden IFF:

  • group admin exists

  • the user is not in admin

  • X-KDE-SubstituteUID == true

update-notifier

update-notifier needs to hide the icon under the same conditions as stated above.

Data preservation and migration

No configuration files are changed by this spec.

Outstanding issues

  • In some cases users would want to have an ability to run a priviledged programm while running an account that does not have sudo configured. Usually this would be done using sudo. Maybe, if the user cann't run a command, it should be moved to a separate menu and if it is run from that menu it would ask for root pasword, while also allowing to enter username/password of another user that has sudo configured for a particular command. The password must be checked before checking the ability to run a particular command, for security reasons.

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