Re: kernel allows loadkeys to be used by any user, allowing for local root compromise

[Rudolf Polzer]

Scripsis, quam aut quem »Krzysztof Halasa« appellare soleo:
> Rudolf Polzer <debian-ne@xxxxxxxxxxxx> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/