lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20060718165039.04D50214B6B@muan.mtu.ru>
Date:	Tue, 18 Jul 2006 20:50:36 +0400
From:	Andrey Borzenkov <arvidjaar@...l.ru>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	anssi.hannula@...il.com, linux-kernel@...r.kernel.org
Subject: Re: input/eventX permissions, force feedback

Dmitry Torokhov wrote:

> Hi Anssi,
> 
> On 7/18/06, Anssi Hannula <anssi.hannula@...il.com> wrote:
>> Currently most distributions have /dev/input/event* strictly as 0600
>> root:root or 0640 root:root. The user logged in will not have rights to
>> the device, unlike /dev/input/js*, as he could read all passwords from
>> the keyboard device.
>>
>> This is a problem, because /dev/input/event* is used for force feedback
>> and should therefore be user-accessible.
>>
>> I can think of the following solutions to this problem:
>>
>> 1. Some creative udev rule to chmod /dev/input/event* less strictly when
>> it has a /dev/input/js* and is thus a gaming device.
>>
>> 2. Some creative udev rule to chmod /dev/input/event* more strictly when
>> it is a keyboard.
>>
>> 3. Have another force feedback interface also in /dev/input/js*.
>>
> 
> You can do it in udev looking either at MODALIAS or at EV and ABS
> environment variables. I think it is pretty safe to say that a device
> with EV_ABS, EV_FF, ABS_X and ABS_Y is a force-feedback joystick-type
> device and not a keyboard.
> 

You could also have udev create specific symlink for such devices,
say /dev/input/ff* and make a rule for pam_console to change their
permissions. That is finally what is done e.g. for CD-ROMs (cdrom ->
hdc/sr0)

-andrey

> Another solution would be to relax permissions if user is also console
> owner (home box installation).
> 
> One thing is for sure - I do not like #3 at all ;)
> 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ