Debian Bug report logs - #334113
linux-image-2.6.12-1-powerpc: kernel allows loadkeys to be used by any user, allowing for local root compromise

version graph

Package: linux-image-2.6.12-1-powerpc; Maintainer for linux-image-2.6.12-1-powerpc is (unknown);

Reported by: Rudolf Polzer <debian-ne@durchnull.de>

Date: Sat, 15 Oct 2005 17:03:05 UTC

Severity: critical

Tags: security

Found in version linux-image-2.6.12-1-powerpc/2.6.12-10

Fixed in version linux-2.6/2.6.14-4

Done: Frederik Schüler <fs@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, debian-ne@durchnull.de, Debian Security Team <team@security.debian.org>, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#334113; Package linux-image-2.6.12-1-powerpc. Full text and rfc822 format available.

Acknowledgement sent to Rudolf Polzer <debian-ne@durchnull.de>:
New Bug report received and forwarded. Copy sent to debian-ne@durchnull.de, Debian Security Team <team@security.debian.org>, Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Rudolf Polzer <debian-ne@durchnull.de>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: linux-image-2.6.12-1-powerpc: kernel allows loadkeys to be used by any user, allowing for local root compromise
Date: Sat, 15 Oct 2005 18:03:31 +0200
Package: linux-image-2.6.12-1-powerpc
Version: 2.6.12-10
Severity: critical
Tags: security
Justification: root security hole


The non-suid command "loadkeys" can be used by any local user having
console access. It does not just apply to the current virtual console
but to all virtual consoles and its effect persists even after logout.

A proof of concept would be (^V, ^C etc. refer to key presses on the
console):

loadkeys
keycode 15 = F23
string F23 = "^V^C^V^Mecho hello world^V^M"
^D

Then log out and let root login (in a computer pool, you can usually get
an admin to log on as root on a console somehow). The next time he'll
press TAB to complete a file name, he instead will run the shell
command.

Of course, the shell command could be more evil, e.g. add a line to
/etc/passwd, clear the screen to make it less obvious, sync and write
stuff to /dev/mem to cause a kernel crash so that most people would not
suspect anything but a hardware fault. A demo exploit adding a line to
the password file, clearing the screen and logging out exists in form of
a shell script.

As a solution, I propose that the loadkeys command (or more exactly, the
kernel interface it uses) should be restricted to root and instead one
could add a suid wrapper for loadkeys that only allows the system-wide
keymaps to be loaded. The old behaviour could still be made selectable
using a procfs file.

If the last modification time of the manual page of loadkeys is true,
this bug exists in the Linux kernel at least since 1997. However, the
BUGS section of the manpage does not hint that the loadkeys command
can even be used as a root compromise and not just for stuff like
unbinding all keys.

Plus, it might be good to have a way to disable chvt for non-root users.
Using chvt, a malicious user could do the same thing in an X session:
remap Backspace to another key, handle Ctrl-Alt-Backspace by chvt 1;
chvt 7 (so the video mode switches) and showing a fake login manager on
the X display. If chvt were not possible for mere mortals, the admin
would be able to disable all possible video mode switching caused by X
applications (like xrandr, xvidmode, dpms) in the xorg.conf file so that
he finally knows: if Ctrl-Alt-Backspace caused video mode switching, the
resulting login screen is genuine.

Another solution would be a keymap-invariant non-remappable "zap" key
combination with the functionality of Alt-SysRq-K - but on an X screen,
it should tell the X server to exit instead of kill -9ing it so that the
video mode gets restored. And it should be able to make a kernel support
it without adding all of the other "Magic SysRq Key" features. Of
course, it should lock the keymap until the user tells the system to
unlock it again.

Or, even better: a "root login key". That is, something unremappable
that causes a new VT to be created with a login prompt for root - and
while this VT is active, the keymap should be locked to the system-wide
standard keymap. Ideally, that "root login key" should also work from X
and maybe even when the X server has crashed.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.12-1-powerpc
Locale: LANG=C, LC_CTYPE=de_DE@euro (charmap=ISO-8859-15)

Versions of packages linux-image-2.6.12-1-powerpc depends on:
ii  coreutils [fileutils]         5.2.1-2.1  The GNU core utilities
ii  initrd-tools                  0.1.82     tools to create initrd image for p
ii  mkvmlinuz                     15         create a kernel to boot a PowerPC 
ii  module-init-tools             3.2-pre9-2 tools for managing Linux kernel mo

linux-image-2.6.12-1-powerpc recommends no packages.

-- no debconf information



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#334113; Package linux-image-2.6.12-1-powerpc. Full text and rfc822 format available.

Acknowledgement sent to Horms <horms@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #10 received at 334113@bugs.debian.org (full text, mbox):

From: Horms <horms@debian.org>
To: Rudolf Polzer <debian-ne@durchnull.de>, 334113@bugs.debian.org
Subject: Re: Bug#334113: linux-image-2.6.12-1-powerpc: kernel allows loadkeys to be used by any user, allowing for local root compromise
Date: Tue, 18 Oct 2005 13:16:58 +0900
Thanks, that seems like a genuine problem, I am forwarding it
upstream for consideration as it is not immediately apparent to me 
what the best solution is.

-- 
Horms



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#334113; Package linux-image-2.6.12-1-powerpc. Full text and rfc822 format available.

Acknowledgement sent to Horms <horms@verge.net.au>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #15 received at 334113@bugs.debian.org (full text, mbox):

From: Horms <horms@verge.net.au>
To: linux-kernel@vger.kernel.org
Cc: Rudolf Polzer <debian-ne@durchnull.de>, 334113@bugs.debian.org, Alastair McKinstry <mckinstry@debian.org>, security@kernel.org, team@security.debian.org, secure-testing-team@lists.alioth.debian.org
Subject: kernel allows loadkeys to be used by any user, allowing for local root compromise
Date: Tue, 18 Oct 2005 13:41:48 +0900
On Sat, Oct 15, 2005 at 06:03:31PM +0200, Rudolf Polzer wrote:
> Package: linux-image-2.6.12-1-powerpc
> Version: 2.6.12-10
> Severity: critical
> Tags: security
> Justification: root security hole
> 
> 
> The non-suid command "loadkeys" can be used by any local user having
> console access. It does not just apply to the current virtual console
> but to all virtual consoles and its effect persists even after logout.
> 
> A proof of concept would be (^V, ^C etc. refer to key presses on the
> console):
> 
> loadkeys
> keycode 15 = F23
> string F23 = "^V^C^V^Mecho hello world^V^M"
> ^D
> 
> Then log out and let root login (in a computer pool, you can usually get
> an admin to log on as root on a console somehow). The next time he'll
> press TAB to complete a file name, he instead will run the shell
> command.
> 
> Of course, the shell command could be more evil, e.g. add a line to
> /etc/passwd, clear the screen to make it less obvious, sync and write
> stuff to /dev/mem to cause a kernel crash so that most people would not
> suspect anything but a hardware fault. A demo exploit adding a line to
> the password file, clearing the screen and logging out exists in form of
> a shell script.
> 
> As a solution, I propose that the loadkeys command (or more exactly, the
> kernel interface it uses) should be restricted to root and instead one
> could add a suid wrapper for loadkeys that only allows the system-wide
> keymaps to be loaded. The old behaviour could still be made selectable
> using a procfs file.
> 
> If the last modification time of the manual page of loadkeys is true,
> this bug exists in the Linux kernel at least since 1997. However, the
> BUGS section of the manpage does not hint that the loadkeys command
> can even be used as a root compromise and not just for stuff like
> unbinding all keys.
> 
> Plus, it might be good to have a way to disable chvt for non-root users.
> Using chvt, a malicious user could do the same thing in an X session:
> remap Backspace to another key, handle Ctrl-Alt-Backspace by chvt 1;
> chvt 7 (so the video mode switches) and showing a fake login manager on
> the X display. If chvt were not possible for mere mortals, the admin
> would be able to disable all possible video mode switching caused by X
> applications (like xrandr, xvidmode, dpms) in the xorg.conf file so that
> he finally knows: if Ctrl-Alt-Backspace caused video mode switching, the
> resulting login screen is genuine.
> 
> Another solution would be a keymap-invariant non-remappable "zap" key
> combination with the functionality of Alt-SysRq-K - but on an X screen,
> it should tell the X server to exit instead of kill -9ing it so that the
> video mode gets restored. And it should be able to make a kernel support
> it without adding all of the other "Magic SysRq Key" features. Of
> course, it should lock the keymap until the user tells the system to
> unlock it again.
> 
> Or, even better: a "root login key". That is, something unremappable
> that causes a new VT to be created with a login prompt for root - and
> while this VT is active, the keymap should be locked to the system-wide
> standard keymap. Ideally, that "root login key" should also work from X
> and maybe even when the X server has crashed.

Hi,

I recently received the following message through the debian Bug tracker.

http://bugs.debian.org/334113

In a nuthsell it raises concernes about the effects of giving
users access to VT ioctls and outlines a potential attack 
using loadkeys to execute commands as root.

I took a very brief look over it, and the concern does seem valid to me.
Most of the VT ioctls are only garded by the following permissions,
the ioctl in question, which I believe is KDSKBSENT, is no exception:

drivers/char/vt_ioctl.c: vt_ioctl(): line 377

        /*
         * To have permissions to do most of the vt ioctls, we either
         * have
         * to be the owner of the tty, or have CAP_SYS_TTY_CONFIG.
         */
        perm = 0;
        if (current->signal->tty == tty || capable(CAP_SYS_TTY_CONFIG))
                perm = 1;


A simple fix for this might be just checking for capable(CAP_SYS_TTY_CONFIG)
in do_kdgkb_ioctl(), which effects KDSKBSENT. This more restrictive
approach is probably appropriate for many of the other ioctls that set
VT parameters.

However, the changes will still affect all consoles and be persistant
after the user logs out of the console. It would seem more logical to
have the state apply only to the current console, and only for the
duration of the session. The latter could be handled in user-space if
the ioctls were privelaged. But I suspect adding the former might be
somewhat difficult.

The same kind of issue also seems to be relevant to many of the other VT
ioctls.

I'm not really familiar enough with the code to comment more, though I
am happy to code-up ideas if people can point me in the right direction.

-- 
Horms



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#334113; Package linux-image-2.6.12-1-powerpc. Full text and rfc822 format available.

Acknowledgement sent to Andrew Morton <akpm@osdl.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #20 received at 334113@bugs.debian.org (full text, mbox):

From: Andrew Morton <akpm@osdl.org>
To: Horms <horms@verge.net.au>
Cc: linux-kernel@vger.kernel.org, security@kernel.org, secure-testing-team@lists.alioth.debian.org, 334113@bugs.debian.org, debian-ne@durchnull.de, mckinstry@debian.org, team@security.debian.org
Subject: Re: [Security] kernel allows loadkeys to be used by any user, allowing for local root compromise
Date: Mon, 17 Oct 2005 23:52:11 -0700
Horms <horms@verge.net.au> wrote:
>
> drivers/char/vt_ioctl.c: vt_ioctl(): line 377
> 
>          /*
>           * To have permissions to do most of the vt ioctls, we either
>           * have
>           * to be the owner of the tty, or have CAP_SYS_TTY_CONFIG.
>           */
>          perm = 0;
>          if (current->signal->tty == tty || capable(CAP_SYS_TTY_CONFIG))
>                  perm = 1;
> 
> 
>  A simple fix for this might be just checking for capable(CAP_SYS_TTY_CONFIG)
>  in do_kdgkb_ioctl(), which effects KDSKBSENT. This more restrictive
>  approach is probably appropriate for many of the other ioctls that set
>  VT parameters.

I briefly discussed this with Alan and he agreed that that's a reasonable
approach.

I'll stick the below in -mm, see what breaks.

--- devel/drivers/char/vt_ioctl.c~setkeys-needs-root	2005-10-17 23:50:37.000000000 -0700
+++ devel-akpm/drivers/char/vt_ioctl.c	2005-10-17 23:51:43.000000000 -0700
@@ -192,6 +192,9 @@ do_kdgkb_ioctl(int cmd, struct kbsentry 
 	int i, j, k;
 	int ret;
 
+	if (!capable(CAP_SYS_TTY_CONFIG))
+		return -EPERM;
+
 	kbs = kmalloc(sizeof(*kbs), GFP_KERNEL);
 	if (!kbs) {
 		ret = -ENOMEM;
_




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#334113; Package linux-image-2.6.12-1-powerpc. Full text and rfc822 format available.

Acknowledgement sent to Horms <horms@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #25 received at 334113@bugs.debian.org (full text, mbox):

From: Horms <horms@debian.org>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, security@kernel.org, secure-testing-team@lists.alioth.debian.org, 334113@bugs.debian.org, debian-ne@durchnull.de, mckinstry@debian.org, team@security.debian.org
Subject: Re: [Security] kernel allows loadkeys to be used by any user, allowing for local root compromise
Date: Tue, 18 Oct 2005 17:59:10 +0900
On Mon, Oct 17, 2005 at 11:52:11PM -0700, Andrew Morton wrote:
> Horms <horms@verge.net.au> wrote:
> >
> > drivers/char/vt_ioctl.c: vt_ioctl(): line 377
> > 
> >          /*
> >           * To have permissions to do most of the vt ioctls, we either
> >           * have
> >           * to be the owner of the tty, or have CAP_SYS_TTY_CONFIG.
> >           */
> >          perm = 0;
> >          if (current->signal->tty == tty || capable(CAP_SYS_TTY_CONFIG))
> >                  perm = 1;
> > 
> > 
> >  A simple fix for this might be just checking for capable(CAP_SYS_TTY_CONFIG)
> >  in do_kdgkb_ioctl(), which effects KDSKBSENT. This more restrictive
> >  approach is probably appropriate for many of the other ioctls that set
> >  VT parameters.
> 
> I briefly discussed this with Alan and he agreed that that's a reasonable
> approach.

Thanks, thats pretty much what I had in mind. Though I would expect
some minor breakage, at least for people who expect nonsetuid loadkeys
to work. But then again, that is the whole point.

> I'll stick the below in -mm, see what breaks.
> 
> --- devel/drivers/char/vt_ioctl.c~setkeys-needs-root	2005-10-17 23:50:37.000000000 -0700
> +++ devel-akpm/drivers/char/vt_ioctl.c	2005-10-17 23:51:43.000000000 -0700
> @@ -192,6 +192,9 @@ do_kdgkb_ioctl(int cmd, struct kbsentry 
>  	int i, j, k;
>  	int ret;
>  
> +	if (!capable(CAP_SYS_TTY_CONFIG))
> +		return -EPERM;
> +
>  	kbs = kmalloc(sizeof(*kbs), GFP_KERNEL);
>  	if (!kbs) {
>  		ret = -ENOMEM;
> _

-- 
Horms



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#334113; Package linux-image-2.6.12-1-powerpc. Full text and rfc822 format available.

Acknowledgement sent to Krzysztof Halasa <khc@pm.waw.pl>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #30 received at 334113@bugs.debian.org (full text, mbox):

From: Krzysztof Halasa <khc@pm.waw.pl>
To: Horms <horms@verge.net.au>
Cc: linux-kernel@vger.kernel.org, Rudolf Polzer <debian-ne@durchnull.de>, 334113@bugs.debian.org, Alastair McKinstry <mckinstry@debian.org>, security@kernel.org, team@security.debian.org, secure-testing-team@lists.alioth.debian.org
Subject: Re: kernel allows loadkeys to be used by any user, allowing for local root compromise
Date: Tue, 18 Oct 2005 16:42:49 +0200
Horms <horms@verge.net.au> writes:

>> Then log out and let root login (in a computer pool, you can usually get
>> an admin to log on as root on a console somehow). The next time he'll
>> press TAB to complete a file name, he instead will run the shell
>> command.

Why doesn't the intruder just simulate login process (printing "login: "
and "Password:")? That's known and used for ages.

The root user (and any other user) should press the SAK key before
attempting login. It should a) reset terminal to a sane state,
b) terminate and/or disconnect all processes from current tty.

Alternatively, he/she should hw-reset/power-cycle the terminal,
if possible (say, with serial/X-terminal).

OTOH I don't know why ordinary users should be allowed to change key
bindings.

BTW: Not sure about Linux consoles, but in general ESCape sequences
can redefine key bindings as well. That's why SAK/reset is so important.
-- 
Krzysztof Halasa



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#334113; Package linux-image-2.6.12-1-powerpc. Full text and rfc822 format available.

Acknowledgement sent to Rudolf Polzer <debian-ne@durchnull.de>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #35 received at 334113@bugs.debian.org (full text, mbox):

From: Rudolf Polzer <debian-ne@durchnull.de>
To: Krzysztof Halasa <khc@pm.waw.pl>
Cc: Horms <horms@verge.net.au>, linux-kernel@vger.kernel.org, 334113@bugs.debian.org, Alastair McKinstry <mckinstry@debian.org>, security@kernel.org, team@security.debian.org, secure-testing-team@lists.alioth.debian.org
Subject: Re: kernel allows loadkeys to be used by any user, allowing for local root compromise
Date: Tue, 18 Oct 2005 19:16:45 +0200
Scripsis, quam aut quem »Krzysztof Halasa« appellare soleo:
> Horms <horms@verge.net.au> writes:
> 
> >> Then log out and let root login (in a computer pool, you can usually get
> >> an admin to log on as root on a console somehow). The next time he'll
> >> press TAB to complete a file name, he instead will run the shell
> >> command.
> 
> Why doesn't the intruder just simulate login process (printing "login: "
> and "Password:")? That's known and used for ages.
> 
> The root user (and any other user) should press the SAK key before
> attempting login. It should a) reset terminal to a sane state,
> b) terminate and/or disconnect all processes from current tty.

That does not help against the loadkeys issue if the attacking user is still
logged in on another virtual console. Even when tty1 is active, a user owning
tty6 can use loadkeys.

Plus, the Linux SAK does not reset the keyboard mapping. And SAK does not reset
the video mode, so when pressed on X, the terminal video mode is garbled until
reboot (maybe it works fine with some framebuffer drivers, but with the stock
VGA text console, it doesn't). X comes back up fine, but when pressing
Ctrl-Alt-F1, X will restore the video mode it saw on startup - which is the
mode of the previous X server the SAK has killed.

> Alternatively, he/she should hw-reset/power-cycle the terminal,
> if possible (say, with serial/X-terminal).

Well, sometimes you have problems that powercycling would "hide" so you can't
track them down if you powercycle the whole computer every time.

> OTOH I don't know why ordinary users should be allowed to change key
> bindings.

For using foreign languages and keyboard mappings.

But for that a suid wrapper around loadkeys would suffice - most distributions
include more than enough keyboard mapping files already.

> BTW: Not sure about Linux consoles, but in general ESCape sequences
> can redefine key bindings as well. That's why SAK/reset is so important.

If man console_codes is correct, they can't.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#334113; Package linux-image-2.6.12-1-powerpc. Full text and rfc822 format available.

Acknowledgement sent to Krzysztof Halasa <khc@pm.waw.pl>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #40 received at 334113@bugs.debian.org (full text, mbox):

From: Krzysztof Halasa <khc@pm.waw.pl>
To: Rudolf Polzer <debian-ne@durchnull.de>
Cc: Horms <horms@verge.net.au>, linux-kernel@vger.kernel.org, 334113@bugs.debian.org, Alastair McKinstry <mckinstry@debian.org>, security@kernel.org, team@security.debian.org, secure-testing-team@lists.alioth.debian.org
Subject: Re: kernel allows loadkeys to be used by any user, allowing for local root compromise
Date: Tue, 18 Oct 2005 20:41:19 +0200
Rudolf Polzer <debian-ne@durchnull.de> writes:

> That does not help against the loadkeys issue if the attacking user is still
> logged in on another virtual console. Even when tty1 is active, a user owning
> tty6 can use loadkeys.

Sure. The problem is that mappings are shared between VCs but anyway
it's solved by disabling user changes.
I don't think there is a solution here, easier than hardware reset.
As for "server" machines (not simple terminals), physical locking is
critical.

> Well, sometimes you have problems that powercycling would "hide" so you can't
> track them down if you powercycle the whole computer every time.

In security-sensitive instalation, you simply don't expose the computers
to non-admins.

> For using foreign languages and keyboard mappings.

Hope they don't change the keys in the process.
Anyway, most people don't need that nor they need suid-wrapper.

BTW: there are similar problems with serial access: users can play
with termio(s) settings (especially CLOCAL flag) and fake
login/password requests. Unless the getty programs are fixed,
you don't want to connect dial-in modems to a machine with user
accounts. Not a kernel thing, though - Linux has termios locking
for 10+ yrs.
-- 
Krzysztof Halasa



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#334113; Package linux-image-2.6.12-1-powerpc. Full text and rfc822 format available.

Acknowledgement sent to Rudolf Polzer <debian-ne@durchnull.de>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #45 received at 334113@bugs.debian.org (full text, mbox):

From: Rudolf Polzer <debian-ne@durchnull.de>
To: Krzysztof Halasa <khc@pm.waw.pl>
Cc: Horms <horms@verge.net.au>, linux-kernel@vger.kernel.org, 334113@bugs.debian.org, Alastair McKinstry <mckinstry@debian.org>, security@kernel.org, team@security.debian.org, secure-testing-team@lists.alioth.debian.org
Subject: Re: kernel allows loadkeys to be used by any user, allowing for local root compromise
Date: Tue, 18 Oct 2005 22:49:19 +0200
Scripsis, quam aut quem »Krzysztof Halasa« appellare soleo:
> Rudolf Polzer <debian-ne@durchnull.de> writes:
> > That does not help against the loadkeys issue if the attacking user is still
> > logged in on another virtual console. Even when tty1 is active, a user owning
> > tty6 can use loadkeys.
> 
> Sure. The problem is that mappings are shared between VCs but anyway
> it's solved by disabling user changes.
> I don't think there is a solution here, easier than hardware reset.
> As for "server" machines (not simple terminals), physical locking is
> critical.

Of course it is.

However, pool computers like in this case are neither servers nor terminals.
If they were terminals, we would need about 30 servers to handle the load of
100 active students. So they are workstation installations that do most of the
work locally.

> > Well, sometimes you have problems that powercycling would "hide" so you can't
> > track them down if you powercycle the whole computer every time.
> 
> In security-sensitive instalation, you simply don't expose the computers
> to non-admins.

Well, in this case the issue is on pool computers for students. Students SHOULD
be able to access the computers, but not as root.

Currently our workaround is "only su(do) from a ssh session on a 'trusted'
computer".

> > For using foreign languages and keyboard mappings.
> 
> Hope they don't change the keys in the process.

They HAVE to do that, this is the very point of switching the keyboard layout
from German to US, to UK, to French or to whatever.

> Anyway, most people don't need that nor they need suid-wrapper.

Many people here need that, but it's ok for them if it works only in X11 (most
of these users don't even know that text consoles exist).

However, Xorg and XFree86 have about the same problem: you can remap
Ctrl-Alt-Backspace. So it would be good if the SAK also worked there which
would require it to set a "sane" video mode.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#334113; Package linux-image-2.6.12-1-powerpc. Full text and rfc822 format available.

Acknowledgement sent to Moritz Muehlenhoff <jmm@inutil.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #50 received at 334113@bugs.debian.org (full text, mbox):

From: Moritz Muehlenhoff <jmm@inutil.org>
To: Horms <horms@verge.net.au>
Cc: linux-kernel@vger.kernel.org, security@kernel.org, secure-testing-team@lists.alioth.debian.org, 334113@bugs.debian.org, Rudolf Polzer <debian-ne@durchnull.de>, Alastair McKinstry <mckinstry@debian.org>, team@security.debian.org
Subject: Re: [Secure-testing-team] kernel allows loadkeys to be used by any user, allowing for local root compromise
Date: Tue, 18 Oct 2005 23:19:53 +0200
Horms wrote:
> > The non-suid command "loadkeys" can be used by any local user having
> > console access. It does not just apply to the current virtual console
> > but to all virtual consoles and its effect persists even after logout.

This has been assigned CAN-2005-3257.

Cheers,
        Moritz



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#334113; Package linux-image-2.6.12-1-powerpc. Full text and rfc822 format available.

Acknowledgement sent to Anthony DeRobertis <anthony@derobert.net>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #55 received at 334113@bugs.debian.org (full text, mbox):

From: Anthony DeRobertis <anthony@derobert.net>
Cc: Horms <horms@verge.net.au>, security@kernel.org, team@security.debian.org, 334113@bugs.debian.org, linux-kernel@vger.kernel.org, Rudolf Polzer <debian-ne@durchnull.de>, Alastair McKinstry <mckinstry@debian.org>, secure-testing-team@lists.alioth.debian.org
Subject: Re: [Secure-testing-team] Re: kernel allows loadkeys to be used by any user, allowing for local root compromise
Date: Wed, 19 Oct 2005 00:14:10 -0400
Krzysztof Halasa wrote:

> Why doesn't the intruder just simulate login process (printing "login: "
> and "Password:")? That's known and used for ages.

Well, you can configure a single vty to only allow logins from admins.
Then you avoid the fake login problem, but not the loadkeys problem
(since that affects all vtys)



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#334113; Package linux-image-2.6.12-1-powerpc. Full text and rfc822 format available.

Acknowledgement sent to Martin Schulze <joey@infodrom.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #60 received at 334113@bugs.debian.org (full text, mbox):

From: Martin Schulze <joey@infodrom.org>
To: 334113@bugs.debian.org
Subject: CAN-2005-3257 assigned
Date: Wed, 19 Oct 2005 07:58:27 +0200
This one is CAN-2005-3257.

Regards,

	Joey

-- 
Never trust an operating system you don't have source for!

Please always Cc to me when replying to me on the lists.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#334113; Package linux-image-2.6.12-1-powerpc. Full text and rfc822 format available.

Acknowledgement sent to Krzysztof Halasa <khc@pm.waw.pl>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #65 received at 334113@bugs.debian.org (full text, mbox):

From: Krzysztof Halasa <khc@pm.waw.pl>
To: Anthony DeRobertis <anthony@derobert.net>
Cc: unlisted-recipients:; (no To-header on input), Horms <horms@verge.net.au>, security@kernel.org, team@security.debian.org, 334113@bugs.debian.org, linux-kernel@vger.kernel.org, Rudolf Polzer <debian-ne@durchnull.de>, Alastair McKinstry <mckinstry@debian.org>, secure-testing-team@lists.alioth.debian.org
Subject: Re: [Secure-testing-team] Re: kernel allows loadkeys to be used by any user, allowing for local root compromise
Date: Wed, 19 Oct 2005 13:00:45 +0200
Anthony DeRobertis <anthony@derobert.net> writes:

> Well, you can configure a single vty to only allow logins from admins.
> Then you avoid the fake login problem, but not the loadkeys problem
> (since that affects all vtys)

Just a guess... Can you use loadkeys to change keys used for switching VTs?
I would investigate switchvt (or how is it named) too.
-- 
Krzysztof Halasa



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#334113; Package linux-image-2.6.12-1-powerpc. Full text and rfc822 format available.

Acknowledgement sent to Krzysztof Halasa <khc@pm.waw.pl>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #70 received at 334113@bugs.debian.org (full text, mbox):

From: Krzysztof Halasa <khc@pm.waw.pl>
To: Rudolf Polzer <debian-ne@durchnull.de>
Cc: Horms <horms@verge.net.au>, linux-kernel@vger.kernel.org, 334113@bugs.debian.org, Alastair McKinstry <mckinstry@debian.org>, security@kernel.org, team@security.debian.org, secure-testing-team@lists.alioth.debian.org
Subject: Re: kernel allows loadkeys to be used by any user, allowing for local root compromise
Date: Wed, 19 Oct 2005 13:18:32 +0200
Rudolf Polzer <debian-ne@durchnull.de> writes:

> However, pool computers like in this case are neither servers nor terminals.
> If they were terminals, we would need about 30 servers to handle the load of
> 100 active students. So they are workstation installations that do most of
> the
> work locally.

Ok. So they are exposed to known attacks with quite high probability.
This might be acceptable (as they are student machines) but not secure.

>> Hope they don't change the keys in the process.
>
> They HAVE to do that,

Well, I meant physical keys to match them to loaded keymaps :-)

> Many people here need that, but it's ok for them if it works only in X11
> (most
> of these users don't even know that text consoles exist).

I see. X11 is another story, though.

> However, Xorg and XFree86 have about the same problem: you can remap
> Ctrl-Alt-Backspace. So it would be good if the SAK also worked there which
> would require it to set a "sane" video mode.

I assume that one can notice that Ctrl-Alt-Backspace doesn't work,
and stop there. I think SAK/X11 video mode issue is possible to fix,
though.
-- 
Krzysztof Halasa



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#334113; Package linux-image-2.6.12-1-powerpc. Full text and rfc822 format available.

Acknowledgement sent to Rudolf Polzer <debian-ne@durchnull.de>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #75 received at 334113@bugs.debian.org (full text, mbox):

From: Rudolf Polzer <debian-ne@durchnull.de>
To: Krzysztof Halasa <khc@pm.waw.pl>
Cc: Horms <horms@verge.net.au>, linux-kernel@vger.kernel.org, 334113@bugs.debian.org, Alastair McKinstry <mckinstry@debian.org>, security@kernel.org, team@security.debian.org, secure-testing-team@lists.alioth.debian.org
Subject: Re: kernel allows loadkeys to be used by any user, allowing for local root compromise
Date: Wed, 19 Oct 2005 15:23:26 +0200
Scripsis, quam aut quem »Krzysztof Halasa« appellare soleo:
> Rudolf Polzer <debian-ne@durchnull.de> writes:
> > However, pool computers like in this case are neither servers nor
> > terminals.  If they were terminals, we would need about 30 servers to
> > handle the load of 100 active students. So they are workstation
> > installations that do most of the work locally.
> 
> Ok. So they are exposed to known attacks with quite high probability.

Which others? Are there other places that assume only trusted users can access
the console?

> >> Hope they don't change the keys in the process.
> >
> > They HAVE to do that,
> 
> Well, I meant physical keys to match them to loaded keymaps :-)

;)

> > However, Xorg and XFree86 have about the same problem: you can remap
> > Ctrl-Alt-Backspace. So it would be good if the SAK also worked there which
> > would require it to set a "sane" video mode.
> 
> I assume that one can notice that Ctrl-Alt-Backspace doesn't work,
> and stop there.

Not if a malicious X program does "chvt 1; chvt 7" when Ctrl-Alt-Backspace is
pressed.

> I think SAK/X11 video mode issue is possible to fix, though.

It would require a video driver that can actually reset the video mode.
Framebuffer drivers usually can do that. For the standard VGA text mode, at
least savetextmode/restoretextmode from svgalib don't work on the graphics
cards I have.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#334113; Package linux-image-2.6.12-1-powerpc. Full text and rfc822 format available.

Acknowledgement sent to Krzysztof Halasa <khc@pm.waw.pl>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #80 received at 334113@bugs.debian.org (full text, mbox):

From: Krzysztof Halasa <khc@pm.waw.pl>
To: Rudolf Polzer <debian-ne@durchnull.de>
Cc: Horms <horms@verge.net.au>, linux-kernel@vger.kernel.org, 334113@bugs.debian.org, Alastair McKinstry <mckinstry@debian.org>, security@kernel.org, team@security.debian.org, secure-testing-team@lists.alioth.debian.org
Subject: Re: kernel allows loadkeys to be used by any user, allowing for local root compromise
Date: Wed, 19 Oct 2005 21:32:53 +0200
Rudolf Polzer <debian-ne@durchnull.de> writes:

>> Ok. So they are exposed to known attacks with quite high probability.
>
> Which others? Are there other places that assume only trusted users can
> access
> the console?

Probably: BIOS booting, messing with computer cases (are the computers
in locked room and only kbds/monitors/mouses are accessible?), sniffing
keyboard cables (all other passwords if not root's), physical damage
to the computer hardware (some kind of DoS).

Still, may be adequate for student room.

>> I assume that one can notice that Ctrl-Alt-Backspace doesn't work,
>> and stop there.
>
> Not if a malicious X program does "chvt 1; chvt 7" when Ctrl-Alt-Backspace is
> pressed.

With correct timing, possibly. Depends on how the graphics driver starts
and switches from text mode. There might be noticeable differences.

> It would require a video driver that can actually reset the video mode.
> Framebuffer drivers usually can do that. For the standard VGA text mode, at
> least savetextmode/restoretextmode from svgalib don't work on the graphics
> cards I have.

I think Xserver could terminate gracefully. But it would require changes
to kernel SAK handling I think - not sure if it's worth it, given other
threats.

Another idea: if the machines are ACPI-enabled and have "soft-power"
buttons, one can make use of acpid.
-- 
Krzysztof Halasa



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#334113; Package linux-image-2.6.12-1-powerpc. Full text and rfc822 format available.

Acknowledgement sent to Rudolf Polzer <debian-ne@durchnull.de>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #85 received at 334113@bugs.debian.org (full text, mbox):

From: Rudolf Polzer <debian-ne@durchnull.de>
To: Krzysztof Halasa <khc@pm.waw.pl>
Cc: Horms <horms@verge.net.au>, linux-kernel@vger.kernel.org, 334113@bugs.debian.org, Alastair McKinstry <mckinstry@debian.org>, security@kernel.org, team@security.debian.org, secure-testing-team@lists.alioth.debian.org
Subject: Re: kernel allows loadkeys to be used by any user, allowing for local root compromise
Date: Wed, 19 Oct 2005 22:24:58 +0200
Scripsis, quam aut quem »Krzysztof Halasa« appellare soleo:
> Rudolf Polzer <debian-ne@durchnull.de> writes:
> 
> >> Ok. So they are exposed to known attacks with quite high probability.
> >
> > Which others? Are there other places that assume only trusted users can
> > access
> > the console?
> 
> Probably: BIOS booting,

Locked. And these boards don't even have the wide-spread "boot from USB even if
system boot up sequence states otherwise" bug. Probably just because they do
not support booting from USB, though.

> messing with computer cases (are the computers in locked room and only
> kbds/monitors/mouses are accessible?),

Not locked, but that would be an option - others would notice it if you did
anything weird, however.

> sniffing keyboard cables (all other passwords if not root's),

That's the only thing that might actually work - an inductive device wrapped
around the keyboard cable. But I've never seen those available ready to buy.

> physical damage to the computer hardware (some kind of DoS).

Not interesting. Well, once someone stole a mouse. A dirty old PS/2 mouse with
a ball. Who would steal such a mouse?

> Still, may be adequate for student room.

Right, especially since people would not mess with the hardware. If there are
20 students in a room, would you really do something strange? For example,
nobody even tries to watch porn in these rooms.

> >> I assume that one can notice that Ctrl-Alt-Backspace doesn't work,
> >> and stop there.
> >
> > Not if a malicious X program does "chvt 1; chvt 7" when Ctrl-Alt-Backspace is
> > pressed.
> 
> With correct timing, possibly. Depends on how the graphics driver starts
> and switches from text mode. There might be noticeable differences.

There might be a difference, yes - but there's also a difference in timing if
the system has background load. So nothing to rely upon. Plus we have CRTs that
just get black for some time with some clicking noise - and these CRTs need
quite a long time to start showing a picture after changing the video mode.

> > It would require a video driver that can actually reset the video mode.
> > Framebuffer drivers usually can do that. For the standard VGA text mode, at
> > least savetextmode/restoretextmode from svgalib don't work on the graphics
> > cards I have.
> 
> I think Xserver could terminate gracefully. But it would require changes
> to kernel SAK handling I think - not sure if it's worth it, given other
> threats.
> 
> Another idea: if the machines are ACPI-enabled and have "soft-power"
> buttons, one can make use of acpid.

Yes, good idea, but we already are using it for soft reboot. If people start
using the idea of remapping backspace so others can't kill their screen saver
(and then keep logged on idle for days - a quite typical "DoS" here), the power
button will most probably be remapped from "shutdown -r now" to
"/etc/init.d/kdm restart". We usually don't want to kill some professor's pine
(ugh, they want us to install it) in that case, but rebooting would do that
too.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#334113; Package linux-image-2.6.12-1-powerpc. Full text and rfc822 format available.

Acknowledgement sent to Krzysztof Halasa <khc@pm.waw.pl>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #90 received at 334113@bugs.debian.org (full text, mbox):

From: Krzysztof Halasa <khc@pm.waw.pl>
To: Rudolf Polzer <debian-ne@durchnull.de>
Cc: Horms <horms@verge.net.au>, linux-kernel@vger.kernel.org, 334113@bugs.debian.org, Alastair McKinstry <mckinstry@debian.org>, security@kernel.org, team@security.debian.org, secure-testing-team@lists.alioth.debian.org
Subject: Re: kernel allows loadkeys to be used by any user, allowing for local root compromise
Date: Thu, 20 Oct 2005 00:57:40 +0200
Rudolf Polzer <debian-ne@durchnull.de> writes:

> That's the only thing that might actually work - an inductive device wrapped
> around the keyboard cable. But I've never seen those available ready to buy.

There are simpler designs - it's just a serial line, right? A simple
"dongle" can send data from the keyboard to a notebook. With luck two
wires would do (using parallel port for sampling data).

Anyway I wouldn't count on people's reaction when they see someone doing
something unusual.
-- 
Krzysztof Halasa



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#334113; Package linux-image-2.6.12-1-powerpc. Full text and rfc822 format available.

Acknowledgement sent to Rudolf Polzer <debian-ne@durchnull.de>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #95 received at 334113@bugs.debian.org (full text, mbox):

From: Rudolf Polzer <debian-ne@durchnull.de>
To: Krzysztof Halasa <khc@pm.waw.pl>
Cc: Horms <horms@verge.net.au>, linux-kernel@vger.kernel.org, 334113@bugs.debian.org, Alastair McKinstry <mckinstry@debian.org>, security@kernel.org, team@security.debian.org, secure-testing-team@lists.alioth.debian.org
Subject: Re: kernel allows loadkeys to be used by any user, allowing for local root compromise
Date: Thu, 20 Oct 2005 01:12:58 +0200
Scripsis, quam aut quem »Krzysztof Halasa« appellare soleo:
> Rudolf Polzer <debian-ne@durchnull.de> writes:
> > That's the only thing that might actually work - an inductive device wrapped
> > around the keyboard cable. But I've never seen those available ready to buy.
> 
> There are simpler designs - it's just a serial line, right? A simple
> "dongle" can send data from the keyboard to a notebook. With luck two
> wires would do (using parallel port for sampling data).

We use a PS/2 port, so without a reboot, this would not work. IIRC 2.6 kernels
with keyboard support compiled into the kernel cannot be forced to re-detect
the keyboard when the line was interrupted (which is a big problem with old KVM
switches). Of course, with USB keyboards this approach would work.

And if it weren't for the typical nvidia driver problems, we wouldn't allow
students to reboot the computers using the power button and let it restart the
X server instead.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#334113; Package linux-image-2.6.12-1-powerpc. Full text and rfc822 format available.

Acknowledgement sent to Paul Jakma <paul@clubi.ie>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #100 received at 334113@bugs.debian.org (full text, mbox):

From: Paul Jakma <paul@clubi.ie>
To: Krzysztof Halasa <khc@pm.waw.pl>
Cc: Horms <horms@verge.net.au>, linux-kernel@vger.kernel.org, Rudolf Polzer <debian-ne@durchnull.de>, 334113@bugs.debian.org, Alastair McKinstry <mckinstry@debian.org>, security@kernel.org, team@security.debian.org, secure-testing-team@lists.alioth.debian.org
Subject: Re: kernel allows loadkeys to be used by any user, allowing for local root compromise
Date: Thu, 20 Oct 2005 03:42:05 +0100 (IST)
On Tue, 18 Oct 2005, Krzysztof Halasa wrote:

> OTOH I don't know why ordinary users should be allowed to change key
> bindings.

I like to load a custom keymap to swap ctrl and caps-lock.

I'd like to keep that ability, but I'd much prefer if it didn't 
affect all VTs, and if it didn't persist past the end of my session.

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
Don't worry if you're a kleptomaniac; you can always take something for it.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#334113; Package linux-image-2.6.12-1-powerpc. Full text and rfc822 format available.

Acknowledgement sent to Krzysztof Halasa <khc@pm.waw.pl>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #105 received at 334113@bugs.debian.org (full text, mbox):

From: Krzysztof Halasa <khc@pm.waw.pl>
To: Rudolf Polzer <debian-ne@durchnull.de>
Cc: Horms <horms@verge.net.au>, linux-kernel@vger.kernel.org, 334113@bugs.debian.org, Alastair McKinstry <mckinstry@debian.org>, security@kernel.org, team@security.debian.org, secure-testing-team@lists.alioth.debian.org
Subject: Re: kernel allows loadkeys to be used by any user, allowing for local root compromise
Date: Thu, 20 Oct 2005 17:05:33 +0200
Rudolf Polzer <debian-ne@durchnull.de> writes:

> We use a PS/2 port, so without a reboot, this would not work. IIRC 2.6
> kernels
> with keyboard support compiled into the kernel cannot be forced to re-detect
> the keyboard when the line was interrupted (which is a big problem with
> old KVM
> switches).

Must have been a different problem, just tried and the keyboard works fine.

But of course one can connect the "dongle" before rebooting. Dead keyboard
can force reboot as well, can't it?

> Of course, with USB keyboards this approach would work.

Would be less trivial.
-- 
Krzysztof Halasa



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#334113; Package linux-image-2.6.12-1-powerpc. Full text and rfc822 format available.

Acknowledgement sent to Bill Davidsen <davidsen@tmr.com>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #110 received at 334113@bugs.debian.org (full text, mbox):

From: Bill Davidsen <davidsen@tmr.com>
To: Paul Jakma <paul@clubi.ie>
Cc: Horms <horms@verge.net.au>, linux-kernel@vger.kernel.org, Rudolf Polzer <debian-ne@durchnull.de>, 334113@bugs.debian.org, Alastair McKinstry <mckinstry@debian.org>, security@kernel.org, team@security.debian.org, secure-testing-team@lists.alioth.debian.org
Subject: Re: kernel allows loadkeys to be used by any user, allowing for local root compromise
Date: Thu, 20 Oct 2005 19:22:35 -0400
Paul Jakma wrote:
> On Tue, 18 Oct 2005, Krzysztof Halasa wrote:
> 
>> OTOH I don't know why ordinary users should be allowed to change key
>> bindings.
> 
> 
> I like to load a custom keymap to swap ctrl and caps-lock.
> 
> I'd like to keep that ability, but I'd much prefer if it didn't affect 
> all VTs, and if it didn't persist past the end of my session.

I believe in security, no matter how inconvenient, but it would be 
desirable to allow the user to reload the keymap, and the character set 
as well, only for the session in use. The solution would seem to lie in 
having an unchanging SAK key, and on exit from a session absolutely 
reset everything.

Clearly this would take some rethinking and a fair amount of work, so 
the right thing to do is use capabilities to block misuse until/unless 
convenience can be made secure.

Key mapping as a whole sucks, you have the map you get in a vt, which is 
ignored by X which maps its own, except when an X app remaps it yet 
again locally. Lots of room for both evil and stupidity.

-- 
   -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
 last possible moment - but no longer"  -me



Reply sent to Frederik Schüler <fs@debian.org>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to Rudolf Polzer <debian-ne@durchnull.de>:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #115 received at 334113-close@bugs.debian.org (full text, mbox):

From: Frederik Schüler <fs@debian.org>
To: 334113-close@bugs.debian.org
Subject: Bug#334113: fixed in linux-2.6 2.6.14-4
Date: Sat, 26 Nov 2005 09:17:41 -0800
Source: linux-2.6
Source-Version: 2.6.14-4

We believe that the bug you reported is fixed in the latest version of
linux-2.6, which is due to be installed in the Debian FTP archive:

kernel-image-2.6-386_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/kernel-image-2.6-386_2.6.14-4_i386.deb
kernel-image-2.6-686-smp_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/kernel-image-2.6-686-smp_2.6.14-4_i386.deb
kernel-image-2.6-686_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/kernel-image-2.6-686_2.6.14-4_i386.deb
kernel-image-2.6-k7-smp_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/kernel-image-2.6-k7-smp_2.6.14-4_i386.deb
kernel-image-2.6-k7_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/kernel-image-2.6-k7_2.6.14-4_i386.deb
linux-2.6_2.6.14-4.diff.gz
  to pool/main/l/linux-2.6/linux-2.6_2.6.14-4.diff.gz
linux-2.6_2.6.14-4.dsc
  to pool/main/l/linux-2.6/linux-2.6_2.6.14-4.dsc
linux-doc-2.6.14_2.6.14-4_all.deb
  to pool/main/l/linux-2.6/linux-doc-2.6.14_2.6.14-4_all.deb
linux-headers-2.6-386_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/linux-headers-2.6-386_2.6.14-4_i386.deb
linux-headers-2.6-686-smp_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/linux-headers-2.6-686-smp_2.6.14-4_i386.deb
linux-headers-2.6-686_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/linux-headers-2.6-686_2.6.14-4_i386.deb
linux-headers-2.6-k7-smp_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/linux-headers-2.6-k7-smp_2.6.14-4_i386.deb
linux-headers-2.6-k7_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/linux-headers-2.6-k7_2.6.14-4_i386.deb
linux-headers-2.6.14-2-386_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.14-2-386_2.6.14-4_i386.deb
linux-headers-2.6.14-2-686-smp_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.14-2-686-smp_2.6.14-4_i386.deb
linux-headers-2.6.14-2-686_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.14-2-686_2.6.14-4_i386.deb
linux-headers-2.6.14-2-k7-smp_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.14-2-k7-smp_2.6.14-4_i386.deb
linux-headers-2.6.14-2-k7_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.14-2-k7_2.6.14-4_i386.deb
linux-headers-2.6.14-2_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.14-2_2.6.14-4_i386.deb
linux-headers-2.6.14_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.14_2.6.14-4_i386.deb
linux-image-2.6-386_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/linux-image-2.6-386_2.6.14-4_i386.deb
linux-image-2.6-686-smp_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/linux-image-2.6-686-smp_2.6.14-4_i386.deb
linux-image-2.6-686_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/linux-image-2.6-686_2.6.14-4_i386.deb
linux-image-2.6-k7-smp_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/linux-image-2.6-k7-smp_2.6.14-4_i386.deb
linux-image-2.6-k7_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/linux-image-2.6-k7_2.6.14-4_i386.deb
linux-image-2.6.14-2-386_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/linux-image-2.6.14-2-386_2.6.14-4_i386.deb
linux-image-2.6.14-2-686-smp_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/linux-image-2.6.14-2-686-smp_2.6.14-4_i386.deb
linux-image-2.6.14-2-686_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/linux-image-2.6.14-2-686_2.6.14-4_i386.deb
linux-image-2.6.14-2-k7-smp_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/linux-image-2.6.14-2-k7-smp_2.6.14-4_i386.deb
linux-image-2.6.14-2-k7_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/linux-image-2.6.14-2-k7_2.6.14-4_i386.deb
linux-image-386_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/linux-image-386_2.6.14-4_i386.deb
linux-image-686-smp_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/linux-image-686-smp_2.6.14-4_i386.deb
linux-image-686_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/linux-image-686_2.6.14-4_i386.deb
linux-image-k7-smp_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/linux-image-k7-smp_2.6.14-4_i386.deb
linux-image-k7_2.6.14-4_i386.deb
  to pool/main/l/linux-2.6/linux-image-k7_2.6.14-4_i386.deb
linux-manual-2.6.14_2.6.14-4_all.deb
  to pool/main/l/linux-2.6/linux-manual-2.6.14_2.6.14-4_all.deb
linux-patch-debian-2.6.14_2.6.14-4_all.deb
  to pool/main/l/linux-2.6/linux-patch-debian-2.6.14_2.6.14-4_all.deb
linux-source-2.6.14_2.6.14-4_all.deb
  to pool/main/l/linux-2.6/linux-source-2.6.14_2.6.14-4_all.deb
linux-tree-2.6.14_2.6.14-4_all.deb
  to pool/main/l/linux-2.6/linux-tree-2.6.14_2.6.14-4_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 334113@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Frederik Schüler <fs@debian.org> (supplier of updated linux-2.6 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sat, 26 Nov 2005 13:18:41 +0100
Source: linux-2.6
Binary: linux-image-sun3 linux-headers-2.6.14-2-em64t-p4-smp linux-image-2.6.14-2-atari linux-image-2.6-powerpc-miboot linux-headers-2.6.14-2-atari linux-headers-2.6.14-2-386 linux-image-2.6.14-2-sun3 linux-image-2.6.14-2-em64t-p4-smp linux-image-2.6.14-2-hp linux-image-2.6-footbridge linux-image-2.6-amd64-generic linux-image-2.6.14-2-apus linux-headers-2.6-64-smp kernel-image-2.6-686-smp linux-headers-2.6-atari kernel-image-2.6-386 linux-headers-2.6-s390 linux-headers-2.6.14-2-sun3 linux-image-mvme16x linux-image-2.6.14-2-s3c2410 linux-image-itanium linux-headers-2.6.14-2-64 linux-image-2.6-amd64-k8-smp linux-headers-2.6.14-2-32 linux-image-2.6-rpc linux-image-2.6-s390 linux-image-q40 linux-headers-2.6-sparc64-smp linux-headers-2.6-mvme147 linux-image-footbridge kernel-image-2.6-itanium-smp linux-headers-2.6.14-2-powerpc linux-image-2.6.14-2-amd64-k8 linux-headers-2.6.14-2-amiga linux-headers-2.6-686-smp linux-image-atari linux-image-2.6.14-2-32 linux-headers-2.6.14-2-s390 linux-image-2.6-q40 linux-manual-2.6.14 kernel-image-2.6-k7-smp linux-headers-2.6.14-2-mvme147 linux-headers-2.6-powerpc-miboot linux-headers-2.6-apus linux-image-s390 linux-image-apus linux-image-2.6.14-2-mvme16x linux-headers-2.6.14-2-alpha-generic linux-patch-debian-2.6.14 linux-headers-2.6.14-2-s390x linux-image-2.6-itanium linux-image-amd64-k8-smp linux-image-2.6.14-2-mac linux-image-2.6.14-2-k7-smp linux-image-2.6.14-2-itanium linux-image-2.6.14-2-k7 linux-headers-2.6-amd64-generic linux-image-2.6-mckinley-smp linux-image-amiga linux-image-2.6-k7 linux-headers-2.6.14-2-32-smp linux-image-2.6.14-2-64-smp linux-headers-2.6.14-2-mckinley linux-image-mckinley-smp linux-image-2.6.14-2-amd64-k8-smp linux-image-em64t-p4-smp linux-image-2.6-powerpc linux-headers-2.6-s3c2410 linux-image-2.6-hp linux-image-2.6.14-2-itanium-smp linux-image-sparc64-smp linux-headers-2.6.14-2-amd64-k8 kernel-image-2.6-mckinley linux-image-powerpc-smp linux-headers-2.6-itanium-smp kernel-image-2.6-power3 linux-image-2.6-64-smp kernel-image-2.6-powerpc linux-headers-2.6-32 linux-tree-2.6.14 kernel-image-2.6-generic linux-headers-2.6-mvme16x linux-headers-2.6.14-2-mac linux-image-2.6.14-2-386 linux-headers-2.6.14-2-powerpc64 linux-image-2.6-alpha-generic linux-headers-2.6-amd64-k8-smp linux-image-2.6-em64t-p4 linux-image-32 linux-headers-2.6.14-2-sparc64-smp linux-headers-2.6.14-2-itanium linux-headers-2.6.14-2-em64t-p4 linux-headers-2.6-powerpc linux-image-hp linux-headers-2.6-em64t-p4-smp kernel-image-powerpc-smp linux-headers-2.6-sparc64 linux-image-powerpc64 linux-headers-2.6-hp linux-headers-2.6.14-2-mckinley-smp linux-image-2.6.14-2-686-smp linux-headers-2.6.14 linux-headers-2.6-powerpc64 linux-image-2.6-apus linux-headers-2.6.14-2-apus linux-image-2.6.14-2-64 linux-image-2.6.14-2-alpha-generic linux-headers-2.6-mac linux-headers-2.6-32-smp linux-image-2.6.14-2-sparc64 linux-headers-2.6-em64t-p4 linux-headers-2.6-rpc linux-image-2.6-mckinley linux-headers-2.6.14-2-sparc64 linux-headers-2.6-alpha-generic linux-image-2.6.14-2-amiga linux-headers-2.6-bvme6000 linux-image-2.6.14-2-alpha-smp kernel-image-2.6-sparc64-smp kernel-image-powerpc linux-image-bvme6000 linux-headers-2.6-alpha-smp linux-headers-2.6.14-2-k7 linux-headers-2.6.14-2-footbridge linux-image-2.6.14-2-q40 linux-image-2.6-atari linux-image-64 linux-image-s3c2410 linux-headers-2.6-386 linux-doc-2.6.14 linux-headers-2.6-sun3 linux-headers-2.6-mckinley-smp kernel-image-2.6-power4-smp linux-image-k7-smp linux-image-386 linux-source-2.6.14 linux-image-2.6.14-2-footbridge linux-image-2.6.14-2-mckinley-smp kernel-image-power3-smp linux-image-2.6.14-2-32-smp linux-image-2.6.14-2-bvme6000 linux-image-2.6-bvme6000 linux-image-mckinley linux-headers-2.6.14-2-686-smp linux-image-itanium-smp linux-image-2.6-sparc64-smp linux-headers-2.6-s390x linux-image-2.6.14-2-powerpc-smp linux-image-2.6-ixp4xx linux-headers-2.6-q40 linux-headers-2.6.14-2-alpha-smp kernel-image-2.6-k7 linux-image-ixp4xx linux-image-rpc linux-image-2.6.14-2-mckinley linux-image-2.6-mac linux-headers-2.6.14-2-powerpc-miboot linux-headers-2.6-64 kernel-image-2.6-power3-smp linux-image-2.6-s390x linux-image-2.6.14-2-em64t-p4 kernel-image-2.6-smp linux-headers-2.6.14-2-hp linux-image-2.6.14-2-rpc linux-image-alpha-smp linux-headers-2.6.14-2-amd64-k8-smp linux-headers-2.6.14-2-mvme16x linux-image-2.6-amd64-k8 linux-headers-2.6-footbridge linux-image-2.6-sparc64 linux-image-amd64-k8 kernel-image-power4 linux-image-2.6.14-2-686 linux-image-2.6.14-2-sparc64-smp linux-image-2.6-s3c2410 linux-headers-2.6.14-2-powerpc-smp linux-headers-2.6.14-2-686 linux-headers-2.6-k7-smp linux-headers-2.6.14-2-k7-smp linux-image-2.6.14-2-powerpc64 linux-headers-2.6-mckinley linux-image-em64t-p4 linux-image-2.6-686-smp linux-image-2.6-mvme147 linux-headers-2.6-ixp4xx linux-image-2.6-32-smp linux-image-powerpc-miboot linux-image-mvme147 linux-image-686-smp linux-image-2.6.14-2-powerpc linux-image-2.6-alpha-smp linux-headers-2.6.14-2-64-smp linux-headers-2.6.14-2-s3c2410 linux-image-686 linux-headers-2.6.14-2 linux-headers-2.6-k7 linux-image-k7 linux-image-2.6-powerpc-smp linux-image-alpha-generic linux-image-s390x linux-image-2.6-32 linux-headers-2.6-686 linux-headers-2.6.14-2-ixp4xx linux-image-64-smp linux-image-2.6-itanium-smp kernel-image-2.6-powerpc-smp linux-image-2.6.14-2-powerpc-miboot linux-image-2.6-amiga linux-headers-2.6.14-2-itanium-smp linux-image-2.6-mvme16x linux-headers-2.6-amiga linux-image-2.6-sun3 kernel-image-2.6-s390x linux-image-powerpc kernel-image-2.6-mckinley-smp kernel-image-power3 linux-image-2.6-powerpc64 linux-headers-2.6-amd64-k8 linux-image-32-smp kernel-image-power4-smp linux-image-mac linux-image-2.6-386 kernel-image-2.6-sparc64 kernel-image-2.6-power4 linux-headers-2.6.14-2-amd64-generic linux-image-amd64-generic kernel-image-2.6-itanium linux-headers-2.6.14-2-q40 linux-headers-2.6.14-2-bvme6000 linux-image-2.6.14-2-ixp4xx linux-image-2.6-64 linux-image-sparc64 linux-image-2.6.14-2-mvme147 linux-headers-2.6.14-2-rpc linux-image-2.6-em64t-p4-smp linux-image-2.6.14-2-s390x linux-headers-2.6-itanium linux-headers-2.6-powerpc-smp linux-image-2.6.14-2-amd64-generic linux-image-2.6-k7-smp linux-image-2.6-686 linux-image-2.6.14-2-s390 kernel-image-2.6-s390 kernel-image-2.6-686
Architecture: source i386 all
Version: 2.6.14-4
Distribution: unstable
Urgency: low
Maintainer: Debian Kernel Team <debian-kernel@lists.debian.org>
Changed-By: Frederik Schüler <fs@debian.org>
Description: 
 kernel-image-2.6-386 - Linux kernel 2.6.12 image on 386-class machines - transition pack
 kernel-image-2.6-686 - Linux kernel 2.6 image on PPro/Celeron/PII/PIII/P4 machines - tra
 kernel-image-2.6-686-smp - Linux kernel 2.6 image on PPro/Celeron/PII/PIII/P4 SMP machines -
 kernel-image-2.6-k7 - Linux kernel 2.6 image on AMD K7 machines - transition package
 kernel-image-2.6-k7-smp - Linux kernel 2.6 image on AMD K7 SMP machines - transition packag
 linux-doc-2.6.14 - Linux kernel specific documentation for version 2.6.14
 linux-headers-2.6-386 - Architecture-specific header files for Linux kernel 2.6 on 386-cl
 linux-headers-2.6-686 - Architecture-specific header files for Linux kernel 2.6 on PPro/C
 linux-headers-2.6-686-smp - Architecture-specific header files for Linux kernel 2.6 on PPro/C
 linux-headers-2.6-k7 - Architecture-specific header files for Linux kernel 2.6 on AMD K7
 linux-headers-2.6-k7-smp - Architecture-specific header files for Linux kernel 2.6 on AMD K7
 linux-headers-2.6.14 - All header files for Linux kernel 2.6.14
 linux-headers-2.6.14-2 - Common header files for Linux kernel 2.6.14
 linux-headers-2.6.14-2-386 - Header files for Linux kernel 2.6.14 on 386-class machines
 linux-headers-2.6.14-2-686 - Header files for Linux kernel 2.6.14 on PPro/Celeron/PII/PIII/P4 
 linux-headers-2.6.14-2-686-smp - Header files for Linux kernel 2.6.14 on PPro/Celeron/PII/PIII/P4 
 linux-headers-2.6.14-2-k7 - Header files for Linux kernel 2.6.14 on AMD K7 machines
 linux-headers-2.6.14-2-k7-smp - Header files for Linux kernel 2.6.14 on AMD K7 SMP machines
 linux-image-2.6-386 - Linux kernel 2.6 image on 386-class machines
 linux-image-2.6-686 - Linux kernel 2.6 image on PPro/Celeron/PII/PIII/P4 machines
 linux-image-2.6-686-smp - Linux kernel 2.6 image on PPro/Celeron/PII/PIII/P4 SMP machines
 linux-image-2.6-k7 - Linux kernel 2.6 image on AMD K7 machines
 linux-image-2.6-k7-smp - Linux kernel 2.6 image on AMD K7 SMP machines
 linux-image-2.6.14-2-386 - Linux kernel 2.6.14 image on 386-class machines
 linux-image-2.6.14-2-686 - Linux kernel 2.6.14 image on PPro/Celeron/PII/PIII/P4 machines
 linux-image-2.6.14-2-686-smp - Linux kernel 2.6.14 image on PPro/Celeron/PII/PIII/P4 SMP machine
 linux-image-2.6.14-2-k7 - Linux kernel 2.6.14 image on AMD K7 machines
 linux-image-2.6.14-2-k7-smp - Linux kernel 2.6.14 image on AMD K7 SMP machines
 linux-image-386 - Linux kernel image on 386-class machines
 linux-image-686 - Linux kernel image on PPro/Celeron/PII/PIII/P4 machines
 linux-image-686-smp - Linux kernel image on PPro/Celeron/PII/PIII/P4 SMP machines
 linux-image-k7 - Linux kernel image on AMD K7 machines
 linux-image-k7-smp - Linux kernel image on AMD K7 SMP machines
 linux-manual-2.6.14 - Linux kernel API manual pages for version 2.6.14
 linux-patch-debian-2.6.14 - Debian patches to version 2.6.14 of the Linux kernel
 linux-source-2.6.14 - Linux kernel source for version 2.6.14 with Debian patches
 linux-tree-2.6.14 - Linux kernel source tree for building Debian kernel images
Closes: 334113 340215 340571
Changes: 
 linux-2.6 (2.6.14-4) unstable; urgency=low
 .
   [ dann frazier ]
   * setkeys-needs-root-1.patch, setkeys-needs-root-2.patch:
     [SECURITY] Require root privilege to write the current
     function key string entry of other user's terminals.
     See CVE-2005-3257 (Closes: #334113)
 .
   [ Simon Horman ]
   * Enable MKISS globally (closes: #340215)
   * mm-invalidate_inode_pages2-overflow.patch
     [SECURITY] 32bit integer overflow in invalidate_inode_pages2() (local DoS)
   * ctnetlink-check-if-protoinfo-is-present.patch
     [SECURITY] ctnetlink: check if protoinfo is present (local DoS)
   * ctnetlink-fix-oops-when-no-icmp-id-info-in-message.patch
     [SECURITY] ctnetlink: Fix oops when no ICMP ID info in message (local DoS)
 .
   [ Sven Luther ]
   * Re-added powerpc/apus patch, now that Roman Zippel merged it in.
   * Let's create asm-(ppc|ppc64) -> asm-powerpc symlink farm.  (Closes: #340571)
 .
   [ maximilian attems ]
   * Add 2.6.14.3 patch - features changelog:
     - isdn/hardware/eicon/os_4bri.c: correct the xdiLoadFile() signature
     - x86_64/i386: Compute correct MTRR mask on early Noconas
     - PPTP helper: Fix endianness bug in GRE key / CallID NAT
     - nf_queue: Fix Ooops when no queue handler registered
     - ctnetlink: check if protoinfo is present
     - ip_conntrack: fix ftp/irc/tftp helpers on ports >= 32768
     - VFS: Fix memory leak with file leases
     - hwmon: Fix lm78 VID conversion
     - hwmon: Fix missing it87 fan div init
     - ppc64 memory model depends on NUMA
     - Generic HDLC WAN drivers - disable netif_carrier_off()
     - ctnetlink: Fix oops when no ICMP ID info in message
     - Don't auto-reap traced children
     - packet writing oops fix
     - PPTP helper: fix PNS-PAC expectation call id
     - NAT: Fix module refcount dropping too far
     - Fix soft lockup with ALSA rtc-timer
     - Fix calculation of AH length during filling ancillary data.
     - ip_conntrack TCP: Accept SYN+PUSH like SYN
     - refcount leak of proto when ctnetlink dumping tuple
     - Fix memory management error during setting up new advapi sockopts.
     - Fix sending extension headers before and including routing header.
     - hwmon: Fix missing boundary check when setting W83627THF in0 limits
   * Remove ctnetlink-check-if-protoinfo-is-present.patch,
     net-nf_queue-oops.patch - already included in 2.6.14.3.
 .
   [ Frederik Schüler ]
   * Make CONFIG_PACKET, PACKET_MM and UNIX builtin on all architectures:
     statically linked has better performance then modules due to TLB issue.
   * Add myself to uploaders.
Files: 
 f0739f0706c4d009db45ce8ea6c008b8 7625 devel optional linux-2.6_2.6.14-4.dsc
 1d30a542931685ad4d17b31580b82a1e 424541 devel optional linux-2.6_2.6.14-4.diff.gz
 f150bbec280fdd62b95fcc1f3f9a82bf 3889112 doc optional linux-doc-2.6.14_2.6.14-4_all.deb
 beacf10dea8ac618daeee11c9d635543 788366 doc optional linux-manual-2.6.14_2.6.14-4_all.deb
 01b0fa56b41fd77a8ed0b3f0b6772046 305062 devel optional linux-patch-debian-2.6.14_2.6.14-4_all.deb
 1622b4539acd62063dba248171873890 38272284 devel optional linux-source-2.6.14_2.6.14-4_all.deb
 6d558efd6c6e71c53ff3a35e837e6c7c 14084 devel optional linux-tree-2.6.14_2.6.14-4_all.deb
 bb0178618ebe39d155d63c3474af166d 116668 devel optional linux-headers-2.6.14_2.6.14-4_i386.deb
 25ae1e1bed719319b0516ca351f45b4d 3038570 devel optional linux-headers-2.6.14-2_2.6.14-4_i386.deb
 790137a37b344404cfc3755ae3c2332a 517016 devel optional linux-headers-2.6.14-2-386_2.6.14-4_i386.deb
 bcf85e036ee24e573de85f87f83643f3 16816816 base optional linux-image-2.6.14-2-386_2.6.14-4_i386.deb
 0acc34adb1b48b297cc7d5c3c16e59e8 13640 base optional linux-image-386_2.6.14-4_i386.deb
 1ff1fdd43f27d9b23aadf7df5f6fabaa 13648 base optional linux-image-2.6-386_2.6.14-4_i386.deb
 aaf888abe0eb7b8f1bfaf1c1c2a7cb41 13676 devel optional linux-headers-2.6-386_2.6.14-4_i386.deb
 c2f6a96fff613b84a648fe9d62cf6c56 514360 devel optional linux-headers-2.6.14-2-686_2.6.14-4_i386.deb
 900515ba87414163bab3e0c6ae3e89d6 17727594 base optional linux-image-2.6.14-2-686_2.6.14-4_i386.deb
 9f7a6aa8ea0d0e79523622dc3081bdab 13666 base optional linux-image-686_2.6.14-4_i386.deb
 32544b6102b68f062e50db0565e69520 13674 base optional linux-image-2.6-686_2.6.14-4_i386.deb
 5b858f8577e58e17ef6fb4195320ffba 13710 devel optional linux-headers-2.6-686_2.6.14-4_i386.deb
 57ad17eb6af7730540046766098a615c 512346 devel optional linux-headers-2.6.14-2-686-smp_2.6.14-4_i386.deb
 8d31c01f02ab203a04ad73b42c625769 17610890 base optional linux-image-2.6.14-2-686-smp_2.6.14-4_i386.deb
 c530089d13390a8a91d23cf0a08f3d43 13686 base optional linux-image-686-smp_2.6.14-4_i386.deb
 1aace47be4d01867e2220e7107851554 13694 base optional linux-image-2.6-686-smp_2.6.14-4_i386.deb
 827f73f9e8539507befc28e12d08aa2e 13726 devel optional linux-headers-2.6-686-smp_2.6.14-4_i386.deb
 7b286f0d1ea777c1ea8119f1fae424b0 525100 devel optional linux-headers-2.6.14-2-k7_2.6.14-4_i386.deb
 493f5d78d830294a1b93f6a5f724108f 17497772 base optional linux-image-2.6.14-2-k7_2.6.14-4_i386.deb
 0b11cef2a3973de98509561ea54038eb 13656 base optional linux-image-k7_2.6.14-4_i386.deb
 2a65eb85aa1ca41f1facde06dc057d3c 13666 base optional linux-image-2.6-k7_2.6.14-4_i386.deb
 e5ab368360edb98e26cc2ce87f2b85e6 13690 devel optional linux-headers-2.6-k7_2.6.14-4_i386.deb
 646edad1e9756f72c863e91275fb4873 512262 devel optional linux-headers-2.6.14-2-k7-smp_2.6.14-4_i386.deb
 a70dcf211a431c68533ede016ab83b96 17435974 base optional linux-image-2.6.14-2-k7-smp_2.6.14-4_i386.deb
 c3ef1bc3d9154325ba9e5aef0d0461bf 13684 base optional linux-image-k7-smp_2.6.14-4_i386.deb
 d5bed92a2fd05b8e03964f2262625457 13692 base optional linux-image-2.6-k7-smp_2.6.14-4_i386.deb
 ac3b691ae88c6b90387c4215c49c9aaf 13722 devel optional linux-headers-2.6-k7-smp_2.6.14-4_i386.deb
 e6ab181b6510111c2d633c93e102a678 13640 base extra kernel-image-2.6-386_2.6.14-4_i386.deb
 f5a2b5981c203fde47926fb02b6f05f3 13656 base extra kernel-image-2.6-686_2.6.14-4_i386.deb
 9454df287fe4d9f67b76545aa30c55b3 13668 base extra kernel-image-2.6-686-smp_2.6.14-4_i386.deb
 dc2fd5ae255808a53b8af7fc304e949a 13646 base extra kernel-image-2.6-k7_2.6.14-4_i386.deb
 779d347f2c75b24145b0f2265cb03acc 13660 base extra kernel-image-2.6-k7-smp_2.6.14-4_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDiI+b6n7So0GVSSARAtjXAJ4jCQTw15WHqWgfDhPZGa4N3tThHACcCUop
pBIZZYx3u5fYnphDNxVivQU=
=+2gU
-----END PGP SIGNATURE-----




Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sun, 17 Jun 2007 15:02:10 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Mon Apr 21 11:02:14 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.