DevicePermissions
|
⇤ ← Revision 1 as of 2008-05-26 15:56:17
Size: 4925
Comment: create spec
|
Size: 4901
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 25: | Line 25: |
| generally, privileges), since these will/might still be required by system daemons. The main concern here are groups which users are put into. |
generally, privileges), since these will/might still be required by system daemons. The main concern here are groups which users are put into. |
| Line 30: | Line 30: |
| the majority of the current user specific device access groups can be replaced by a simple Console``Kit/automatic ACL solution. This applies to devices which cannot sensibly be used from a remote login, e. g. `audio` and `video`, and where it does not make a lot of sense to not give those privileges to locally active users. |
the majority of the current user specific device access groups can be replaced by a simple Console``Kit/automatic ACL solution. This applies to devices which cannot sensibly be used from a remote login, e. g. `audio` and `video`, and where it does not make a lot of sense to not give those privileges to locally active users. |
| Line 37: | Line 37: |
| default, and/or are generally applicable to remote sessions as well are described and maintained in Policy``Kit. That way, the more fine-grained PK privileges can be assigned to users, groups, people on consoles, or other dynamic sets. |
default, and/or are generally applicable to remote sessions as well are described and maintained in Policy``Kit. That way, the more fine-grained PK privileges can be assigned to users, groups, people on consoles, or other dynamic sets. |
Summary
We will replace the remaining system groups which control device access and which desktop users are put into by default by more dynamic, flexible, and better designed ConsoleKit/PolicyKit privilege rules.
Release Note
TODO
Rationale
NSS Groups should solely be for grouping people. They should not be used extensively to assign privileges to local device permissions, since this leads to proliferation of more and more groups, difficulties with maintaining those groups, and even more difficulties with maintaining them centrally in e. g. NIS or LDAP.
Design
- We will not generally abolish groups for device access (or, more generally, privileges), since these will/might still be required by system daemons. The main concern here are groups which users are put into.
Similarly to the already deprecated plugdev and scanner groups, the majority of the current user specific device access groups can be replaced by a simple ConsoleKit/automatic ACL solution. This applies to devices which cannot sensibly be used from a remote login, e. g. audio and video, and where it does not make a lot of sense to not give those privileges to locally active users.
- Privileges which should not be granted to all local users by default, and/or are generally applicable to remote sessions as well
are described and maintained in PolicyKit. That way, the more fine-grained PK privileges can be assigned to users, groups, people on consoles, or other dynamic sets.
Implementation
Replacements of current default groups
cdrom, floppy: The only reason why we still put users into these groups is that our
installer creates /etc/fstab entries for CD-ROMs by default. This needs to stop at least for desktops, which will also help to overcome problems with changing device names (E. g. an upgrade from 7.10 to 8.04 changed /dev/hdc to /dev/scd0, which broke CD-ROM access). With the fstab entry gone, the existing desktop automounting infrastructure (through gnome-mount and hal) is sufficient to provide floppy and CD-ROM access to local users on foreground consoles.
audio: Hal already assigns dynamic ACLs to sound devices in Ubuntu 8.04 (see
/usr/share/PolicyKit/policy/org.freedesktop.hal.device-access.policy), so this can be dropped without any problem.
video: This group is currently used for the following devices:
/dev/agpgart: At the moment there is no obvious reason why users should have access to this in the first place. X.org runs as root and on the client side access to this is not needed.
/dev/dv1394*, /dev/video1934*, Video4Linux devices, DVB
- devices: already covered by Hal/CK in Ubuntu 8.04
(org.freedesktop.hal.device-access.policy)
- devices: already covered by Hal/CK in Ubuntu 8.04
dialout, dip: TODO
fuse: This group is currently a bad workaround for a poor security
design/excuse. fusermount can be abused for some easy local DoS. A better design would be to provide a dbus activation backend (running as root) to call fusermount, and control access to it with PolicyKit rules (proposed: available to all local consoles).
The long-term goal is to drop the fuse group completely, but that will take a while until all fuse applications are ported.
lpadmin: TBD
adm: This needs to stay around, since this group controls readability of system log files, without a program being in between. It is an LSB standard group, too.
Other devices
- fingerprint readers: Current hardy allows access to those over a custom PK rule in hal. Scott says that this should not be necessary. TODO: get further comments from Scott
Console logins
In order for text console logins to succeed and get similar privileges as X11 logins, the libpam-ck-connector package should be installed by default and set up so that VT logins get a ConsoleKit session.
In addition to installing the package, the PAM module must be activated in /etc/pam.d/common-session:
{{{ session optional pam_ck_connector.so }}}
This does not interfere with gdm's and kdm's built-in support for ConsoleKit. To the contrary, this unbreaks local device access for people who use a nonstandard login manager.
Migration
We will not automatically remove system groups, or any user membership, since we cannot make assumptions about how they are currently being used and customized.
Test/Demo Plan
TODO
Outstanding Issues
- PCMCIA smartcard readers have been inaccessible in all Ubuntu releases so far. Implementing this spec is not a regresion for those, but making those work properly requires someone with the hardware.
DesktopTeam/Specs/Intrepid/DevicePermissions (last edited 2008-09-25 15:51:48 by p579DE8FB)