Re: group nvram
On Wed, Mar 18, 2009 at 9:38 PM, Bastien ROUCARIES
> On Wed, Mar 18, 2009 at 7:23 PM, Bastien ROUCARIES
> <email@example.com> wrote:
>> On Wed, Mar 18, 2009 at 7:13 PM, Marco d'Itri <firstname.lastname@example.org> wrote:
>>> On Mar 18, Steve Langasek <email@example.com> 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
>>> rdma (infiniband devices)
> about this group:
> 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