linux-kernel - Re: [RFC] Input: implement sysrq as an input handler

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]

Date:	Sun, 4 Apr 2010 15:27:34 +0200
From:	Pavel Machek <pavel@....cz>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Henrique de Moraes Holschuh <hmh@....eng.br>,
	Linux Input <linux-input@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Jason Wessel <jason.wessel@...driver.com>
Subject: Re: [RFC] Input: implement sysrq as an input handler

Hi!

> > If userspace disables sysrq during normal operation, that makes it
> > useless.
> > 
> > If normal user could do that, that's a security problem.
> > 
> 
> Yes, and...? This patch does not change the way one enables, disables,
> intercepts, etc. SysRq and SAK compared to how it was handled when SysRq
> was part of keyboard _input handler_. The only thisng this patch does is
> moving the code into a _separate_ input handler.

Yep, that was just a note.

> > > The problem is that device does not know what SysRq and especially SAK are.
> > > User can reassign key codes and key symbols easily.
> > 
> > That was not case in original implementation; it had hardcoded keymap.
> 
> The earth was also flat back then and the only keyboard was AT one. SAK
> was always part of keymap so could be reassinged at any time.

Well, there are two SAKs.

One SAK -- in keymap, is remappable and always was.

Second, sysrq-saK -- is (was?) hardcoded and not affected by
keymap. Please don't change that.

> > > I don't think we had any issues like this since 2.5 so I would not worry
> > > about userspace too much. If anything we just need to review what stuff
> > > we run as root (we do that anyway, right?).
> > 
> > Hehe. If X can break sysrq, that's both X and sysrq problem.
> 
> Root can disable Sysrq... News at 11.

Root *does* disable sysrq is indeed news ... and problem.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/