On Wed, Mar 18, 2009 at 9:38 PM, Bastien ROUCARIES <roucaries.bast...@gmail.com> wrote: > 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.
Done under http://wiki.debian.org/SystemGroups Please contribute > Regards > > Bastien > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
