linux-kernel - Re: [PATCH] Input: document the proper usage of EV_KEY and KEY

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: <d120d5000706010704h71c817a9p55e0bba5d54efd3f@mail.gmail.com>
Date:	Fri, 1 Jun 2007 10:04:56 -0400
From:	"Dmitry Torokhov" <dmitry.torokhov@...il.com>
To:	"Matthew Garrett" <mjg59@...f.ucam.org>
Cc:	"Henrique de Moraes Holschuh" <hmh@....eng.br>,
	"Richard Hughes" <hughsient@...il.com>, linux-acpi@...r.kernel.org,
	linux-input@...ey.karlin.mff.cuni.cz, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Input: document the proper usage of EV_KEY and KEY_UNKNOWN

On 6/1/07, Matthew Garrett <mjg59@...f.ucam.org> wrote:
> On Fri, Jun 01, 2007 at 12:37:58AM -0400, Dmitry Torokhov wrote:
> > On Friday 01 June 2007 00:08, Matthew Garrett wrote:
> > > If you let users alter the kernel keymap, then you need to implement
> > > support for resetting the kernel keymap on exit. Otherwise it's a
> > > trivial DoS.
> > >
> >
> > You already do - do you let your users play games with force-feedback
> > joysticks? To load force feedback effect you need write permissions for
> > corresponding event device.
>
> That's much less of a problem, especially since (realistically) any
> force feedback-aware application will reset the values on first use.
> That's not the case for the keymap.
>

What I am trying to say - there already EVIOCSKEYCODE ioctl in the
kernel. And for force feedback devices to work you need to nable
writing to corresponding /dev/input/eventX thus opening possibility to
alter the keymap table. I guess you coudl analyze capabilities of a
device and only relax permissions for devices that have FF...

Anyway, I think that we don't want ordinary users to alter hardware
keymapping, it should indeed be priveleged operation done by box's
administrator. Hopefully the infrastructure (hal/udev/whatever) will
be able to load proper keymap at boot time so even that is not needed.

Why I think using kernel remapping_in addition_ to X remapping is better:

- X remapping only works in X. Even if you say that major
distributions presently moved all logic in X but I don't think it is
the only true way (in fact I think that some of it should run as
standalone daemons; if I press power button I want my box to shut down
even if I happen to be at text console. Same goes for sleep).

- KEY_PROG* are assigned somewhat randomly across devices, with
KEY_PROG1 matching FN-F1 on laptop multimedia key and also on one of
the buttons on that remote control that manufacturers tend to supply
with those "desktop replacement" laptops. Remapping them in X will not
satisfy user. However remappig into actions (like KEY_EJECTCD) on
kernel level solves this. From user perspective there isn't really any
difference - he assigns an action to a key.

- Having devices generate KEY_UNKNOWN with a nice dialog box
explaining what had happened will alert users of existance of events
generated by such (esp. if they are unlabeled and hit by accident).
For labeled keys we may ask user to submit necessary data to one of
the projects (HAL?) to add to the database of devices/models/keymaps.
If we were generating KEY_PROG1 more sophisticated users would simply
remap the keys and move on without telling anybody.

- If using X remapping alone every user will have to repeat the task
of mapping keycodes. In case when there are labels on the keyboard
(but the kernel does not know what it is) that setup is likely to be
identical for most users on the box. I venture to say that even with
unlabeled keys the setup will be identical - first user will influence
the rest.

The biggest cons for KEY_UNKNOWN + scancode is that presently we do
not have the code to iteract with user.

> > > The standard setup in an office environment is likely to be
> > > multiuser.
> >
> > Huh? In my limited experience everyone in the office gets its own box.
> > And I am not talking about software shop.
>
> Standard is that everyone gets their own machine, but usually everyone
> has an account on all of them.

Which is never used (except remotely)...

-- 
Dmitry
-
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/