[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: group nvram



On Wed, Mar 18, 2009 at 9:38 PM, Bastien ROUCARIES
<roucaries.bastien@gmail.com> wrote:
> On Wed, Mar 18, 2009 at 7:23 PM, Bastien ROUCARIES
> <roucaries.bastien@gmail.com> wrote:
>> On Wed, Mar 18, 2009 at 7:13 PM, Marco d'Itri <md@linux.it> wrote:
>>> On Mar 18, Steve Langasek <vorlon@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
>


Reply to: