On Wed, Mar 18, 2009 at 7:23 PM, Bastien ROUCARIES <roucaries.bast...@gmail.com> wrote: > On Wed, Mar 18, 2009 at 7:13 PM, Marco d'Itri <m...@linux.it> wrote: >> On Mar 18, Steve Langasek <vor...@debian.org> wrote: >> >>> A peek at the source says it uses /proc/acpi/ibm/light. >> Other people told me that they believe that nowadays all modern >> thinkpads use a kernel driver. >> >> This is the complete list of groups which I'd rather stop using: >> >> fuse (I have no idea about how FUSE works) > > This group is important, fuse could lead to local dos. > >> kvm (what are the security implications of access to /dev/kvm?) > > Idem local dos due to pinned memory > >> nvram >> rdma (infiniband devices)
about this group: https://bugs.launchpad.net/ubuntu/+source/udev/+bug/256216 Having 0666 permissions would not necessarily be a bad idea, but the consensus among other distributions is to limit RDMA access to an "rdma" group so that administrators have some control over who gets direct hardware access (even though in theory it is safe for anyone, there is the possibility of untrusted users consuming network bandwidth at least). Also, RDMA often requires increasing the amount of locked memory allowed in /etc/security/limits.conf, and doing that by group "rdma" is convenient as well. >> scanner (do SCSI scanners still exist? how are they used?) > > scanner is also used for usb device. > >> tss (TPM devices, do select users have a need to access them?) > > > BTW why do you hate this group? They are here in order to give fine > gained privilege, that is the basis of good security. > >> The other major reason to do this is that non-standard groups which are >> not in /etc/groups break some systems which use LDAP. > > Add this group to standard ldap. Acces to harware should be limited by > policy, and group is a good policy. And a catch all group > coulddolocaldos is not really a good policy. BTW instead of arguing about group and something like this could we create a wiki page on debian wiki about justification of group. Therefore purpose of every system group will documented. With exemple of security concern. Regards Bastien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org