public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andries Brouwer <Andries.Brouwer@cwi.nl>
To: 7eggert@gmx.de
Cc: Andries Brouwer <Andries.Brouwer@cwi.nl>,
	linux-kernel@vger.kernel.org, akpm@osdl.org, horms@verge.net.au
Subject: Re: security / kbd
Date: Sat, 3 Dec 2005 02:34:55 +0100	[thread overview]
Message-ID: <20051203013455.GB24760@apps.cwi.nl> (raw)
In-Reply-To: <E1EiLA5-0001VE-64@be1.lrz>

On Sat, Dec 03, 2005 at 01:21:51AM +0100, Bodo Eggert wrote:

> > On the other hand, I am told that recent kernels restrict the use of
> > loadkeys to root. If so, an unfortunate choice. People want to switch
> > unicode support on/off, or go from/to a dvorak keymap.
> 
> It's global, and it can be done remotely. Therefore you can either have
> remote logins or a secure console.

Let me repeat what I said and you snipped:
If there is a security problem, then it should be solved in user space.

Some people actually use the console. They want to be able to reassign
CapsLock, set their own function keys, set dvorak keymap etc.
It is a bad idea to restrict that functionality to root.

There are a thousand things one can do to put the kernel keyboard/console
in an interesting state. The solution is to have init/getty/login reset
state to a useful initial state. Not to have the kernel forbid one
to change the settings of the very keyboard one is typing on.

Andries

> The correct fix would be binding the keymap to the current tty only,
> resetting the console if it gets closed and not allowing init to reuse
> it unless it's closed. If you do this, you'll want a default setting, too.

Yes.

> YANI: Root should be able to set a coloured border indicating that it's
> really the getty/login process asking for the user prompt/password.

Didnt I show a "bleeding edge" patch some April 1st or so?
At least I had a red border on some console a few years ago.
The patch must still exist somewhere. I seem to recall that Paul Gortmaker
submitted a somewhat more general version.

---

marc.theaimsgroup.com tells me that the change was due to horms and akpm.
Let me cc them and see whether they have reasons why this had to be done
in kernel space.

  reply	other threads:[~2005-12-03  1:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <5f6Fp-1ZB-11@gated-at.bofh.it>
2005-12-03  0:21 ` security / kbd Bodo Eggert
2005-12-03  1:34   ` Andries Brouwer [this message]
2005-12-03  2:11     ` Bodo Eggert
2005-12-03  2:39       ` Andries Brouwer
2005-12-03  5:33         ` Bodo Eggert
2005-12-03 14:46           ` Andries Brouwer
2005-12-03 17:19             ` Bodo Eggert
2005-12-03 18:11               ` Andries Brouwer
2005-12-03 18:48                 ` Bodo Eggert
2005-12-03 21:43                   ` Andries Brouwer
2005-12-02  0:08 Andries Brouwer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051203013455.GB24760@apps.cwi.nl \
    --to=andries.brouwer@cwi.nl \
    --cc=7eggert@gmx.de \
    --cc=akpm@osdl.org \
    --cc=horms@verge.net.au \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox